Inquiry method, device, system, electronic equipment, storage medium and program product

Abstract

The embodiment of the present specification provides a diagnosis method, device, system, electronic equipment, storage medium and program product. In the embodiment of the present specification, a first diagnosis list is determined based on the chief complaint information of a user, and at least two first suspected diagnoses are selected from the first diagnosis list. Related candidate questions are determined for the at least two first suspected diagnoses to form a candidate question set; a large language model is used to select a candidate question that can change the confidence of the at least two first suspected diagnoses from the candidate question set as a first inquiry question; and the first inquiry question is fed back to the user for the chief complaint information.

Description

Technical Field

[0001] This specification relates to the field of computer technology, and in particular to a diagnostic method, apparatus, system, electronic device, storage medium, and program product. Background Technology

[0002] With the continuous development of technology, automated consultation services have emerged. For example, users can input their chief complaint information, such as symptoms and signs, through a client application. The server will then provide feedback on the consultation questions to the client based on the user's chief complaint information, so as to obtain more detailed information through interaction with the user and make a diagnosis.

[0003] The current automated consultation service still has a lot of room for improvement in consultation efficiency. Summary of the Invention

[0004] This specification provides several embodiments of a consultation method, apparatus, system, electronic device, storage medium, and program product to improve accuracy.

[0005] The first embodiment of this specification provides a method for taking a medical history. The method includes: Based on the user's chief complaint, a first diagnostic list is determined; the first diagnostic list includes multiple first hypothetical diagnoses, which represent multiple possible diagnostic results generated by the large language model for the user's chief complaint; Based on the confidence level of the plurality of first hypothesis diagnoses, at least two first hypothesis diagnoses are selected from the plurality of first hypothesis diagnoses; For each of the at least two first hypothesis diagnoses, relevant candidate questions are determined to form a candidate question set, and the relevant candidate questions are used to verify or exclude the corresponding first hypothesis diagnoses; Using a large language model, candidate questions that can change the diagnostic confidence of at least two first hypotheses are selected from the candidate question set as the first consultation question; Based on the chief complaint, the first consultation question was addressed.

[0006] A second embodiment of this specification provides a medical consultation device. The medical consultation device includes: A determination module is used to determine a first diagnostic list based on the user's chief complaint information; the first diagnostic list includes multiple first hypothetical diagnoses, which represent multiple possible diagnostic results generated by the large language model for the user's chief complaint; A selection module is used to select at least two first hypothesis diagnoses from the plurality of first hypothesis diagnoses based on the confidence level of the first hypothesis diagnoses; The determining module is further configured to determine relevant candidate questions for each of the at least two first hypothesis diagnoses, forming a candidate question set, wherein the relevant candidate questions are used to verify or exclude the corresponding first hypothesis diagnoses; The processing module is used to select, using a large language model, candidate questions that can change the diagnostic confidence of at least two first hypotheses as first consultation questions from the candidate question set; The feedback module is used to provide feedback on the first consultation question.

[0007] A third embodiment of this specification provides a medical consultation system. The medical consultation system includes: The client is used to provide the interactive interface; The server is used to execute the steps in the consultation method provided in the above embodiments.

[0008] A fourth embodiment of this specification provides an electronic device. The electronic device includes a memory and a processor. The memory stores executable instructions; the processor executes the executable instructions to implement the steps in the consultation method provided in the above embodiments.

[0009] The fifth embodiment of this specification provides a computer-readable storage medium. The storage medium stores computer instructions that, when executed by a processor, can perform the steps of the consultation method provided in the above embodiments.

[0010] The sixth embodiment of this specification provides a computer program product. This computer program product includes a computer program or instructions that, when executed by a processor, cause the processor to perform the steps in the diagnostic inquiry method provided in the above embodiments.

[0011] In the technical solutions of the various embodiments provided in this specification, a first diagnostic list is determined based on the user's chief complaint information. Based on the confidence levels of multiple first hypothetical diagnoses in the first diagnostic list, at least two first hypothetical diagnoses are selected from the first diagnostic list. Then, relevant candidate questions are determined for each of the at least two first hypothetical diagnoses to form a candidate question set. A large language model is used to select one candidate question from the candidate question set as the first consultation question. The first consultation question is then fed back to the user based on the chief complaint information. It is evident that the various embodiments of this specification innovatively propose a mechanism of "candidate question set determination + large language model question selection." Compared to the method of having the large language model generate consultation questions entirely based on the user's chief complaint information, the embodiments of this specification provide a candidate question set for the large language model. The large language model selects candidate questions from this set whose information can change the confidence levels of at least two first hypothetical diagnoses as consultation questions. This method has low computational overhead, and the consultation questions are more valuable and more targeted. Compared to methods that use computational models to calculate values ​​for each candidate question (such as the discrimination index or information gain value in distinguishing different hypothetical diagnoses), the embodiments in this specification utilize large language models for selection. This cleverly leverages the powerful contextual reasoning capabilities to approximate complex calculations, eliminating the need to build a large, detailed prior probability knowledge base to train or adjust the computational model to improve its accuracy. Furthermore, in the embodiments of this specification, each question has a clear and traceable objective (i.e., a question that can distinguish different first hypothetical diagnoses to the greatest extent possible), rather than random or aimless dialogue. This helps improve consultation efficiency, unlike related technologies that require multiple rounds of consultation to eliminate a hypothetical diagnosis, and then multiple rounds of consultation to find the accurate hypothetical diagnosis. Attached Figure Description

[0012] The accompanying drawings, which are included to provide a further understanding of this specification and form part of this specification, illustrate exemplary embodiments and are used to explain this specification, but do not constitute an undue limitation thereof. In the drawings: Figure 1 This is a schematic diagram of the structure of a consultation system provided in an exemplary embodiment of this specification; Figure 2 A schematic diagram illustrating the working principle of the consultation system provided in an exemplary embodiment of this specification; Figure 3 A flowchart illustrating a consultation method provided as an exemplary embodiment of this specification; Figure 4 A flowchart illustrating a consultation method provided as another exemplary embodiment of this specification; Figure 5 A flowchart illustrating the loop in a consultation method provided as another exemplary embodiment of this specification; Figure 6 This is a schematic diagram of the structure of a medical consultation device provided in an exemplary embodiment of this specification; Figure 7 This is a schematic diagram of the structure of an electronic device provided as an exemplary embodiment of this specification. Detailed Implementation

[0013] To make the objectives, technical solutions, and advantages of this specification clearer, the technical solutions of this specification will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of them. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this specification.

[0014] It should be noted that, in the cases involving user information in the embodiments of this specification, the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in the embodiments of this specification are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse. In addition, the various models involved in this specification (including but not limited to language models or large models) comply with relevant laws and standards.

[0015] Before introducing the specific details of each embodiment in this specification, a brief explanation of the technical terms mentioned herein will be provided.

[0016] Information gain refers to the amount of information a question can provide. In this paper, it refers to the extent to which a question (whether answered yes or no) changes the confidence level of various diagnostic probabilities. The question with the greatest information gain is the "key question" that most effectively distinguishes different diagnoses.

[0017] The single best question is the question that has the greatest information gain among many candidate questions, that is, the question that is most effective in distinguishing the competing diagnoses in the current differential diagnosis list.

[0018] Bayesian-like Update: A mechanism that simulates the ideas of Bayes' theorem. In this paper, it refers to the system re-evaluating the entire list of diagnoses and updating the confidence level of each diagnosis after obtaining an answer (new evidence) to a new question.

[0019] Dynamic Multi-Hypothesis: This refers to the practice of not locking onto a single diagnosis during the consultation process, but rather simultaneously and dynamically maintaining a list of possible diagnoses (DDx). This list of diagnoses is continuously updated based on new consultation information.

[0020] Differential diagnosis (DDx): In medicine, this refers to the process of listing all possible diagnoses for a given symptom or sign, and then eliminating or confirming them one by one through further examination. In this article, differential diagnosis is a list of diagnoses generated and maintained by the system and ordered by probability.

[0021] Evidence-anchored: refers to the explicit, traceable medical evidence required to support key steps in a system, such as generating a hypothetical diagnosis. This is achieved by associating collected clinical features with a pre-built, guideline-based "feature-disease index".

[0022] Feature_to_disease_index: A key index built offline. It establishes a mapping from clinical features (such as symptoms and signs) to related diseases, providing evidence-based clues when generating initial diagnostic hypotheses.

[0023] Consultation flow: A data structure. A consultation flow is not static text or a flowchart, but rather a structured, executable unit of diagnostic logic compiled from clinical guidelines and other medical knowledge. Consultation flows can be divided into: SCC Flow and DSFlow.

[0024] SCC Flow (Symptom Chief Complaint Flow): This symptom-based complaint flow is used in the initial consultation phase. It systematically collects basic information about the patient's condition and identifies alarm symptoms based on the user's complaint.

[0025] DS Flow (Diagnosis Specific Flow): A consultation process. Each disease corresponds to a consultation process, which is an executable consultation process for a specific disease, including the logical steps and questions required to verify or rule out the diagnosis.

[0026] PatientState: A dynamic data object used to structure and store all collected patient information throughout the consultation process, including symptoms, signs, consultation history, and a list of diagnoses (ddx_hypothesis). The state data mentioned below (such as first state data, second state data, third state data, and fourth state data) can be this PatientState.

[0027] ddx_hypothesis: A data structure stored in PatientState, namely a list of diagnoses. It contains multiple possible disease diagnoses, their respective confidence levels, and the reasoning that supports or opposes the diagnosis.

[0028] MDT Chairman: In one embodiment provided in this specification, this role is defined for the Large Language Model (LLM). It simulates the chairman of a multidisciplinary team (MDT) consultation, responsible for selecting the "key question" with the greatest information gain (i.e., the ability to distinguish between different diagnoses) from multiple candidate questions.

[0029] PICO (Patient-Intervention-Comparison-Outcome) is a standard framework in evidence-based medicine used to construct clinical questions and summarize research evidence. In this paper, PICO is used as the final structured output format to seamlessly integrate consultation results into subsequent treatment recommendations or report generation modules.

[0030] Large language models, such as LLM, are artificial intelligence models trained on large amounts of text data using deep learning. They are capable of understanding, generating, and reasoning about human language. Large language models have a large number of parameters and can be trained using self-supervised or unsupervised methods. Once trained, the model can process long texts and capture contextual relationships, and can generate logically coherent content, etc.

[0031] Figure 1This application illustrates a consultation system corresponding to the consultation method provided in this embodiment. The consultation system includes a client 2 and a server 1. The client 2 and server 1 communicate via a network. The client provides an interactive interface. The server 1 determines a first diagnostic list based on the user's chief complaint information sent by the client; the first diagnostic list includes multiple first hypothetical diagnoses; the multiple first hypothetical diagnoses represent multiple possible diagnostic results generated by a large language model for the user's chief complaint; based on the confidence level of the multiple first hypothetical diagnoses, at least two first hypothetical diagnoses are selected from the multiple first hypothetical diagnoses; relevant candidate questions are determined for each of the at least two first hypothetical diagnoses to form a candidate question set; wherein the relevant candidate questions are used to verify or exclude the corresponding first hypothetical diagnoses; using the large language model, candidate questions that can change the confidence level of at least two first hypothetical diagnoses are selected as first consultation questions from the candidate question set; and the first consultation question is fed back to the client.

[0032] Candidate questions that can alter the probability distribution (i.e., confidence level) of at least two first-hypothetical diagnoses are considered to be questions that can distinguish between different first-hypothetical diagnoses. Commonly used quantitative metrics include "information gain" or "discrimination index." As mentioned in the terminology explanation above, information gain refers to the amount of information a candidate question can provide. The question with the greatest information gain is the "key question" that most effectively distinguishes between different hypothetical diagnoses. The discrimination index refers to the candidate question's ability to distinguish between at least two most probable hypothetical diagnoses.

[0033] Furthermore, server 1 can also be used to respond to the user's response to the first consultation question through the client and determine a second diagnosis list; wherein, the second diagnosis list includes multiple second hypothetical diagnoses and the confidence levels corresponding to the second hypothetical diagnoses; if the second diagnosis list contains a second hypothetical diagnosis with a confidence level greater than a threshold, then the second diagnosis list is used as the basis for generating consultation results; if the second diagnosis list does not contain a second hypothetical diagnosis with a confidence level greater than a threshold, then at least two second hypothetical diagnoses are selected from the second hypothetical diagnoses, and a second consultation question is determined for the at least two second hypothetical diagnoses.

[0034] In this embodiment, server 1 can be a server, service cluster, virtual server, or cloud, etc., and this embodiment does not specifically limit it. Server 1 provides corresponding functional services to client 2, such as consultation services, query services, etc. At least one model can be deployed on server 1, such as a large language model, a preset model that can build processes and / or indexes, etc. Of course, server 1 can also deploy only a powerful model, such as a large language model, which can interact with users (such as consultation) and automatically build processes (such as the symptom complaint process and / or consultation process mentioned below) and / or indexes (such as the clinical feature-disease index mentioned below), etc. Users can access the interactive interface through a browser, client application (APP), web application H5 (HyperText Markup Language 5, fifth generation HTML, Hypertext Markup Language), lightweight application (also known as a mini-program, a lightweight application), or cloud application on the corresponding device of client 2. Client devices can be, but are not limited to: smartphones, smart wearable devices, tablets, laptops, desktop computers, etc. In this embodiment, the server can implement the steps in the following method embodiments, which will be described in detail below.

[0035] See Figure 2 The example shown illustrates a system architecture that can be deployed on the server side. This system architecture may include: a consultation and information collection service, a knowledge base service, and a large language model service. Each service may correspond to a service node on hardware, which can be a server, a virtual server, a server cluster, or a cloud application.

[0036] The consultation and information collection service manages the consultation process (such as a multi-turn dialogue state machine); it collects, updates, and structures user complaint and response information (such as symptoms, medical history, vital signs, and diagnostic lists generated during the consultation process). This consultation and information collection service can rely on a session database to save the consultation state and will also call knowledge base services and large language model services.

[0037] The knowledge base service stores and manages structured medical knowledge, pre-built indexes (such as clinical feature-disease indexes), and pre-built workflows (such as symptom complaint workflows and / or consultation workflows), and also provides a knowledge retrieval interface. The knowledge base service may also have a knowledge retrieval and inference engine. Databases that the knowledge base service can use may include, but are not limited to, graph databases (such as those storing clinical feature-disease indexes), vector databases, and relational databases. For example, the consultation and information collection service initiates an API call to the knowledge base service (such as requesting a symptom complaint workflow template for "symptom A"), and the knowledge base service returns the symptom complaint workflow template for "symptom A"; the consultation and information collection service then interacts with the user according to the symptom complaint workflow template for "symptom A" (such as sequentially asking about duration, pain location, etc.). As another example, the consultation and information collection service initiates another API call to the knowledge base service (such as requesting a consultation workflow template for "diagnosis a"), and similarly, the knowledge base service returns the consultation workflow template for "diagnosis a". The consultation and information collection service then determines candidate questions according to the consultation workflow template for "diagnosis a". For example, the consultation and information collection service sends a request to the knowledge base service to search for diseases. This request may include all the status information of all users collected in the symptom complaint process (such as symptoms, signs, location, duration, etc.). The knowledge base service responds to the request by performing knowledge retrieval and reasoning, and provides feedback to the consultation and information collection service on at least one possible disease.

[0038] The large language model can be deployed in the cloud or on a private cluster. The consultation and information gathering service can send at least one disease reported by the knowledge base service to the large language model. The large language model can then provide a list of diagnoses, which may include at least one hypothetical diagnosis. Based on the consultation process templates corresponding to multiple hypothetical diagnoses reported by the knowledge base service, the consultation and information gathering service can also determine candidate questions for each hypothetical diagnosis. The service can then send multiple candidate questions to the large language model, which will select the candidate question that meets the information gain requirement (e.g., the one with the highest information gain) as the consultation question (i.e., the key question).

[0039] More specific functions and executable steps for each service will be mentioned in the following method embodiments.

[0040] One embodiment of this application provides a method for conducting a medical consultation. The entity executing this method can be the aforementioned server. See also... Figure 3 As shown in the example, the method includes: 101. Based on the user's chief complaint information, determine a first diagnostic list; the first diagnostic list includes multiple first hypothetical diagnoses, the multiple first hypothetical diagnoses representing multiple possible diagnostic results generated by the large language model for the user's chief complaint; 102. Based on the confidence level of the plurality of first hypothesis diagnoses, select at least two first hypothesis diagnoses from the plurality of first hypothesis diagnoses; 103. Determine relevant candidate questions for each of the at least two first hypothesis diagnoses to form a candidate question set, wherein the relevant candidate questions are used to verify or exclude the corresponding first hypothesis diagnoses; 104. Using a large language model, select candidate questions from the candidate question set that can change the diagnostic confidence of at least two first hypotheses as the first consultation question; 105. Provide feedback on the first consultation question.

[0041] In point 101 above, the user's chief complaint information can be entered by the user through the client's interactive interface, such as through an input tool (e.g., keyboard), voice input, or uploaded information. The chief complaint information may include, but is not limited to: symptoms, signs, presence of underlying medical conditions, historical physical examination reports, location of symptoms, duration of symptoms, etc. The user's chief complaint information can be entered and / or uploaded by the user in a single instance, or it can be obtained through multiple interactions and inquiries with the user.

[0042] In some embodiments, in addition to containing multiple first hypothetical diagnoses, the first diagnosis list may also include the confidence level corresponding to each first hypothetical diagnosis. Accordingly, step 102 above, "selecting at least two first hypothetical diagnoses from the first hypothetical diagnoses," can specifically be as follows: From the plurality of first hypothesis diagnoses, select a predetermined number of first hypothesis diagnoses with the highest confidence level; wherein the predetermined number is greater than or equal to 2.

[0043] The confidence level corresponding to the first hypothesis diagnosis can be determined by models such as deep learning models and convolutional neural network models. Alternatively, the confidence level corresponding to the first hypothesis diagnosis can be determined by a large language model.

[0044] In other embodiments, step 102 above may select at least two first hypothetical diagnoses by referring to preset rules. For example, first select the first hypothetical diagnoses that may point to critical illness and are of high urgency from multiple first hypothetical diagnoses, and then select common first hypothetical diagnoses, etc.

[0045] The "candidate questions related to each first hypothesis diagnosis" in the above 103 can be determined using the consultation process in the knowledge base. For example, the knowledge base stores consultation processes corresponding to various diagnoses. In this consultation process, the questions corresponding to the current consultation stage are extracted from the consultation processes corresponding to each first hypothesis diagnosis, and these questions are used as candidate questions related to that first hypothesis diagnosis.

[0046] The consultation process corresponding to a specific first-hypothesis diagnosis includes the logical steps and questions required to verify or rule out that first-hypothesis diagnosis. In the diagnostic service provided to users, each time the consultation process corresponding to the first-hypothesis diagnosis is invoked and a question is extracted as a candidate question according to its logical steps, that candidate question is marked. Upon the next invocation of the consultation process corresponding to the first-hypothesis diagnosis, the next unmarked candidate question is extracted according to its logical steps. The "current consultation stage" can be understood as: the stage in the consultation process corresponding to the unmarked (i.e., unextracted) candidate question following the marked candidate question.

[0047] Among the 104 above, a candidate question that can change the diagnostic confidence of at least two first hypotheses can be a candidate question that satisfies the information gain requirement. Satisfying the information gain requirement can be, but is not limited to, having an information gain value greater than a threshold for each candidate question in the candidate question set, or having the maximum information gain in the candidate question set.

[0048] In some embodiments, a first diagnostic list and a candidate question set can be input into a large language model. The first diagnostic list may include, in addition to the first hypothetical diagnosis, the confidence level corresponding to each first hypothetical diagnosis, and the reasoning supporting or opposing the first hypothetical diagnosis. By inputting the first diagnostic list and the candidate question set into the large language model, the model can combine the multiple first hypothetical diagnoses included in the first diagnostic list, the confidence levels of each first hypothetical diagnosis, and the reasoning supporting or opposing each first hypothetical diagnosis to analyze the information gain of each candidate question in the candidate question set, thereby selecting one as the first diagnostic question.

[0049] Alternatively, the at least two first hypothesis diagnoses and candidate question sets selected in step 102 can be input into a large language model. The large language model can then combine the at least two first hypothesis diagnoses to analyze the candidate questions in the candidate question set that best distinguish some or all of the first hypothesis diagnoses as the first consultation question.

[0050] Alternatively, the at least two first hypothetical diagnoses selected in step 102, the confidence levels corresponding to the at least two first hypothetical diagnoses, the evidence supporting or opposing the at least two first hypothetical diagnoses, and the candidate question set are input into a large language model. The large language model combines the at least two first hypothetical diagnoses, the confidence levels corresponding to the at least two first hypothetical diagnoses, and the evidence supporting or opposing the at least two first hypothetical diagnoses to analyze the information gain corresponding to each candidate question in the candidate question set, so as to select one as the first consultation question.

[0051] The information gain of each candidate question can be determined by the large language model. Alternatively, the large language model does not specifically calculate the information gain of each candidate question, but instead uses its powerful contextual reasoning capabilities to approximate the complex information gain calculation. The first question output by the large language model is a candidate question whose information gain meets the requirements.

[0052] Large language models possess the ability to understand the differences between various hypothetical diagnoses and to comprehend context. This embodiment utilizes a large language model for decision-making, cleverly leveraging its powerful capabilities to approximate complex information gain calculations. It selects a candidate question from multiple first-choice questions that meets the required information gain as the first diagnostic question. This first diagnostic question can distinguish these hypothetical diagnoses to the greatest extent, efficiently eliminating some and focusing on the key hypothetical diagnoses, thus significantly improving diagnostic efficiency. In related technologies, traditional machine learning or probabilistic models (such as entropy and Gini impurity in decision theory) are typically used to calculate a specific information gain score for each candidate question. Such machine learning or probabilistic models require a large, detailed, and labeled prior probability knowledge base. Constructing a comprehensive and accurate prior probability knowledge base is extremely difficult and costly.

[0053] In other feasible embodiments, candidate questions that can change the confidence levels of at least two first-hypothesis diagnoses can be candidate questions that meet the discrimination index requirements. The large language model can calculate the discrimination index corresponding to each candidate question in the candidate question set based on the first diagnostic list and the candidate question set. The candidate question with the largest discrimination index is selected as the first diagnostic question.

[0054] The method provided in this embodiment may further include the following steps: 106. Responding to the user's response to the first consultation question, determine a second diagnosis list; wherein the second diagnosis list includes multiple second hypothetical diagnoses and the confidence levels corresponding to the second hypothetical diagnoses; 107. If the second diagnosis list contains a second hypothetical diagnosis with a confidence level greater than the threshold, then the second diagnosis list shall be used as the basis for generating the consultation results. 108. If there is no second hypothesis diagnosis with a confidence level greater than the threshold in the second diagnosis list, then at least two second hypothesis diagnoses are selected from the plurality of second hypothesis diagnoses, and a second consultation question is determined for the at least two second hypothesis diagnoses.

[0055] Step 108 above essentially means: if there is no second hypothetical diagnosis with a confidence level greater than the threshold in the second diagnosis list, then return to steps 102 to 105. Accordingly, "first diagnosis list" in steps 102 to 104 is replaced with "second diagnosis list", and "first hypothetical diagnosis" is replaced with "second hypothetical diagnosis"; step 105 corresponds to "providing feedback on the second consultation question based on the response information".

[0056] The solution provided in the embodiments of this specification constructs a closed-loop, Bayesian-like iterative process: generating a question set -> selecting and determining the consultation questions -> updating the question set based on user responses to determine the next consultation question. This process continuously collects new evidence through strategic questioning in each round to update the question set until the diagnosis converges (i.e., there is a hypothesis diagnosis with a confidence level greater than a threshold). Each consultation question can efficiently eliminate some hypothesis diagnoses, focusing on the key hypothesis diagnosis, resulting in high consultation efficiency; and this iterative mechanism simulates the process of expert doctors dealing with uncertainties.

[0057] Furthermore, this embodiment also introduces a dynamic data object, namely, status data (such as PatientState). This status data continuously collects information throughout the consultation process. This status data may include, but is not limited to, symptoms, signs, consultation history, diagnosis lists, etc. In some implementable embodiments, step 101, "determining the first diagnosis list based on the user's chief complaint information," may include the following steps: 1011. Based on the aforementioned complaint information, generate status data representing the user's state; 1012. Using a knowledge base, determine the first disease information related to the state data; 1013. Input the status data and the first disease information into the large language model, and generate the first diagnosis list from the large language model.

[0058] The above step 1011 can be specifically described as follows: the chief complaint information is structured and stored in a dynamic status data. This status data will be continuously updated and improved during subsequent consultations.

[0059] In a more specific example, the knowledge base includes a clinical feature-disease index. Accordingly, step 1012 above, "using the knowledge base to determine the first disease information related to the state data," may include the following steps: 1012a. Extract at least one clinical feature from the status data; 1012b. Query the clinical feature-disease index to obtain at least one disease related to the at least one clinical feature, so as to form the first disease information.

[0060] In this embodiment, the "clinical feature-disease index" serves as a bridge connecting the chief complaint information and the generation of evidence-based hypotheses, providing evidence-based clues for the subsequent generation of the first diagnostic list by the large language model. Compared to the large language model directly generating the first diagnostic list based on the chief complaint information (or first state data), this embodiment utilizes the more specialized clinical feature-disease index to determine the first disease information, thus making the first diagnostic list output by the large language model based on this first disease information more accurate.

[0061] In step 1013 above, the first diagnosis list may include at least one first hypothetical diagnosis and a confidence level corresponding to each first hypothetical diagnosis. Further, in some embodiments, in addition to including at least one first hypothetical diagnosis and a confidence level corresponding to each first hypothetical diagnosis, the first diagnosis list may also include supporting or opposing evidence (reasoning) for the first hypothetical diagnosis.

[0062] In this embodiment, steps 102-104 are triggered when the first diagnosis list contains two or more first hypothetical diagnoses. If the first diagnosis list contains only one first hypothetical diagnosis, then the candidate question related to that first hypothetical diagnosis can be directly used as the first consultation question.

[0063] Furthermore, in combination Figure 2 The method provided in this embodiment may further include the following steps: 109. Add the first diagnosis list to the status data to read the first diagnosis list from the status data before selecting at least two first hypothetical diagnoses from the first diagnosis list.

[0064] The state data is continuously updated within the loop to constantly improve the user's information. For example, the method may also include the following steps: 110. Extract a second clinical feature from the user's response information to the first consultation question; 111. Update the status data based on the second clinical feature to obtain the updated status data; 112. Using the knowledge base, determine the second disease information related to the updated state data; 113. Input the updated status data and the second disease information into the large language model, and generate a second diagnosis list from the large language model; wherein, the second diagnosis list includes multiple second hypothetical diagnoses and the confidence levels corresponding to the second hypothetical diagnoses; 114. If the second diagnostic list contains a second hypothetical diagnosis with a confidence level greater than the threshold, then the updated state data is updated again based on the second diagnostic list to obtain the state data as the output result. 115. If there is no second hypothetical diagnosis with a confidence level greater than the threshold in the second diagnosis list, then at least two second hypothetical diagnoses are selected from the plurality of second hypothetical diagnoses, and a second consultation question is determined for the at least two second hypothetical diagnoses.

[0065] Furthermore, this embodiment may also include the following steps: 116. Input the state data as the output result into the first preset model, and the first preset model outputs the consultation result in a format that conforms to the standard framework of evidence-based medicine.

[0066] The first preset model can be a large language model or other models capable of text formatting; this embodiment does not specifically limit its application. It follows an evidence-based medicine framework, such as PICO (Patient-Intervention-Control-Outcome). Here, the first preset model outputs consultation results conforming to the corresponding PICO output format, facilitating seamless integration of the consultation results into subsequent treatment or reporting modules. Alternatively, the first preset model can also output text similar to a consultation report based on the aforementioned status data as output.

[0067] Furthermore, the solution provided in this embodiment also pre-constructs a symptom complaint flow (SCC Flow). This symptom complaint flow can be stored in a knowledge base. Accordingly, the method provided in this embodiment may further include the following steps: 117. Utilize a pre-built symptom complaint process to interact with the user and obtain the complaint information.

[0068] For example, consultation and information collection services interact with users according to the steps defined in the symptom complaint process. For instance, after a user complains of a "headache," the symptom complaint process first asks some questions to rule out urgent situations, checking for alarm symptoms to ensure safety; then, following the steps defined in the symptom complaint process, it asks the user "location of pain," and after the user answers the specific location, it asks the user "how long has it been like this," and so on.

[0069] Furthermore, the solution provided in this embodiment can adopt a "parallel exploration" mechanism, that is, step 103 "diagnosing relevant candidate questions for the at least two first hypotheses respectively, forming a candidate question set" includes the following steps: 1031. Load the consultation processes corresponding to the at least two first hypothetical diagnoses in parallel; 1032. From the consultation process corresponding to the at least two first hypothetical diagnoses, extract the candidate questions corresponding to the at least two first hypothetical diagnoses respectively, and form the candidate question set.

[0070] The "parallel exploration" mechanism (loading multiple consultation processes in parallel and extracting candidate questions from each consultation process) combined with "extracting consultation questions from a large language model" in this embodiment enables the large language model to have a global perspective during the consultation process, and to weigh and distinguish between multiple diagnostic possibilities in order to quickly identify key issues and improve consultation efficiency.

[0071] The clinical features-disease index, symptom-complaint flow (SCC Flow), and consultation flow (DS Flow) mentioned above can be pre-built and stored in a knowledge base. For example, this embodiment also includes a step of offline knowledge base construction. Specifically, this embodiment may also include the following steps: Using a second pre-defined model, multi-channel medical data are processed to construct a clinical feature-disease index; and / or Using a third pre-defined model, medical data from multiple channels is processed to construct a symptom complaint process; and / or The fourth preset model is used to process medical data from multiple channels and construct a consultation process.

[0072] The second, third, and fourth preset models can be models of different types, partially identical, or entirely identical. This embodiment does not limit the specific implementation of the second, third, and fourth preset models. For example, they can be, for instance, large language models.

[0073] The aforementioned multi-channel medical resources may include, but are not limited to, clinical guidelines, diagnostic textbooks, and other materials. In practice, a corresponding "symptom complaint process" can be constructed for different symptoms. For example, a corresponding "symptom complaint process" can be constructed for "pain," and a corresponding "symptom complaint process" can be constructed for "fever." Of course, a "symptom complaint process" can also be constructed without targeting specific symptoms, and a larger, more comprehensive "symptom complaint process" can be built based on multi-channel medical resources. The consultation process (consultation logic and questions) differs for different diagnoses; therefore, when constructing the consultation process, a corresponding consultation process can be constructed for each different diagnosis.

[0074] In related technologies, intelligent consultation paths are often rigid or suffer from logical "black box" defects (unexplainable and untraceable). This specification provides a consultation method that dynamically updates status data and then updates the diagnosis list based on the updated status data. This allows for the determination of consultation questions based on the updated diagnosis list, quickly identifying key issues and rapidly pinpointing the target diagnosis. This specification's solution integrates knowledge flow (such as symptom complaint flow, clinical feature-disease index, and consultation process) with a large language model. By simulating expert "MDT chairperson" decision-making, it selects the "key question" that maximizes information gain from multiple diagnostic hypotheses, achieving a Bayesian iterative diagnostic loop. This solution overcomes the rigidity and blindness of traditional methods, making the consultation process efficient, accurate, and interpretable. It highly simulates expert diagnostic thinking and has significant innovative and practical value in the field of artificial intelligence in medicine.

[0075] The following is a systematic description of the solutions provided in the embodiments of this specification.

[0076] This solution is divided into two main modules: an offline module and an online module.

[0077] The offline module is used to process multi-channel medical information (such as unstructured clinical guidelines, diagnostic materials, and other knowledge sources) into structured and executable consultation processes (such as symptom complaint processes and consultation processes); it is also used to build knowledge indexes (such as clinical feature-disease indexes); and to store consultation processes and knowledge indexes in a knowledge base (such as a knowledge graph).

[0078] The online module is used to invoke processes or indexes in the knowledge base when interacting with users, and to perform the consultation through a dynamic iterative loop.

[0079] Another embodiment of the medical history taking method provided in this specification includes the following steps: Step 1: Initiation and Initial Information Gathering (Symptom Chief Complaint - SCC Flow) Figure 2 (Symptom complaint stage in the example shown) 1.1 Startup See Figure 2 The consultation and information collection service responds to the user's input of chief complaint information (such as "stomach pain for a year"), queries a pre-set index (such as chief complaint symptoms - symptom chief complaint process index), queries and loads the symptom chief complaint process (SCC Flow-abdominal_pain) corresponding to "abdominal pain".

[0080] 1.2 Information Collection The consultation and information collection service follows the steps defined in the symptom complaint process (i.e., interacting with the user). This symptom complaint process first checks for alarm symptoms to ensure safety, and then collects basic information about the condition, such as the location, nature, and timing of the pain.

[0081] 1.3 Storage The consultation and information collection service structures the user's chief complaint information (i.e., all information collected after interacting with the user using the symptom-complaint process) and stores it in a dynamic PatientState object (corresponding to the first state data mentioned in the above embodiment). For simplicity, it will be referred to as PatientState in the following text.

[0082] Step Two: Evidence-Anchored DDx Generation (i.e., Figure 2 (Hypothesis generation phase in the example shown) 2.1 Clue Inquiry 2.1.1 Determine disease information based on PatientState.

[0083] The consultation and information collection service extracts collected clinical features from the PatientState, such as "pain location: upper abdomen" and "PPI trial response: ineffective". The service then calls the knowledge base service to query the offline-built clinical feature-disease index to obtain at least one disease associated with the aforementioned clinical features. The disease information includes the at least one disease obtained.

[0084] 2.1.2. Using a large language model, generate a diagnostic list ddx_hypothesis based on PatientState and disease information.

[0085] The consultation and information collection service calls the large language model service, which generates a diagnosis list (ddx_hypothesis). PatientState and the previously queried set of diseases (i.e., disease information) are input into the large language model. At this point, the large language model acts as a "diagnostic expert," processing PatientState and the previously queried set of diseases to generate a diagnosis list sorted by probability and containing diagnostic criteria. This diagnosis list, ddx_hypothesis, contains at least one hypothesized diagnosis.

[0086] 2.2 Status Update Store the diagnosis list ddx_hypothesis into PatientState to obtain the updated PatientState.

[0087] Step 3: Focus on Validation and Iterative Optimization (The Core Loop) Figure 2 (Verification and Iteration Phase of the Example) The following loop starts when PatientState contains two or more hypothetical diagnoses.

[0088] See Figure 4 The loop flowchart shown is as follows: 3.1. Obtain the list of diagnoses ddx_hypothesis in PatientState.

[0089] For example, the diagnostic list ddx_hypothesis: {functional dyspepsia, 60%; gastroesophageal reflux, 30%; other, 10%}. The percentage following each hypothetical diagnosis in the list represents the confidence level of that diagnosis. Of course, the diagnostic list may also contain evidence supporting or opposing any hypothetical diagnosis, which is not shown here.

[0090] 3.2 Select the Top-N high-confidence hypothesis diagnoses from the diagnosis list ddx_hypothesis.

[0091] Where N is a natural number greater than or equal to 2. For example, the top two hypothetical diagnoses with the highest confidence levels are: functional dyspepsia and gastroesophageal reflux.

[0092] 3.3. Parallel loading of diagnostic processes (DS Flow) corresponding to N hypothetical diagnoses.

[0093] For example, the diagnostic process for "functional dyspepsia" and the diagnostic process for "gastroesophageal reflux" can be loaded in parallel.

[0094] 3.4 Extract candidate questions from the DS Flow corresponding to the N loaded hypothesis diagnoses to form a candidate question set.

[0095] Extract a candidate question A from the diagnostic process corresponding to "functional dyspepsia", such as "Do you feel full early, feel full after only a few bites, and are unable to finish a normal meal?"; select a candidate question B from the diagnostic process corresponding to "gastroesophageal reflux", such as "Do you experience acid reflux and heartburn?"

[0096] The above questions are grouped into a candidate question set {candidate question A, candidate question B}.

[0097] If the diagnostic process corresponding to "functional dyspepsia" is loaded again in the next cycle, since candidate question A "Do you have early satiety, ..." has been extracted in this cycle, a question that has not been extracted downstream of candidate question A in the diagnostic process will be extracted as the candidate question for the next cycle.

[0098] 3.5. Provide the diagnostic list ddx_hypothesis and candidate question set to the large language model (such as LLM) of the "MDT Chair" role to determine the diagnostic questions.

[0099] The consultation and information collection service utilizes the large language model service. Specifically, it uses the large language model to evaluate which question in the candidate question set is most effective in distinguishing between "functional dyspepsia" and "gastroesophageal reflux." For example, the large language model might determine that candidate question B, "Do you have acid reflux and heartburn?", is more effective in distinguishing between "functional dyspepsia" and "gastroesophageal reflux" than candidate question A, "Do you have early satiety...". Therefore, the large language model will select candidate question B as the consultation question.

[0100] In some embodiments, after the large language model outputs the consultation question, it can also output the reason for the decision, such as the reason for selecting candidate question B from the candidate question set as the consultation question.

[0101] 3.6. Asking Questions and Status Updates

[0102] The inquiry and information collection service presents users with medical questions through an interactive interface. In response to the user's answer to the question, the service updates the PatientState to add the new information from the user's answer to the PatientState.

[0103] 3.7 Bayesian-like Updates and Loops After updating PatientState, return to step two. Using the updated PatientState, retrieve a set of diseases through a query; then, use the large language model to process the updated PatientState and the corresponding set of diseases to regenerate the diagnosis list. Update PatientState using the regenerated diagnosis list. A Bayesian-like update: The new information in PatientState serves as new evidence. Returning to step two, the large language model re-evaluates the confidence levels of multiple hypothetical diagnoses in the diagnosis list of PatientState, updating the posterior probability. Because new evidence is input into the large language model, the confidence levels of multiple hypothetical diagnoses will fluctuate, achieving an effect similar to a Bayesian update.

[0104] See Figure 5In the example shown, the diagnosis list ddx_hypothesis in PatientState is obtained; based on the diagnosis list, it is determined whether the convergence condition is met. If it is met, the loop terminates; otherwise, step three is executed to determine the consultation question based on PatientState in order to collect more information and continuously update PatientState.

[0105] The convergence condition can be, but is not limited to, the following: the diagnosis list contains hypothetical diagnoses with a confidence level greater than a threshold. The threshold can be 80%, 90%, etc., and this embodiment does not limit this.

[0106] Step Four: Termination and Handover The consultation and information collection service continuously updates the PatientState with comprehensive and rich information throughout the entire process, providing it to subsequent services such as treatment plan recommendation services and / or report generation services. Before providing PatientState to subsequent services, the consultation and information collection service can perform format conversion on PatientState, for example, converting it into a structured PICO object.

[0107] For example, a pre-trained language model service can be invoked, utilizing one of the large language models focused on format conversion to convert PatientState into a PICO object.

[0108] In summary, this embodiment has at least the following beneficial effects: 1. Because this embodiment pre-constructs a clinical feature-disease index, symptom complaint process, and diagnostic process, such as the symptom complaint process as guidance in the symptom complaint stage and the clinical feature-disease index and diagnostic process as guidance in the hypothesis generation stage, the information provided to the large language model is more accurate. In this way, the information output by the large language model (such as consultation questions, diagnosis lists, etc.) will not deviate from the recommended path of clinical guidelines, and there will be no situation of raising unsafe or irrelevant questions. Moreover, the evidence-based nature of the entire consultation process is well guaranteed.

[0109] 2. In this embodiment, a candidate question set is determined using clinical features-disease index and diagnostic process. This candidate question set is then provided to the large language model to determine the consultation questions, rather than having the large language model "create" consultation questions from scratch. Therefore, the computational overhead of the large language model in this embodiment is low, and the determined consultation questions are more valuable, helping to quickly pinpoint the target diagnosis with high accuracy, efficiency, and reliability.

[0110] 3. In this embodiment, the large language model selects a candidate question that meets the information gain requirement from the candidate question set as the diagnosis question. This cleverly utilizes its powerful semantic understanding and contextual reasoning capabilities to approximate the complex information gain calculation, saving the cost of training a dedicated computational model (a model that calculates the information gain corresponding to each question). Moreover, the semantic understanding and contextual reasoning capabilities of the large language model are difficult for some computational models to match.

[0111] 4. The solution provided in this embodiment employs a parallel exploration mechanism, which loads N hypothetical diagnoses and their corresponding diagnostic processes in parallel, extracting candidate questions from these N processes. This parallel exploration mechanism does not solely focus on the top-ranked hypothetical diagnosis but also considers multiple top-ranked hypothetical diagnoses (such as Top 2 or Top 3); it extracts the next logical question from the loaded multiple DS Flows, forming a candidate question set. Therefore, the "parallel exploration mechanism" is not only efficient but also provides a more comprehensive view of the consultation process, enabling the weighing and differentiation among multiple hypothetical diagnoses, much like the logic of a professional doctor's consultation. Related technologies typically determine the error of one hypothetical diagnosis through the diagnostic process before judging the accuracy of another. This embodiment avoids wasting significant interactions on an incorrect path because parallel exploration identifies the most distinguishing question between different hypothetical diagnoses, greatly shortening consultation time and enabling diagnosis in a shorter period.

[0112] 5. The consultation path in this embodiment is not preset but dynamically generated. During the verification and iteration phases, the next consultation question is dynamically determined by the large language model based on continuously updated state data (such as PatientState). As the state data is constantly updated, the corresponding parallel-loaded diagnostic processes will change, and the candidate questions extracted according to the loaded diagnostic processes will also differ. Therefore, this embodiment greatly improves the flexibility of the path and its adaptability to complex conditions. Due to its high dynamic adaptability (able to adjust consultation questions based on the patient's unique answers), this embodiment can handle atypical cases and complex situations.

[0113] 6. This embodiment of the solution possesses the characteristics of clear logic, interpretability, and traceability. Each inquiry (providing feedback to the user regarding their medical questions) has a clear and traceable strategic objective (e.g., in the above example, to differentiate between "functional dyspepsia" and "gastroesophageal reflux"), rather than random or aimless interaction. Specifically, this embodiment of the solution demonstrates interpretability and traceability in at least the following aspects: The generation of the diagnostic list uses clinical features-disease indexes as evidence-based clues.

[0114] Each hypothetical diagnosis in the diagnostic list is accompanied by supporting or opposing evidence.

[0115] When selecting a diagnostic question, the large language model can output its decision rationale.

[0116] The symptom-complaint flow (SCC Flow) or diagnostic flow (DS Flow) upon which the consultation process is based is linked to a specific guideline recommendation through an identifier (such as justified_by_recommendation_id).

[0117] 7. This embodiment's solution is not merely about "retrieving" knowledge, but rather about "executing" and "navigating" knowledge that has been compiled into a structured process. This embodiment proactively plans how to invoke knowledge base services and large language model services at different stages. This embodiment's solution has high diagnostic efficiency; the identified diagnostic questions can quickly rule out or confirm some diagnoses with fewer interactions, significantly shortening diagnostic time and improving consultation efficiency. This has immense practical value in clinical applications.

[0118] The solutions provided in the embodiments of this specification adopt a hybrid architecture (such as...). Figure 2The example shown does not simply use a large language model as a dialogue interface, but rather embeds it as a decision engine within a framework comprised of structured, executable knowledge flows (such as SCC Flow, DS Flow, and clinical feature-disease index). The structured flow ensures the evidence-based, safe, and logical nature of the consultation; while the large language model endows the system with dynamic reasoning and adaptability at key decision points (such as generating a diagnosis list and determining the consultation question). The embodiments in this specification propose using a large language model to simulate the decision-making process of a multidisciplinary team (MDT) chairperson. By inputting a diagnosis list and a set of candidate questions from multiple diagnostic flows, the large language model selects a candidate question as the consultation question with the goal of maximizing information gain. This successfully transforms the clinical expert's diagnostic strategy (maximizing information gain) into a computable and executable module. The embodiments in this specification construct a closed-loop, Bayesian-like iterative process: generating a diagnosis list → candidate question set → determining the consultation question and asking it → updating evidence → regenerating the diagnosis list. It dynamically maintains a state data point called PatientState and continuously collects new evidence through strategic questioning in each round, updating the confidence levels corresponding to each hypothetical diagnosis until the diagnosis converges. This cyclical mechanism highly simulates the cognitive process of expert physicians when facing uncertainty. The embodiments in this specification also provide an offline knowledge construction method, such as using a pre-defined model (e.g., a large language model) to "reverse engineer" PICO evidence and diagnostic textbook logic from medical data into executable DS Flow and SCC Flow, and creating a feature_to_disease_index (clinical feature-disease index). This index serves as a bridge connecting symptom collection and evidence-based hypothesis generation, ensuring that the generation of the diagnostic list is based on solid evidence from the outset.

[0119] This specification provides an exemplary embodiment of a medical consultation device. See also: Figure 6The example shown illustrates a diagnostic device comprising: a determination module 11, a selection module 12, a processing module 13, and a feedback module 14. The determination module 11 determines a first diagnostic list based on the user's chief complaint; the first diagnostic list includes multiple first hypothetical diagnoses, each representing a possible diagnostic result generated by a large language model for the user's chief complaint. The selection module 12 selects at least two first hypothetical diagnoses from the multiple first hypothetical diagnoses based on their confidence levels. The determination module 11 further determines relevant candidate questions for each of the at least two first hypothetical diagnoses, forming a candidate question set. These relevant candidate questions are used to verify or exclude the corresponding first hypothetical diagnoses. The processing module 13 uses the large language model to select candidate questions from the candidate question set that can change the confidence levels of the at least two first hypothetical diagnoses as first diagnostic questions. The feedback module 14 provides feedback on the first diagnostic questions based on the chief complaint information.

[0120] It should be noted that the devices provided in the above embodiments can implement the technical solutions described in the corresponding method embodiments above. The specific implementation principles and corresponding beneficial effects of the above modules or units can be found in the corresponding content of the above method embodiments, and will not be repeated here.

[0121] This specification also provides an electronic device according to one embodiment. For example... Figure 7 As shown, the electronic device includes a processor 22 and a memory 21. The memory 21 stores one or more computer programs; the processor 22 is coupled to the memory 21 and is used for the at least one or more computer programs to implement the steps in the methods provided in the embodiments of this specification.

[0122] The aforementioned memory 21 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk.

[0123] Furthermore, the electronic device also includes other components such as a communication component 23, a display 24, a power supply component 25, and an audio component 26. Only some components are shown here for illustrative purposes, and it is not intended that the electronic device contains only these components.

[0124] Accordingly, embodiments of this specification also provide a computer-readable storage medium storing a computer program, which, when executed by a computer, can implement the method steps or functions provided in the embodiments of this specification described above.

[0125] The methods in this specification can be implemented, in whole or in part, by software, hardware, firmware, or any combination thereof. When implemented in software, they can be implemented, in whole or in part, as a computer program product. Therefore, this specification also provides a computer program product. This computer program product includes a computer program / instructions that, when executed by an electronic component such as a processor, can perform, in whole or in part, the steps or functions of the methods provided in the embodiments of this specification. The computer can be a general-purpose computer, a special-purpose computer, a computer network, network equipment, user equipment, core network equipment, OAM, or other programmable device.

[0126] The aforementioned memory can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0127] The aforementioned display includes a screen, which may include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the screen includes a Touch Panel, the screen can be implemented as a touchscreen to receive input signals from the user. The Touch Panel includes one or more touch sensors to sense touches, swipes, and gestures on the Touch Panel. The touch sensors can sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation.

[0128] The aforementioned power supply components provide power to various components within the device in which they reside. These power supply components may include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power to the device in which they reside.

[0129] The aforementioned audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC) configured to receive external audio signals when the device containing the audio component is in an operating mode, such as call mode, recording mode, or voice recognition mode. The received audio signals can be further stored in memory or transmitted via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals.

[0130] Accordingly, embodiments of this specification also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, enables the processor to implement the steps in the above-described method embodiments. The computer-readable storage medium includes volatile or non-volatile or a combination thereof, and can be removable or non-removable. Examples of computer-readable storage media include, but are not limited to, phase-change random access memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random-access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), flash memory or other memory technologies, CD-ROM, Digital Video Disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium. Accordingly, embodiments of this specification also provide a computer program product, which includes a computer program or instructions that, when executed by a processor, cause the processor to implement the steps in the above-described method embodiments. It should be understood that each step or combination of steps in the above-described method flow can be implemented by the computer program or instructions. Furthermore, these computer programs or instructions can be applied to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device, enabling the processor of the general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device to function as an apparatus for implementing the corresponding functions in the above-described method embodiments.

[0131] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0132] The above are merely embodiments of this specification and are not intended to limit this specification. Various modifications and variations can be made to this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims of this specification.

Claims

1. A method for taking medical history, characterized in that, include: Based on the user's chief complaint, determine the first diagnostic list; The first diagnostic list includes multiple first-hypothesis diagnoses, which represent multiple possible diagnostic results generated by the large language model for the user's complaint; Based on the confidence level of the plurality of first hypothesis diagnoses, at least two first hypothesis diagnoses are selected from the plurality of first hypothesis diagnoses; For each of the at least two first hypothesis diagnoses, relevant candidate questions are determined to form a candidate question set, and the relevant candidate questions are used to verify or exclude the corresponding first hypothesis diagnoses; Using a large language model, candidate questions that can change the diagnostic confidence of at least two first hypotheses are selected from the candidate question set as the first consultation question; Provide feedback on the first consultation question.

2. The method according to claim 1, characterized in that, Also includes: In response to the user's answer to the first consultation question, a second diagnosis list is determined; wherein, the second diagnosis list includes multiple second hypothetical diagnoses and the confidence levels corresponding to the second hypothetical diagnoses; If the second diagnosis list contains a second hypothetical diagnosis with a confidence level greater than the threshold, then the second diagnosis list will be used as the basis for generating the consultation results. If there is no second hypothetical diagnosis with a confidence level greater than the threshold in the second diagnosis list, then at least two second hypothetical diagnoses are selected from the plurality of second hypothetical diagnoses, and a second consultation question is determined for the at least two second hypothetical diagnoses.

3. The method according to claim 1, characterized in that, Based on the user's chief complaint, a primary diagnostic list is determined, including: Based on the aforementioned complaint information, status data representing the user's state is generated; Using a knowledge base, first disease information related to the state data is determined; The status data and the first disease information are input into the large language model, and the large language model generates the first diagnosis list.

4. The method according to claim 3, characterized in that, The knowledge base includes a clinical features-disease index; as well as Using a knowledge base, first disease information related to the state data is determined, including: Extract at least one clinical feature from the status data; The clinical feature-disease index is queried to obtain at least one disease related to the at least one clinical feature, thereby forming the first disease information.

5. The method according to claim 3, characterized in that, Also includes: The first diagnosis list is added to the status data to read the first diagnosis list from the status data before selecting at least two first hypothetical diagnoses from the first diagnosis list.

6. The method according to claim 5, characterized in that, Also includes: Extract the second clinical feature from the user's response to the first consultation question; The status data is updated based on the second clinical feature to obtain the updated status data; Using the knowledge base, second disease information related to the updated state data is determined; The updated state data and the second disease information are input into the large language model, which generates a second diagnosis list; wherein, the second diagnosis list includes multiple second hypothetical diagnoses and the confidence levels corresponding to the second hypothetical diagnoses; If the second diagnosis list contains a second hypothesis diagnosis with a confidence level greater than the threshold, the updated state data is updated again based on the second diagnosis list to obtain the state data as the output result. If there is no second hypothetical diagnosis with a confidence level greater than the threshold in the second diagnosis list, then at least two second hypothetical diagnoses are selected from the plurality of second hypothetical diagnoses, and a second consultation question is determined for the at least two second hypothetical diagnoses.

7. The method according to claim 6, characterized in that, Also includes: The state data, which is the output result, is input into the first preset model, and the first preset model outputs the consultation result in a format that conforms to the standard framework of evidence-based medicine.

8. The method according to any one of claims 1 to 7, characterized in that, Also includes: The system utilizes a pre-built symptom complaint process to interact with the user and obtain the complaint information.

9. The method according to any one of claims 1 to 7, characterized in that, From the plurality of first hypothesis diagnoses, at least two first hypothesis diagnoses are selected, including: From the plurality of first hypothesis diagnoses, select a predetermined number of first hypothesis diagnoses with the highest confidence level; Wherein, the set quantity is greater than or equal to 2.

10. The method according to any one of claims 1 to 7, characterized in that, For each of the at least two first hypothesis diagnoses, relevant candidate questions are identified to form a candidate question set, including: The consultation processes corresponding to the at least two first hypothetical diagnoses are loaded in parallel. From the consultation process corresponding to the at least two first hypothetical diagnoses, candidate questions corresponding to the at least two first hypothetical diagnoses are extracted to form the candidate question set.

11. The method according to claim 10, characterized in that, Also includes: Using the second pre-set model, medical data from multiple channels are processed to construct a clinical feature-disease index; and / or Using a third pre-defined model, medical data from multiple channels are processed to construct a symptom complaint process; and / or The fourth preset model is used to process medical data from multiple channels and construct a consultation process; Among them, the second preset model, the third preset model and the fourth preset model are different types of models, some are the same models or all are the same models.

12. A medical consultation device, characterized in that, include: The determination module is used to determine the first diagnostic list based on the user's chief complaint information; The first diagnostic list includes multiple first-hypothesis diagnoses, which represent multiple possible diagnostic results generated by the large language model for the user's complaint; A selection module is used to select at least two first hypothesis diagnoses from the plurality of first hypothesis diagnoses based on the confidence level of the first hypothesis diagnoses; The determining module is further configured to determine relevant candidate questions for each of the at least two first hypothesis diagnoses, forming a candidate question set, wherein the relevant candidate questions are used to verify or exclude the corresponding first hypothesis diagnoses; The processing module is used to select, using a large language model, candidate questions that can change the diagnostic confidence of at least two first hypotheses as first consultation questions from the candidate question set; The feedback module is used to provide feedback on the first consultation question.

13. A consultation system, characterized in that, include: The client is used to provide the interactive interface; The server is used to execute the steps in the consultation method according to any one of claims 1 to 11.

14. An electronic device, characterized in that, Includes memory and processor; among which, The memory is used to store executable instructions; The processor executes the executable instructions to implement the steps of the consultation method as described in any one of claims 1 to 11.

15. A computer-readable storage medium, characterized in that, The storage medium stores computer instructions that, when executed by a processor, can perform the steps of the consultation method as described in any one of claims 1 to 11.

16. A computer program product, characterized in that, The computer program product includes a computer program or instructions that, when executed by a processor, cause the processor to perform the steps of the consultation method as described in any one of claims 1 to 11.

Images