Intelligent processing of medical exclusion conditions, apparatus, and electronic device

Abstract

The disclosure provides an intelligent processing of medical screening conditions, and relates to the technical field of data processing, in particular to the technical field of medicine, databases, data queries and the like. The specific implementation scheme is: performing semantic intention analysis on a natural language description of a medical screening condition input by a user, and converting the natural language description into a structured intermediate representation, wherein the intermediate representation includes a plurality of structured condition units and their logical relationships, and one structured condition unit corresponds to one medical screening condition; based on a preset medical field knowledge ontology library, traversing each structured condition unit of the intermediate representation, and converting the intermediate representation into an executable database query statement based on the traversal result; executing the database query statement to obtain a data result; and generating explanatory evidence information connecting the natural language description and the data result according to the association information of the intermediate representation and the database query statement execution process.

Description

Technical Field

[0001] This disclosure relates to the field of data processing technology, and in particular to the fields of medicine, databases, and data querying. Background Technology

[0002] In clinical research, researchers typically describe medical inclusion and exclusion criteria in natural language. These criteria often involve complex medical logic and knowledge domain barriers, leading to inaccurate results. Current technologies exhibit multiple gaps between the natural language descriptions of medical inclusion and exclusion criteria and the execution of clinical database queries: for example, a semantic understanding gap, as general natural language processing (NLP) techniques lack deep integration with clinical domain knowledge, failing to accurately translate natural language intent into structured query logic; and a result tracing gap, where a traceable and interpretable chain of evidence exists between the query results and the original medical inclusion and exclusion criteria, making it difficult to quickly pinpoint the root cause when results are questionable. These problems result in inefficient patient screening processes and compromised accuracy. Summary of the Invention

[0003] This disclosure provides an intelligent processing method, apparatus, and electronic device for solving at least one of the above-mentioned technical problems related to medical inclusion and exclusion conditions.

[0004] According to a first aspect of this disclosure, an intelligent processing method for medical intake and discharge conditions is provided, wherein the method includes: The medical inclusion and exclusion conditions described in natural language input by the user are semantically interpreted and converted into a structured intermediate representation. The intermediate representation contains multiple structured condition units and their logical relationships, and one structured condition unit corresponds to one medical inclusion and exclusion condition. Based on a pre-defined medical domain knowledge ontology, the structured conditional units of the intermediate representation are traversed, and the intermediate representation is converted into an executable database query statement based on the traversal results. Execute the database query statement to obtain the data results; Based on the association information between the intermediate representation and the execution process of the database query statement, explanatory evidence information connecting the natural language description and the data results is generated.

[0005] According to a second aspect of this disclosure, an intelligent processing device for medical intake and discharge conditions is provided, wherein the device comprises: The intermediate representation conversion module is used to perform semantic intent parsing on the medical inclusion and exclusion conditions described in natural language input by the user and convert them into a structured intermediate representation. The intermediate representation contains multiple structured condition units and their logical relationships, and one structured condition unit corresponds to one medical inclusion and exclusion condition. The query statement conversion module is used to traverse each structured condition unit of the intermediate representation based on a preset medical domain knowledge ontology, and convert the intermediate representation into an executable database query statement based on the traversal results. The data structure module is used to execute the database query statement and obtain the data result; An interpretability module is used to generate interpretive evidence information that connects the natural language description and the data results based on the association information between the intermediate representation and the execution process of the database query statement.

[0006] According to a third aspect of this disclosure, an electronic device is provided, comprising: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the above-described method.

[0007] According to a fourth aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are used to cause the computer to perform the method described above.

[0008] According to a fifth aspect of this disclosure, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the method described above.

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

[0010] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein: Figure 1 This is a flowchart illustrating an intelligent processing method for medical intake and discharge conditions provided in the first embodiment of this disclosure; Figure 2 This is a schematic diagram of an exemplary S101 process; Figure 3 This is a schematic diagram of an exemplary S102 process; Figure 4 This is a schematic diagram of an exemplary S104 process; Figure 5 This is a schematic diagram of the structure of an intelligent processing device for medical intake and discharge conditions provided in the second embodiment of this disclosure; Figure 6This is a block diagram of an electronic device used to implement the methods of the embodiments of this disclosure. Detailed Implementation

[0011] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0012] Where there is no conflict, the various embodiments of this disclosure and the features thereof in the embodiments may be combined with each other.

[0013] As used herein, the term “and / or” includes any and all combinations of one or more related enumerated entries.

[0014] The terminology used herein is for describing particular embodiments only and is not intended to limit this disclosure. As used herein, the singular forms “a” and “the” are also intended to include the plural forms unless the context clearly indicates otherwise.

[0015] Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and this disclosure, and will not be interpreted as having an idealized or overly formal meaning, unless expressly so defined herein.

[0016] The intelligent processing method for medical exclusion conditions according to this disclosure can be executed by electronic devices such as terminal devices or servers. Terminal devices can be in-vehicle devices, user equipment (UE), mobile devices, user terminals, terminals, cellular phones, cordless phones, personal digital assistants (PDAs), handheld devices, computing devices, in-vehicle devices, wearable devices, etc. The method can be implemented by a processor calling computer-readable program instructions stored in memory. Alternatively, the intelligent processing method for medical exclusion conditions provided in this disclosure can be executed by a server.

[0017] In the first disclosed embodiment, see Figure 1 , Figure 1 This diagram illustrates a flowchart of an intelligent processing method for medical intake and discharge conditions according to a first embodiment of the present disclosure. The method includes: S101. Perform semantic intent parsing on the medical inclusion and exclusion conditions described in natural language input by the user, and convert them into a structured intermediate representation. The intermediate representation contains multiple structured condition units and their logical relationships. One structured condition unit corresponds to one medical inclusion and exclusion condition.

[0018] This step aims to address the semantic understanding gap between natural language and database queries in existing technologies. Specifically, the system receives inclusion and exclusion conditions described by users in free text form (i.e., natural language form), which contain complex medical logic and semantics.

[0019] Among them, medical inclusion and exclusion criteria refer to the inclusion and exclusion criteria used to screen research subjects in clinical research. These criteria are described by the user in natural language and include medical constraints such as disease diagnosis, symptoms, signs, examination indicators, and time range. For example, the user can enter "Include research subjects who are over 60 years old and have not undergone any surgery in the past year, and who have no history of myocardial infarction."

[0020] Semantic intent parsing refers to the process of deeply understanding medical inclusion and exclusion conditions in natural language form, extracting core medical entities, logical relationships and constraint information, and transforming ambiguous natural language intent into structured information that can be recognized by machines.

[0021] Structured intermediate representation refers to a structured data form that can accurately represent the semantics of medical inclusion and exclusion conditions. It serves as a bridge connecting natural language and database query statements. It contains multiple structured condition units and logical relationships between units, such as AND, OR, and NOT. Each structured condition unit corresponds to a specific inclusion and exclusion constraint.

[0022] Users input medical inclusion and exclusion conditions in natural language through the system's front-end input interface. These conditions can contain multiple layers of logical nesting, complex temporal semantics, and various medical entities. This step initiates the semantic intent parsing process, which can be divided into two stages: coarse parsing and fine parsing, to ensure the accuracy of semantic understanding. Specifically: In the coarse parsing stage, a lightweight natural language processing model (such as an NLP model) pre-trained on medical corpus is invoked to perform preliminary entity recognition on the input text, filtering out potential medical entities such as diseases, symptoms, ages, and time ranges. In addition, a medical domain knowledge ontology is invoked in real time to perform context-dependent concept disambiguation and multi-dimensional normalization on the pre-identified entities, standardizing ambiguous expressions into unified medical concepts and assigning unique ontology concept identifiers, filtering ambiguous entities, generating high-dimensional feature sequences, and achieving effective decoupling of knowledge processing and semantic structure parsing.

[0023] In the fine-tuning stage, the standardized entity information obtained from the coarse-parsed analysis, the complete data model information of the current research project, and the mapping rules of the medical domain knowledge ontology are input together into a large-scale language model (LLM) fine-tuned from the medical research corpus. The core task of LLM is to parse the logical relationships in natural language, including multi-level nested relationships, map each standardized entity information to a corresponding structured conditional unit, and construct a structured intermediate representation according to the logical relationships.

[0024] The final intermediate representation accurately represents structured conditional units (also known as atomic conditions), logical operators, and their hierarchical relationships in a structured form. Each structured conditional unit can contain key information such as ontology concept identifiers, database field candidate lists, comparison operators, value ranges, and relative time parameters, providing standard input for subsequent machine processing and also allowing users to edit the intermediate representation visually.

[0025] S102. Based on a pre-defined medical domain knowledge ontology, traverse each structured condition unit of the intermediate representation, and convert the intermediate representation into an executable database query statement based on the traversal results.

[0026] This step aims to address the transformation from validated semantic intents to standardized, executable query statements. The system receives an intermediate representation that has been confirmed or modified by the user and automatically constructs the query through deep integration and dynamic invocation of rules from a medical domain knowledge ontology.

[0027] The medical knowledge ontology is a structured knowledge system that may include core components such as a medical terminology thesaurus, disease-symptom-drug association rules, time window calculation specifications, and database field mapping rules. It supports medical entity normalization, semantic parsing, and query generation. It can contain at least three layers: a concept layer storing medical terms and their standard conceptual identifiers; a mapping layer storing the mapping relationships between conceptual identifiers and specific database tables and fields, as well as value domain conversion rules; and a rule layer storing medical logical association rules and optimization rules between tables.

[0028] Database query statements refer to query instructions that conform to database syntax specifications and can be executed directly in clinical databases, such as structured query language (SQL), which is used to filter patient data from the database that meet inclusion and exclusion criteria.

[0029] Specifically, each structured condition unit can be traversed sequentially according to the hierarchical structure of the structured intermediate representation, such as the tree-like order of the ingress and egress condition tree, initiating the transformation process from semantics to query. The entire process dynamically invokes a medical domain knowledge ontology to ensure accuracy and efficiency. Specifically, this can include: Field-to-table mapping: For each structured condition unit, the medical domain knowledge ontology is queried through its ontology concept identifier to obtain the corresponding target database table and field mapping relationship. For example, "myocardial infarction" corresponds to "diagnosis record table.D10 code". The validity of the field is confirmed by combining the project data model information to complete the semantic-to-physical data mapping.

[0030] The system performs logical and temporal conversion, parses the logical relationships between structured conditional units, and automatically derives table join relationships and generates join statements based on predefined medical logic rules in the medical domain knowledge ontology, such as "the patient basic information table and the diagnosis record table are associated through patient identifiers". It converts the relative time parameters in the structured conditional units into date calculation expressions in the target database dialect, and converts comparison operators and value ranges into valid query condition clauses.

[0031] Query optimization is achieved by rewriting and optimizing the initially generated query statements based on preset optimization rules in the medical knowledge ontology. For example, it identifies time range scanning operations on large time schedules such as surgical record tables and diagnostic record tables and rewrites them as index queries on pre-computed snapshot tables, significantly reducing query costs. At the same time, it adjusts the order of query clauses to adapt to the database index, improving execution efficiency.

[0032] Metadata embedding is used to embed the structured condition unit node identifier (such as "N_001") corresponding to each query clause in the generated database query statement as an annotation, forming a structure of query clauses and node identifier annotations. This does not affect query execution, but also establishes an anchor point for subsequent result tracing, achieving a precise association between intermediate representation and query statement.

[0033] S103. Execute the database query statement to obtain the data results.

[0034] This step is a routine data query execution process. The system submits the validated database query statement generated in step S102 (validation includes at least one dimension such as syntax, fields, permissions, and logic) to the target clinical database for execution and retrieves the returned data result set, which is typically a list of patients who meet the inclusion and exclusion criteria and their related data.

[0035] S104. Based on the association information between the intermediate representation and the database query statement execution process, generate explanatory evidence information that connects the natural language description and the data results.

[0036] This step is the core step in establishing system credibility and achieving traceability of results. The traceability in this method is not an afterthought analysis function, but a proactive and consistent explanatory chain of evidence capability that elevates the system from the level of query execution to the level of analysis and collaboration.

[0037] Among them, explanatory evidence information refers to the information set that records the full-link relationship between "natural language inclusion conditions - structured intermediate representation - database query statement - data results", which can clearly show the source of data results and the selection criteria, and support result traceability.

[0038] Based on the relevant information accumulated throughout the entire process, an explanatory chain of evidence is constructed to bind natural language descriptions with data results. Specifically: For information integration, the annotation metadata in the database query statement is first extracted. Each returned patient data is associated with the corresponding structured condition unit to determine the patient data's compliance status with each structured condition unit, such as "compliant" or "non-compliant". The specific judgment criteria are recorded, such as "patient age = 65 years old, meets the 'age > 60 years old' condition" and "last surgery date = 3 months ago, does not meet the 'no surgery within the past year' condition". A mapping relationship between patient data and raw natural language can also be established.

[0039] Explanatory evidence information generation, based on integrated correlation information, produces structured explanatory evidence information. This explanatory evidence information can include at least one of the following: matching details between patient data and each structured condition unit, such as node identifiers, compliance status, and judgment criteria; data source descriptions, such as corresponding database tables and field names; and mapping relationships with the original natural language inclusion and exclusion conditions, such as corresponding text fragments and the location information of the original text. This explanatory evidence information not only clearly elucidates the specific reasons for the inclusion or exclusion of each patient data point but also provides core data support for subsequent two-way interactive traceability, resolving the issue of gaps in result traceability and ensuring the transparency and credibility of the screening results.

[0040] The method disclosed herein constructs a complete technical loop from natural language description to database query execution and result tracing by introducing a structured intermediate representation as the core hub. First, the method accurately parses and solidifies unstructured natural language intent into an intermediate representation, resolving semantic understanding gaps. Then, based on domain knowledge ontology, this representation is transformed into an executable query, and after execution, explanatory evidence connecting the result and the original conditions is proactively constructed. This fundamentally resolves operational verification and result tracing gaps, achieving automated and precise processing of medical inclusion and exclusion conditions from natural language input to data output, significantly improving the efficiency and reliability of patient screening in clinical research.

[0041] The core of the intermediate representation lies in its structured semantic carrier—a machine-executable and user-understandable entity—that lies between natural language and database query language. Its core function is to accurately carry the complete filtering logic parsed from natural language, including atomic conditions and their nested combinations, while maintaining decoupling from the underlying database implementation. Its specific implementation can take various forms; the in-row condition tree is one exemplary structural form. Other possible forms include, but are not limited to, a structured rule list organizing atomic conditions and logical rules in list form, or an enhanced abstract syntax tree that incorporates domain semantic annotations on top of a traditional syntax tree. To clearly illustrate the principles of this invention, the following detailed description will use the preferred embodiment of the in-row condition tree as an example. Those skilled in the art should understand that the description of the specific form of the intermediate representation is merely illustrative and does not constitute a limitation on the scope of protection of this invention.

[0042] Among them, the in-place condition tree refers to the specific implementation form of the structured intermediate representation. It presents the semantic logic of medical in-place conditions in an intuitive tree structure. The root node is the overall logical relationship, the intermediate nodes are nested logical operators, and the leaf condition nodes are specific structured condition units, that is, atomic in-place constraints, which support machine parsing and user visual interaction.

[0043] Leaf condition nodes refer to the lowest level nodes in the nano-row condition tree, corresponding to a specific atomic nano-row constraint, i.e., a single structured condition unit, which is the basic unit that constitutes the nano-row condition tree.

[0044] See Figure 2 , Figure 2 This is an exemplary flowchart of S101. In the example where the middle section represents a condition tree and the structured condition units are leaf condition nodes, S101 includes: S1011. Identify and process based on medical exclusion conditions to obtain corresponding standardized medical entity information.

[0045] This step corresponds to the domain knowledge-guided coarse parsing stage described earlier. Its purpose is to perform preliminary structuring processing on the raw natural language input, providing cleaned and enhanced input for subsequent precise parsing.

[0046] Standardized medical entity information refers to medical entity data that has undergone normalization processing and includes unified concept identifiers and type labels, eliminating ambiguity in entity names. For example, "myocardial infarction" and "myocardial infarction" are unified as the same concept, ensuring semantic consistency.

[0047] In some examples, S1011 includes: Step 1: Conduct a preliminary analysis of the medical inclusion and exclusion criteria to identify the medical entity information.

[0048] The preliminary analysis refers to the basic semantic processing of medical inclusion and exclusion conditions in natural language form, including word segmentation, part-of-speech tagging, and identification of medical entity boundaries, to initially screen out possible medical entities.

[0049] First, basic natural language processing is performed on the user-input natural language description. This process utilizes lightweight models or rules for preliminary parsing, with the core task being to identify key fragments in the text related to medical screening, i.e., medical entity information. This entity information consists of the initially identified information fragments. For example, from the text "age greater than 60 years old and no history of myocardial infarction," we might identify "age" and "60 years old" as numerical constraint entities, and "myocardial infarction" as a disease entity. At this point, the system only has a preliminary understanding of the existence of these word strings and their approximate types, such as numerical values ​​and diseases. Further analysis can be performed on their precise medical meaning, standardized expressions, and correspondence with the database.

[0050] Step 2: Call the medical domain knowledge ontology library to normalize the medical entity information and obtain standardized medical entity information containing ontology concept identifiers corresponding to the medical entity information.

[0051] The initially identified medical entity information is often vague and ambiguous. To eliminate ambiguity and unify standards, the system calls upon a medical domain knowledge ontology in real time. The concept layer of this ontology serves as the authoritative interpretation within the medical field. The system submits initially identified medical entity information (such as "myocardial infarction") to the ontology, which then queries its internal concept network to perform the following key operations: concept disambiguation, for example, determining that "myocardial infarction" in the current context refers specifically to "myocardial infarction" and not other possible meanings; and normalization, which involves unifying semantically identical medical entities with different expressions into a standard form through clinical domain knowledge verification, and supplementing concept identifiers and type information. This is the core step in eliminating semantic ambiguity; for example, mapping multiple expressions such as "myocardial infarction" and "MI" to the standard concept "myocardial infarction." The result of this mapping is the assignment of a unique ontology concept identifier to the standard concept. This identifier is a unique code assigned to each standard medical concept in the medical domain knowledge ontology, used to uniquely represent the medical entity and ensure semantic consistency across systems and databases. For example, "myocardial infarction" might be assigned the ontology concept identifier C001, specifically: concept_id: "C001_MyocardialInfarction". Simultaneously, the knowledge ontology of the medical domain knowledge ontology may supplement this concept with its type, such as "disease diagnosis" for "myocardial infarction", associated synonyms, and hierarchical relationships. Through this process, the original, vague medical entity information is transformed into standardized medical entity information containing precise ontology concept identifiers and other normalized attributes.

[0052] S1012. Input the standardized medical entity information and the preset data model information into the large language model to obtain the output of the large language model's sorting and categorization condition tree.

[0053] This step corresponds to the context-aware, detailed analysis and structuring stage described earlier. The purpose of this step is to understand the overall logical structure of the selection criteria and organize it into a formal tree representation.

[0054] The standardized medical entity information generated in the previous step, along with the preset data model information, are used to construct a prompt. The data model information refers to the metadata of the databases involved in the current medical research project, including table names, field names, field types, and inter-table relationships. This prompt is input into a large language model fine-tuned with a specialized medical corpus. During training, this large language model learns the semantic patterns and logical expressions of medical texts, as well as their correspondence with the inclusion-sorting condition tree structure of this invention. During inference, based on the input standardized entities and data model context, it can perform at least the following tasks: understand the logical relationships between entities, such as "AND," "OR," and "NOT" and their nesting levels; preliminarily determine the database resources that may be involved in implementing each condition based on the data model information; and generate a structured inclusion-sorting condition tree conforming to a predetermined format. This tree fully expresses the semantics of the original natural language query in a machine-readable structured format (such as JSON).

[0055] In some examples, each leaf condition node contains at least one of the following: ontology concept identifier, database field candidate information, comparison operator, comparison value, and time constraint parameter; This refers to the list of database fields in the medical knowledge ontology that are associated with standard medical entities and may be used for filtering. For example, the database field corresponding to "age" might be "Patient Basic Information Table. Date of Birth" or "Patient Basic Information Table. Age", etc.

[0056] Comparison operators refer to logical operators used to characterize constraint relationships, including numerical comparisons such as >, <, ≥, ≤, =, and ≠; existence judgments such as exist or not exist, specifically, "greater than" corresponds to ">", and "none" corresponds to "not exist".

[0057] The comparison value refers to the specific numerical value or range corresponding to the comparison operator, such as "60" in "60 years old".

[0058] Time constraint parameters refer to relevant information used to limit the time range, including time type, such as relative time, absolute time; time length; reference time point, etc. For example, the time constraint parameters for "within the past year" are "relative time, 1 year, current date".

[0059] In the process of generating the nano-row condition tree, constructing any leaf condition node includes at least one of the following steps: Step 1: Obtain ontology concept identifiers from the medical domain knowledge ontology base; Construct the semantic foundation for leaf condition nodes. The medical semantics of a leaf condition node are uniquely determined by its ontology concept identifier, which can be derived from the result obtained in step S1011 by querying the medical domain knowledge ontology.

[0060] Step 2: Based on ontology concept identifiers and a pre-defined data model, infer candidate information for database fields; The key reasoning step in achieving semantic-to-data mapping is as follows: Based on the ontology concept identifiers already determined in the leaf condition nodes, combined with pre-defined data model information—that is, which tables and fields are available—the process of determining "which locations in the database might need to be accessed to query a certain ontology concept" is generated. This generates a candidate list of database fields, which provides clear mapping target options for the subsequent query generation module.

[0061] Step 3: Extract at least one of the comparison operator, comparison value, and time constraint parameter from the medical inclusion and exclusion conditions.

[0062] The filling of specific constraints for leaf condition nodes is usually done by the large language model. It extracts the operational details related to a certain leaf condition node from the original natural language description fragment. For example, it extracts the "greater than" operator and the value "60", or it extracts the time constraint parameter "within the last year" and represents it as a structured parameter. This information, together with the ontology concept identifier, defines a complete and executable filtering condition.

[0063] See in some examples Figure 3 , Figure 3 This is an exemplary flowchart illustrating step S102. S102 includes: S1021. Traverse the intermediate representation, and for the structured condition units therein, query the medical domain knowledge ontology base based on the ontology concept identifiers contained therein to determine the corresponding target database table and fields. Among them, the target database table and field refer to the specific tables and fields in the clinical database that store the data required for inclusion and exclusion criteria. For example, the target table for "age" filtering is the "Patient Basic Information Table", and the target field is "Date of Birth"; the target table for "history of myocardial infarction" filtering is the "Diagnosis Record Table", and the target field is "001 code".

[0064] First, the entire structure of the intermediate representation (e.g., the nav-pv condition tree) is traversed. For each structured condition unit (i.e., a leaf condition node) in the nav-pv condition tree, the system extracts the ontology concept identifier from its data structure. The ontology concept identifier is a key established in step S101 that represents a unique standardized medical concept.

[0065] Subsequently, using the ontology concept identifier as the query key, the mapping layer of the medical domain knowledge ontology is invoked. This mapping layer stores the precise correspondence between semantic concepts and physical database structures. Through this query, the system can determine one or more target database tables and fields for each atomic condition. For example, for a condition with the identifier "myocardial infarction," the mapping layer might indicate that its data is stored in the "Disease Diagnosis Code" field of the "Diagnosis Record Table," with a value of "acb." Furthermore, the system also processes semantics such as time parameters, converting relative time descriptions like "within the last year" into specific date functions or range query (BETWEEN) statements based on the database dialect. This step completes the transformation from the semantic concept of "what to search" to the database location of "where to search."

[0066] S1022. Generate multiple database query statements based on the target database tables and fields.

[0067] After completing the basic field mapping, the system initially constructs multiple basic database query clauses or fragments based on the target database table and fields mapped to each structured condition unit, as well as the comparison operators and values ​​contained in that unit. At this stage, in some examples, the basic database query clauses or fragments may only be for a single condition or a single table.

[0068] See also Figure 2 After S1022, S102 may also include: S1023. Based on the logical relationship between the structured condition units in the intermediate representation, deduce the table connection relationship between the target database tables corresponding to each structured condition unit. Based on the above logical relationships, this step derives the necessary data table join paths to achieve the overall query. Table join relationships refer to the association rules established between multiple target database tables through common fields (such as "Patient ID" or "Visiting Number"), used to achieve joint queries of multi-table data. For example, the "Patient Basic Information Table" and the "Diagnosis Record Table" are linked through "Patient ID".

[0069] The system analyzes the tree structure of the intermediate representation. For example, if an "age" condition (related to the patient's basic information table) and a "surgical history" condition (related to the surgical record table) are connected using the AND operator, it means that matching data needs to be retrieved from both tables simultaneously. Therefore, a relationship must be established between the two tables. The system calls the rule layer of the medical domain knowledge ontology, which predefines medical logic rules between tables. For example, "surgical record" must be associated with "patient's basic information" through "patient unique identifier". Based on these rules, the system automatically derives all necessary table join relationships, ensuring that the query can retrieve complete information from the correct data source.

[0070] S1024. Based on the table join relationship, determine the query relationship between each database query statement.

[0071] Among them, query relationship refers to the logical association between multiple database query statements, corresponding to the logical relationship of structured condition units in the inclusion and sorting condition tree (such as AND, OR, NOT), which is used to integrate multiple query clauses into a complete query logic.

[0072] Based on the table join relationships derived in the previous step, the multiple database query statements or clauses generated in step S1022 are integrated. It determines how these query fragments should be combined using SQL syntax such as JOIN, subqueries, or UNION operations to reflect the logical relationships defined in the intermediate representation. For example, the condition "no surgical records within the last year" is specifically implemented as a subquery that joins the main table using patient identifiers, ensuring the logical correctness of the generated query.

[0073] In some examples, S1023-S1024 can be omitted, and this is not a limitation here.

[0074] See also Figure 2 After S1024, S102 may also include: S1025. Based on the preset optimization rules in the medical domain knowledge ontology, the initially generated database query statement is rewritten to obtain the rewritten optimized database query statement. The optimization rules are used to improve the query performance of the database query statement.

[0075] Specifically, optimization rules refer to a set of pre-defined strategies in the medical knowledge ontology to improve query execution efficiency. These strategies are designed based on the storage characteristics, data volume distribution, and query frequency of clinical databases, and include rules such as snapshot table query rewriting, index utilization, and query clause order adjustment.

[0076] Query performance refers to the execution efficiency of database query statements, including metrics such as query response time and resource utilization. The optimization goal is to shorten query time and reduce resource consumption while ensuring the accuracy of the results.

[0077] Rewriting refers to adjusting the structure, syntax, or query method of a query statement according to optimization rules without changing the query semantics, thereby generating an optimized version that is more suitable for database execution.

[0078] The system introduces a rule-driven query plan optimization step, which calls the rule layer of the medical domain knowledge ontology. This layer contains a series of preset optimization rules (or performance heuristics). The optimization rules encapsulate the data query experience and understanding of database performance of domain experts. Based on these rules, the initially generated database query statement is analyzed and rewritten to generate an optimized database query statement with the same semantics but significantly higher execution efficiency.

[0079] In some examples, S1025 specifically includes: Step 1: Identify the database query statement and / or its associated target database table containing the target query pattern for time range scanning of large time schedules; Large time series tables refer to database tables that store time-series data of clinical events, with large data volumes and frequent records, such as surgical record tables, examination record tables, and medication record tables. Full table time range scans of these tables usually take a long time and affect query efficiency.

[0080] Targeted query patterns refer to query structures that involve scanning a time range across a large timeline, such as querying surgery dates within a year from a surgical record table. These types of query patterns are a key focus for performance optimization.

[0081] Specifically, the system analyzes the initial query statements and, based on the knowledge of the rule base, identifies known inefficient query patterns. For example, a target query pattern is to perform a full table or a large-scale time range scan on a large time schedule to determine whether an event exists or meets a time condition, such as "query whether there are any surgical records in the past year". This pattern is marked as a high-cost operation because it requires scanning a large amount of data.

[0082] Step 2: Rewrite the database query statement corresponding to the target query pattern into a query that points to the snapshot table, where the snapshot table is a pre-calculated database table containing patient aggregate indicators.

[0083] The snapshot table refers to a database table that pre-calculates and stores aggregated patient indicators. It includes key screening indicators that have been summarized and statistically analyzed, such as the date of the last surgery, whether there is a specific medical history, and the cumulative number of examinations. It is updated regularly by the system to replace real-time scanning of large timelines and improve query efficiency.

[0084] Patient aggregate indicators refer to derived indicators based on the aggregation of patients' historical data. They can directly reflect the constraint information required for inclusion and exclusion conditions without the need for real-time calculation from raw data. Examples include "date of last surgery" and "history of myocardial infarction".

[0085] For identified inefficient patterns, the system performs query rewriting, specifically replacing complex real-time calculations with pre-computed intermediate data. For example, the system rewrites complex logic involving time-range joins across multiple large event tables into simple queries on one or more snapshot tables. These snapshot tables are pre-computed offline, periodically updated aggregation tables that summarize key time points and status indicators for each patient. This rewriting transforms operations that previously required complex joins and filtering of massive historical records into direct index lookups or simple comparisons on smaller snapshot tables, significantly improving query execution efficiency and achieving intelligent performance optimization. The final output is a directly executable SQL statement with potential optimization comments.

[0086] In some examples, S1025 may be omitted; this is not a limitation here.

[0087] In some examples, after S102, this method may also include: Step A: Embed the node identifiers corresponding to the structured conditional units in the intermediate representation as annotation metadata into the database query statement.

[0088] Among them, the node identifier refers to the unique identifier assigned to each leaf condition node in the sorting condition tree, which is used to uniquely distinguish each node and supports node-level association and tracing.

[0089] Annotation metadata refers to additional information embedded in database query statements to mark node relationships. It can exist in database annotation format, does not affect the execution of the query statement, and is only used for subsequent result tracing.

[0090] This step is a technical prerequisite for building end-to-end interpretability. When generating the final database query statement (whether initially generated or optimized), the system extracts a unique node identifier for each structured condition unit (such as a leaf condition node) from the intermediate representation (such as an inverted condition tree). Subsequently, these node identifiers are embedded as annotation metadata into the comment lines of the SQL clauses in the query statement that correspond to their logic. These annotations do not affect the query results but provide anchors for mapping the execution results back to the original semantic intent.

[0091] See Figure 4 , Figure 4 This is an exemplary flowchart illustrating S104. Based on step A, in some examples, S104 includes: S1041. Based on the annotation metadata, associate each returned data result with the corresponding structured condition unit in the intermediate representation to obtain the association information; The association information refers to the matching relationship between each record in the data results (such as each patient) and the corresponding structured condition unit and query clause in the inclusion and exclusion condition tree. This can include core content such as "patient identifier - node identifier - compliance status," for example, "patient P001 - node N_001 - compliance"; "patient P001 - node N_002 - non-compliance," etc. The compliance status refers to the judgment result of whether a record in the data results meets or violates the corresponding structured condition unit (a certain inclusion and exclusion condition), including two core statuses: "compliance" and "non-compliance," which explain the specific basis for record selection.

[0092] Specifically, after the database completes its execution and returns data results (e.g., a list of patients and relevant field values ​​used for judgment), an evidence binding process is performed. Based on the annotation metadata pre-embedded in the SQL, each returned row of data is analyzed and marked to determine whether and how the row satisfies or violates the specific structured condition unit pointed to by the annotation. For example, for Patient 1, the system records that their "age = 65 years old," which satisfies the condition "age > 60 years old" of a structured condition unit annotated as such. Through this process, abstract query results are transformed into associated information bound one-to-one with specific semantic conditions.

[0093] S1042. Generate explanatory evidence information based on related information.

[0094] Using the correlation information generated in the previous step, structured explanatory evidence is dynamically generated. This is not simply a matter of passing or excluding conclusions, but a detailed and traceable list of evidence. The explanatory evidence clearly records the conformity between each patient or data result and each relevant medical inclusion or exclusion condition, and cites specific underlying data values ​​as evidence.

[0095] In some examples, after S101, this method may also include: Step B: Record the correspondence information between each structured condition unit in the intermediate representation and its corresponding original text fragment of the medical inclusion and exclusion conditions.

[0096] The corresponding information of the original text fragment refers to the mapping relationship between the structured condition unit in the inclusion condition tree and the corresponding text fragment in the original natural language inclusion condition. For example, it includes "node identifier - original text fragment - location information". A specific example can be "N_001 - age greater than 60 years old - 8th-12th character of the text", which is used to trace the source of the data results to the original natural language.

[0097] Simultaneously or after generating the intermediate representation in step S101, the system records an important mapping relationship, namely, which specific original text segment in the original natural language description each structured conditional unit in the intermediate representation was parsed from. For example, it records the original text segment "age greater than 60 years old" in the original text corresponding to the structured conditional unit NTree_N1 (age > 60 years old).

[0098] It should be noted that the method provided in this disclosure also improves interactivity.

[0099] In some examples, after S104, this method may also include: A visualization report of query results is generated based on interpretive evidence information. The visualization report allows users to trace the data results back to their corresponding structured condition units through interactive operations, and / or to the original text fragments of medical inclusion and exclusion conditions through corresponding information.

[0100] Among them, the visual report refers to the report that presents the screening results and explanatory evidence information in a graphical and intuitive form, such as including statistics on the number of patients screened, details of individual patients' compliance, and traceability entry points, and supports user interaction.

[0101] Interactive operations refer to the actions performed by users on the visual report interface, such as clicking to view details, reverse tracing, and highlighting, which are used to verify and check the filtering results.

[0102] In this way, the explanatory evidence and corresponding information built in the backend are transformed into a visual report of query results that users can directly perceive and manipulate. The visual report not only displays the final patient list but also provides in-depth details. Its core interactive capability lies in the fact that when a user clicks on a patient, the report expands to show how that patient passed or violated each condition (structured condition unit) and displays specific data evidence. This is achieved based on correlated information; when a user clicks on a specific judgment in the report, the system can reverse-locate the corresponding condition node in the intermediate representation; furthermore, based on the corresponding information, the system marks and displays the corresponding original text in the user's initial natural language input. It can also display the database fields and calculation logic ultimately executed by this judgment. This two-way interactive tracing forms a complete closed loop, greatly enhancing the credibility of the results and the debuggability of the problems.

[0103] In some examples, after S101, this method may also include: Provide users with a visual interface for editing the NaN tree, presenting the NaN arrangement condition tree in an interactive graphical format; The tree editing visualization interface receives user editing operations on at least one leaf condition node in the arrangement condition tree, forming a corrected arrangement condition tree.

[0104] The visualization interface for editing the arrangement condition tree refers to an interactive interface that displays the arrangement condition tree in a graphical form and supports user editing operations. Logical nodes in the interface can be represented by shape one, leaf condition nodes by shape two, and logical relationships are connected by lines, intuitively presenting the semantic structure of the arrangement conditions.

[0105] Editing operations refer to the modifications that users make to the sorting and categorizing condition tree on the visual interface, including adjusting logical nesting relationships, editing parameters of leaf condition nodes, adding nodes, deleting nodes, etc., to correct deviations in machine understanding.

[0106] The revised inclusion and sorting condition tree refers to the updated inclusion and sorting condition tree after user editing, reflecting the user's true filtering intent and serving as the basis for regenerating the query statement.

[0107] Specifically, after S101 generates the Na-rank condition tree, the system does not immediately proceed to query generation. Instead, it first presents this structured intermediate representation to the user through a Na-rank tree editing visualization interface in an interactive graphical format (such as a collapsible / expandable tree diagram). This allows the user to intuitively view the machine's understanding of their query intent. If the user finds any discrepancies in the system's understanding—for example, incorrect logical relationships, incorrect values, or inaccurate concept mappings—they can directly edit the visualization interface. Each user edit directly modifies the Na-rank condition tree data structure, which serves as a semantic blueprint. The system receives these operations and updates its internal representation in real time, thus forming a revised Na-rank condition tree that has been verified or corrected by the user. The modified tree structure then serves as new input, replacing the original parsing result and driving the subsequent query generation and execution process.

[0108] The method disclosed herein establishes an interactive pathway between natural language and database queries through structured intermediate representations (such as inclusion / exclusion condition trees). Combined with the full-process knowledge support of a medical knowledge ontology, it not only solves the triple gap problem of semantic understanding, operational verification, and result traceability in clinical research inclusion / exclusion condition processing, but also enables human-machine collaborative verification through a visual editing interface, improves the efficiency of massive data screening through query rewriting optimization, and ensures transparent and verifiable results through bidirectional interactive traceability. The whole system forms a closed loop of "semantic parsing - query generation - result traceability - interactive optimization," avoiding machine understanding bias and human operation errors, significantly improving the accuracy, efficiency, and reliability of inclusion / exclusion condition processing, while enhancing the system's usability and controllability, perfectly adapting to the intelligent processing needs of complex inclusion / exclusion conditions in clinical research.

[0109] In the disclosed second embodiment, see Figure 5 ,like Figure 1 The principle shown Figure 5 This disclosure illustrates a second embodiment of an intelligent processing device 50 for medical intake and discharge conditions, wherein the device includes: The intermediate representation conversion module 501 is used to perform semantic intent parsing on the medical inclusion and exclusion conditions described in natural language input by the user and convert them into a structured intermediate representation. The intermediate representation contains multiple structured condition units and their logical relationships, with one structured condition unit corresponding to one medical inclusion and exclusion condition. The query statement conversion module 502 is used to traverse each structured condition unit of the intermediate representation based on a preset medical domain knowledge ontology, and convert the intermediate representation into an executable database query statement based on the traversal results. Data results module 503 is used to execute database query statements and obtain data results; The interpretability module 504 is used to generate interpretive evidence information that connects the natural language description and the data results based on the association information between the intermediate representation and the database query execution process.

[0110] In some examples, the middle represents a sorting condition tree; The intermediate representation conversion module 501 is specifically used for: Based on medical exclusion criteria, identification and processing are performed to obtain corresponding standardized medical entity information; Standardized medical entity information and preset data model information are input into a large language model to obtain the in-row and out-row condition tree output by the large language model.

[0111] In some examples, the intermediate representation conversion module 501, after identifying and processing based on medical exclusion conditions to obtain corresponding standardized medical entity information, is specifically used for: A preliminary analysis of the medical inclusion and exclusion criteria was conducted to identify the medical entity information within them; By calling upon a medical domain knowledge ontology, the medical entity information is normalized to obtain standardized medical entity information containing ontology concept identifiers corresponding to the medical entity information.

[0112] In some examples, the structured conditional element is a leaf conditional node; Each leaf condition node contains at least one of the following: ontology concept identifier, database field candidate information, comparison operator, comparison value, and time constraint parameter; The intermediate representation conversion module 501 constructs leaf condition nodes by including at least one of the following steps: Obtain ontology concept identifiers from a medical domain knowledge ontology repository; Based on ontology concept identifiers and a pre-defined data model, candidate information for database fields is inferred. Extract at least one of the following from the medical inclusion and exclusion conditions: comparison operator, comparison value, and time constraint parameter.

[0113] In some examples, the query transformation module 502 is specifically used for: Traverse the intermediate representation, and for each structured condition unit, query the medical domain knowledge ontology based on the ontology concept identifiers it contains to determine the corresponding target database table and fields; Generate multiple database query statements based on the target database tables and fields.

[0114] In some examples, query transformation module 502 is also used for: Based on the logical relationships between the structured condition units in the intermediate representation, the table join relationships between the target database tables corresponding to each structured condition unit are derived. Based on table joins, determine the query relationships between each database query statement.

[0115] In some examples, query transformation module 502 is also used for: Based on the preset optimization rules in the medical knowledge ontology, the initially generated database query statement is rewritten to obtain the rewritten optimized database query statement. The optimization rules are used to improve the query performance of the database query statement.

[0116] In some examples, the query statement transformation module 502 rewrites the initially generated database query statement according to the preset optimization rules in the medical domain knowledge ontology, resulting in a rewritten database query statement, and is used for: Identify database query statements and / or their associated target database tables containing target query patterns that perform time range scans on large time schedules; The database query statement corresponding to the target query pattern is rewritten as a query pointing to the snapshot table, which is a pre-calculated database table containing patient aggregate indicators.

[0117] In some examples, the device also includes: The annotation module is used to embed the node identifiers corresponding to the structured condition units in the intermediate representation as annotation metadata into the database query statement.

[0118] In some examples, the interpretability module 504 is specifically used to: associate each returned data result with the corresponding structured conditional unit in the intermediate representation based on the annotation metadata to obtain association information; Based on the associated information, explanatory evidence information is generated.

[0119] In some examples, the device also includes: The recording module is used to record the correspondence information between each structured condition unit in the intermediate representation and the original text fragment of the corresponding medical inclusion and exclusion conditions.

[0120] In some examples, the device also includes: The visualization and tracing module is used to generate a visualization report of query results based on interpretive evidence information. The visualization report of query results allows users to trace the data results to their corresponding structured condition units through related information through interactive operations, and / or to the original text fragments of medical inclusion and exclusion conditions through corresponding information.

[0121] In some examples, the device also includes: The tree editing module provides users with a visual interface for editing nanotrees, presenting the nanotree arrangement condition tree in an interactive graphical format. The tree editing visualization interface receives user editing operations on at least one leaf condition node in the arrangement condition tree, forming a corrected arrangement condition tree.

[0122] The acquisition, storage, and application of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0123] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0124] Computer instructions stored on a non-transitory computer-readable storage medium are used to cause a computer to perform the above-described method.

[0125] Computer program products include computer programs that, when executed by a processor, implement the methods described above.

[0126] Figure 6 A schematic block diagram of an example electronic device 600 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0127] like Figure 6As shown, device 600 includes a computing unit 601, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 602 or a computer program loaded from a storage unit into random access memory (RAM) 603. The RAM 603 may also store various programs and data required for the operation of device 600. The computing unit 601, ROM 602, and RAM 603 are interconnected via bus 604. An input / output (I / O) interface 605 is also connected to bus 604.

[0128] Multiple components in device 600 are connected to I / O interface 605, including: input unit 606, such as keyboard, mouse, etc.; output unit 607, such as various types of monitors, speakers, etc.; storage unit 608, such as disk, optical disk, etc.; and communication unit 609, such as network card, modem, wireless transceiver, etc. Communication unit 609 allows device 600 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0129] The computing unit 601 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 601 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 601 performs the various methods and processes described above, such as the methods described above. For example, in some embodiments, the methods described above can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 608. In some embodiments, part or all of the computer program can be loaded and / or installed on device 600 via ROM 602 and / or communication unit 609. When the computer program is loaded into RAM 603 and executed by the computing unit 601, one or more steps of the methods described above can be performed. Alternatively, in other embodiments, the computing unit 601 can be configured to perform the methods described above by any other suitable means (e.g., by means of firmware).

[0130] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0131] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0132] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0133] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0134] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0135] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

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

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

Claims

1. An intelligent processing method of medical triage conditions, wherein, The method includes: The medical inclusion and exclusion conditions described in natural language input by the user are semantically interpreted and converted into a structured intermediate representation. The intermediate representation contains multiple structured condition units and their logical relationships, and one structured condition unit corresponds to one medical inclusion and exclusion condition. Based on a pre-defined medical domain knowledge ontology, the structured conditional units of the intermediate representation are traversed, and the intermediate representation is converted into an executable database query statement based on the traversal results. Execute the database query statement to obtain the data results; Based on the association information between the intermediate representation and the execution process of the database query statement, explanatory evidence information connecting the natural language description and the data results is generated.

2. The method of claim 1, wherein, The intermediate representation is a sorting condition tree; The process of semantic intent parsing of the medical inclusion and exclusion conditions described in natural language input by the user and converting them into a structured intermediate representation includes: Based on the aforementioned medical exclusion criteria, identification and processing are performed to obtain corresponding standardized medical entity information; The standardized medical entity information and the preset data model information are input into the large language model to obtain the in-row and out-row condition tree output by the large language model.

3. The method according to claim 2, wherein, The identification and processing based on the medical exclusion criteria to obtain corresponding standardized medical entity information includes: The medical inclusion and exclusion conditions are preliminarily analyzed to identify the medical entity information therein; The medical domain knowledge ontology is invoked to normalize the medical entity information, resulting in standardized medical entity information containing ontology concept identifiers corresponding to the medical entity information.

4. The method according to claim 2 or 3, wherein, The structured condition unit is a leaf condition node; Each leaf condition node includes at least one of the following: ontology concept identifier, database field candidate information, comparison operator, comparison value, and time constraint parameter; Constructing the leaf condition node includes at least one of the following steps: Obtain the ontology concept identifier from the medical domain knowledge ontology base; Based on the ontology concept identifier and the preset data model, the candidate information of the database field is inferred; At least one of the comparison operator, the comparison value, and the time constraint parameter is parsed from the medical inclusion and exclusion conditions.

5. The method according to any one of claims 1-4, wherein, The method, based on a pre-defined medical domain knowledge ontology, traverses each structured conditional unit of the intermediate representation and converts the intermediate representation into an executable database query statement based on the traversal results, including: Traverse the intermediate representation, and for each structured condition unit, query the medical domain knowledge ontology based on the ontology concept identifier it contains to determine the corresponding target database table and fields; Multiple database query statements are generated based on the target database tables and fields.

6. The method according to claim 5, wherein, After generating multiple database query statements based on the target database tables and fields, the step of traversing each structured condition unit of the intermediate representation based on a preset medical domain knowledge ontology, and converting the intermediate representation into executable database query statements based on the traversal results, further includes: Based on the logical relationship between the structured condition units in the intermediate representation, the table join relationship between the target database tables corresponding to each structured condition unit is derived; Based on the table join relationship, the query relationship between each of the database query statements is determined.

7. The method according to claim 6, wherein, After determining the query relationships between the database query statements based on the table join relationships, the step of traversing each structured condition unit of the intermediate representation based on a preset medical domain knowledge ontology, and converting the intermediate representation into executable database query statements based on the traversal results, further includes: Based on the preset optimization rules in the medical domain knowledge ontology, the initially generated database query statement is rewritten to obtain the rewritten optimized database query statement, wherein the optimization rules are used to improve the query performance of the database query statement.

8. The method according to claim 7, wherein, The process involves rewriting the initially generated database query statement according to preset optimization rules in the medical domain knowledge ontology, resulting in a rewritten database query statement, including: Identify the database query statement and / or its associated target database table, which contains a target query pattern for time range scanning of a large time schedule; The database query statement corresponding to the target query pattern is rewritten as a query pointing to the snapshot table, wherein the snapshot table is a pre-calculated database table containing patient aggregate indicators.

9. The method according to any one of claims 1-8, wherein, After traversing each structured conditional unit of the intermediate representation based on a preset medical domain knowledge ontology and converting the intermediate representation into an executable database query statement based on the traversal results, the method further includes: The node identifiers corresponding to the structured condition units in the intermediate representation are embedded as annotation metadata into the database query statement.

10. The method according to claim 9, wherein generating explanatory evidence information connecting the natural language description and the data result based on the association information between the intermediate representation and the database query statement execution process includes: Based on the annotation metadata, each returned data result is associated with the corresponding structured condition unit in the intermediate representation to obtain the association information; Based on the aforementioned association information, the explanatory evidence information is generated.

11. The method according to claim 10, wherein after performing semantic intent parsing on the medical inclusion and exclusion conditions of the natural language description input by the user and converting them into a structured intermediate representation, the method further includes: Record the correspondence information between each structured condition unit in the intermediate representation and its corresponding original text fragment of the medical inclusion and exclusion conditions.

12. The method according to claim 10, after generating explanatory evidence information connecting the natural language description and the data result based on the association information between the intermediate representation and the database query statement execution process, the method further includes: A query result visualization report is generated based on the explanatory evidence information. The query result visualization report allows users to trace the data results back to their corresponding structured condition units through the associated information, and / or to the original text fragments of the medical inclusion and exclusion conditions through the corresponding information, via interactive operations.

13. The method according to any one of claims 2-12, wherein, After semantic intent parsing of the medical inclusion and exclusion conditions described in natural language input by the user and converting them into a structured intermediate representation, the method further includes: Provide users with a visual interface for editing the nanotree, presenting the nanotree in an interactive graphical format; The tree editing visualization interface receives user editing operations on at least one leaf condition node in the arrangement condition tree, forming a corrected arrangement condition tree.

14. An intelligent processing device for medical intake and discharge conditions, wherein, The device includes: The intermediate representation conversion module is used to perform semantic intent parsing on the medical inclusion and exclusion conditions described in natural language input by the user and convert them into a structured intermediate representation. The intermediate representation contains multiple structured condition units and their logical relationships, and one structured condition unit corresponds to one medical inclusion and exclusion condition. The query statement conversion module is used to traverse each structured condition unit of the intermediate representation based on a preset medical domain knowledge ontology, and convert the intermediate representation into an executable database query statement based on the traversal results. The data structure module is used to execute the database query statement and obtain the data result; An interpretability module is used to generate interpretive evidence information that connects the natural language description and the data results based on the association information between the intermediate representation and the execution process of the database query statement.

15. An electronic device comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-13.

16. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-13.

17. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-13.

Images