An AI-CDSS method, system and storage medium based on multi-source medical event graph and risk constraint tool scheduling

Abstract

The application discloses an AI-CDSS method and system based on a multi-source medical event graph and a risk constraint tool arrangement and a storage medium, relates to the technical field of medical artificial intelligence and clinical decision support, and comprises the following steps: acquiring multi-source medical data of a target patient, and constructing a patient multi-source medical event graph; generating a clinical state vector; matching the clinical state vector with each tool node in a medical capability graph, and screening a candidate medical tool set; performing a risk constraint control strategy on the candidate action, and generating a controlled tool calling chain; calling a medical tool to acquire a plurality of evidence items, and generating a structured evidence package; and generating a clinical decision support suggestion card or an evidence completion prompt according to a minimum sufficient evidence set condition judgment. The application solves the problems of insufficient safety constraints and missing evidence verifiability of existing systems in a multi-source heterogeneous medical data scene. The application realizes a controlled tool arrangement and suggestion generation which are computable, verifiable and auditable.

Description

Technical Field

[0001] This invention relates to the field of medical artificial intelligence and clinical decision support technology, specifically to a method and system for constructing multi-source medical event graphs, matching medical capability graphs, arranging risk constraint tools, verifying the consistency of multi-source evidence, and generating and controlling clinical decision support suggestion cards for AI-CDSS scenarios. Background Technology

[0002] Existing Clinical Decision Support Systems (CDSS) typically compare structured fields from electronic medical records, laboratory tests, and imaging systems based on fixed rules, single rating scales, or pre-defined trigger conditions, and output alerts or suggestions when the conditions are met. With the development of large language models and intelligent agent technology, general intelligent agent solutions are beginning to be introduced into medical decision support scenarios, using natural language planning to invoke external tools and generate suggestions.

[0003] However, the above solutions suffer from the following technical problems in scenarios with multi-source heterogeneous medical data: Patient data comes from multiple heterogeneous systems such as electronic medical records, hospital information systems, laboratory systems, imaging systems, medical order systems, and nursing records. These systems have different data formats, temporal relationships, and semantic representations, lacking a unified structured representation of patient status. This makes it difficult to constrain and verify indications, contraindications, input field completeness, and access permissions based on a complete clinical context when calling tools. Furthermore, for high-risk diagnostic and treatment actions, existing systems lack mechanisms for masking, downgrading, or forcing manual confirmation based on a combination of patient risk level and action risk level. Simultaneously, the semantic consistency, temporal consistency, and directional conflicts among evidence items from different tools and modalities (such as AI-generated imaging results, imaging report texts, laboratory results, medical records, and guidelines) are difficult to quantify. When key evidence fields are missing, the system may still output clear diagnostic and treatment recommendations, lacking a recommendation generation control mechanism based on evidence sufficiency conditions. Summary of the Invention

[0004] The purpose of this invention is to provide an AI-CDSS method, system, and storage medium based on multi-source medical event graphs and risk constraint tools, to address the following technical problems in the prior art: In scenarios involving access to multi-source heterogeneous medical data, existing clinical decision support systems lack a mechanism to transform multi-source medical data into a unified and computable structured patient state representation, resulting in tool calls being unable to implement medical risk constraints based on a complete clinical context; for high-risk diagnostic and treatment actions, existing systems lack mechanisms for masking, downgrading, or forcing manual confirmation based on a combination of patient risk level and action risk level; semantic consistency, temporal consistency, and directional conflicts among evidence items from different tools and modalities are difficult to quantify and calculate; and the generation of clinical decision support recommendations lacks a verifiable control mechanism based on the minimum sufficient evidence set condition, leading to technical problems such as false triggering, conflicting evidence output, and generating explicit recommendations even when evidence is insufficient.

[0005] To achieve the above objectives, this invention employs an AI-CDSS method based on multi-source medical event graphs and risk constraint tools, comprising the following operational steps: Acquire multi-source medical data of the target patient and convert it into medical event nodes, then construct a multi-source medical event graph of the patient based on the medical event nodes; Based on the patient's multi-source medical event graph, the doctor's current operational behavior, the patient's treatment stage, the set of identified risk labels, and the current medical order status, a clinical status vector is generated. The clinical status vector is matched with each tool node in the pre-constructed medical capability map, the matching score of each tool node is calculated, and a candidate medical tool set is obtained by screening. Based on the patient's risk level, the tool's risk level, the completeness of the input fields, and the calling permissions, a risk constraint control strategy is executed on each candidate action in the candidate medical tool set to generate a controlled tool calling chain. Using a controlled tool call chain, at least one medical tool is invoked sequentially, and multiple evidence items are output. Perform semantic consistency, temporal consistency, multimodal consistency, and guideline consistency checks on multiple evidence items, calculate the strength of conflicting evidence, identify supporting evidence sets, conflicting evidence sets, neutral evidence sets, missing evidence sets, and expired evidence sets, and generate a structured evidence package; Determine whether the structured evidence package meets the preset minimum sufficient evidence set conditions. When the structured evidence package meets the minimum sufficient evidence set conditions, generate a clinical decision support suggestion card; when the structured evidence package does not meet the minimum sufficient evidence set conditions, generate evidence completion prompts.

[0006] Furthermore, medical event nodes include: event type, event time, data source, standard medical code, event value, confidence level, and effective time window attributes.

[0007] Furthermore, constructing a multi-source medical event graph for patients based on medical event nodes includes: constructing a multi-source medical event graph for patients based on the temporal relationship, support relationship, conflict relationship and causal relationship between medical event nodes.

[0008] Furthermore, each tool node in the medical capability graph includes: input field constraints, output field constraints, indication conditions, contraindication conditions, risk level, access permissions, and credibility threshold attributes.

[0009] Furthermore, calculating the matching score for each tool node includes: calculating the completeness of input fields; calculating the matching degree of indication, treatment stage, risk level, permission satisfaction, and contraindication conflict intensity; weighting and summing the completeness of input fields, the matching degree of indication, the matching degree of treatment stage, the matching degree of risk level, and the permission satisfaction, and subtracting the weighted value of the contraindication conflict intensity to obtain the matching score; when the completeness of input fields is lower than the preset input completeness threshold, the tool node does not output the final conclusion, but only outputs the set of missing fields.

[0010] Furthermore, the tool nodes in the medical capability graph also include: dependency relationships, prerequisite relationships, mutual exclusion relationships, and composition relationships; the tool nodes also include applicable departments and applicable treatment stages attributes.

[0011] Furthermore, the risk constraint control strategies include: allowing, downgrading, mandatory manual confirmation, or blocking; at the same time, the controlled tool call chain also includes: each tool node must simultaneously meet the following conditions: the integrity of the input field is not lower than the preset input integrity threshold, the contraindication conditions do not conflict with the clinical state vector, the calling permission meets the current user's permission, and the corresponding risk constraint control strategy is not blocking.

[0012] Furthermore, calculating the strength of conflicting evidence involves calculating the sum of the products of the four elements: Confidence product: the product of the confidence levels of the two pieces of evidence; Opposite direction indicator: An indicator that measures whether the directions of evidence conflict; Semantic consistency: Based on the path distance calculation of medical ontology, the smaller the distance, the higher the consistency; Time consistency: Calculated based on event time difference and time decay coefficient; the smaller the time difference, the higher the consistency.

[0013] Furthermore, a physician feedback and threshold adaptation mechanism is implemented: This mechanism records physician feedback on the adoption, rejection, modification, or ignoring of clinical decision support suggestion cards, along with the reasons noted; it utilizes the collected feedback, combined with clinical state vectors and structured evidence packages, to update the selection weights of tool nodes; and it automatically adjusts the trigger thresholds for corresponding types of reminders based on the difference between the historical rejection rate and the target rejection rate for similar reminders in similar patient states.

[0014] On the other hand, the present invention also provides an AI-CDSS system based on multi-source medical event graphs and risk constraint tools, for executing an AI-CDSS method based on multi-source medical event graphs and risk constraint tools, including: Multi-source medical data access module: used to obtain patient-related data from internal and external hospital systems; Medical event standardization module: used to uniformly convert data from different systems into medical event nodes; Patient Medical Event Graph Construction Module: Used to construct a patient medical event graph based on medical event nodes; Clinical status vector generation module: used to generate clinical status vectors based on the patient's medical event graph, the doctor's current operation behavior, the patient's treatment stage, department information, disease pathway nodes, and the current medical order status; Medical Capability Graph Module: Used for registering and managing callable medical tools; Risk-constrained tool orchestration module: used to screen, block, downgrade, or force manual confirmation of candidate tools and actions based on clinical status vector, tool risk level, patient risk level, input completeness, and calling permissions, and generate a controlled tool calling chain; Multi-source evidence consistency verification module: used to calculate semantic consistency, temporal consistency, multimodal consistency, guideline consistency, and conflict intensity of evidence returned from different tools, modalities, and sources, and generate a structured evidence package; Recommendation Card Generation Control Module: Used to determine the level of clinical decision support recommendation card to be generated based on whether the structured evidence package meets the preset minimum sufficient evidence set conditions; Doctor feedback and threshold adaptation module: This module collects doctors' acceptance, rejection, neglect, modification, and reason annotation of suggestion cards, and adjusts the trigger threshold, tool selection weight, and reminder frequency based on patient status similarity, departmental differences, and historical feedback.

[0015] On the other hand, the present invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of an AI-CDSS method based on multi-source medical event graphs and risk constraint tools.

[0016] Compared with the prior art, the beneficial effects achieved by the present invention are: (1) Improve the consistency of heterogeneous medical data processing: This invention transforms multi-source medical data into unified event nodes and relation edges through patient medical event graphs, reducing false triggering caused by differences in data formats of different systems.

[0017] (2) Improve the security of tool calls: This invention clarifies the input constraints, indications, contraindications, risk levels and permission requirements of each tool through a medical capability map, thus avoiding the problem of intelligent agents freely calling inapplicable tools.

[0018] (3) The present invention uses a risk constraint matrix to shield, downgrade or force manual confirmation of candidate actions, thereby avoiding the system from automatically outputting high-risk diagnosis and treatment actions and reducing the risk of outputting high-risk medical actions.

[0019] (4) This invention improves the ability to identify evidence conflict by using semantic consistency, temporal consistency, multimodal consistency, guideline consistency and conflict intensity calculation to identify inconsistencies between medical records, test results, imaging AI, medical orders and guideline rules.

[0020] (5) This invention judges by the minimum sufficient evidence set and generates evidence completion prompts when key evidence is missing, but does not generate clear treatment suggestions, thereby reducing the hallucination output in the case of insufficient evidence; at the same time, by outputting structured evidence packages and suggestion cards, each reminder can be traced back to the specific event, source system, occurrence time and tool call result, thereby improving the traceability of CDSS output.

[0021] (6) This invention dynamically adjusts the trigger threshold and tool weights based on doctor feedback and patient status similarity, reducing low-value reminders that are rejected frequently over a long period of time and reducing alarm fatigue; and the tool nodes in the medical capability graph can be expanded according to specific diseases, applicable to various AI-CDSS scenarios such as VTE, atrial fibrillation, stroke, chest pain, pulmonary nodules, aortic dissection, postoperative management of orthopedic surgery, and chronic disease management, enhancing the scalability of multiple specific diseases. Attached Figure Description

[0022] Figure 1 This is a schematic diagram of the AI-CDSS system module composition provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of the operation logic of the AI-CDSS method provided in the embodiments of the present invention; Figure 3 This is a schematic diagram of the risk constraint tool orchestration process provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the multi-source evidence consistency verification and recommendation card generation process provided in the embodiments of the present invention. Detailed Implementation

[0023] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention are within the scope of protection of the present invention.

[0024] This invention provides a technical solution for an AI-CDSS method, system, and storage medium based on multi-source medical event graphs and risk constraint tool orchestration. Its core improvement lies in: transforming multi-source heterogeneous medical data into a unified structured patient state representation, and completing the orchestration and suggestion generation of computable, verifiable, and auditable controlled tools under the constraints of medical capability graphs, risk constraint matrices, and multi-dimensional evidence consistency verification mechanisms. This solves the problems of insufficient security constraints and lack of evidence verifiability in existing systems under multi-source heterogeneous medical data scenarios.

[0025] This invention ultimately achieves the following objectives: (1) Transform multi-source heterogeneous medical data into a unified patient medical event graph.

[0026] (2) Generate clinical state vectors based on patient diagnosis and treatment stages, doctor operation behavior and patient event graphs.

[0027] (3) Construct a medical capability map that includes input constraints, indications, contraindications, risk levels and permission information.

[0028] (4) The candidate actions of the agent are masked, downgraded or forced to be manually confirmed by the risk constraint matrix.

[0029] (5) Perform semantic, temporal, multimodal and guideline consistency checks on the results returned by multiple tools.

[0030] (6) Control the generation level of CDSS recommendation cards based on the minimum sufficient evidence set.

[0031] (7) Dynamically adjust the trigger threshold and tool selection weight based on doctor feedback to reduce invalid reminders and false triggers.

[0032] Example 1: like Figure 1 As shown in the figure, the AI-CDSS system based on multi-source medical event graphs and risk constraint tools described in this embodiment includes: Multi-source medical data access module: Used to obtain patient-related data from internal and external hospital systems, including but not limited to: Electronic Medical Record (EMR), Hospital Information System (HIS), Laboratory System (LIS), Picture Archiving and Communication System (PACS), Radiological Information System (RIS), Medical Order System, Nursing Record System, Surgical Anesthesia System, Pharmacy Review System, Disease Management System, Follow-up System, Image AI Analysis System, Regional Medical Platform or Medical Consortium Platform.

[0033] Medical Event Standardization Module: This module is used to uniformly convert data from different systems into medical event nodes. Each medical event node includes at least: event type, event time, data source, standard medical code, raw text or numerical value, confidence level, level of evidence, effective time window, and correlation with other events.

[0034] The Patient Medical Event Graph Construction Module is used to construct a patient medical event graph based on medical event nodes, expressing the patient's diagnosis and treatment timeline, clinical issues, sources of evidence, and temporal / causal / supporting / conflicting relationships between events.

[0035] Clinical status vector generation module: used to generate clinical status vectors based on the patient's medical event graph, the doctor's current operation behavior, the patient's treatment stage, department information, disease path nodes, and the current medical order status.

[0036] The Medical Capability Graph module is used to register and manage callable medical tools. Each tool node has structured metadata, including input field constraints, output field constraints, indication conditions, contraindication conditions, applicable departments, applicable treatment stages, risk level, evidence level, calling permissions, confidence threshold, and calling cost.

[0037] Risk-constrained tool orchestration module: This module is used to filter, block, downgrade, or force manual confirmation of candidate tools and actions based on clinical status vectors, tool risk levels, patient risk levels, input completeness, and calling permissions, and to generate a controlled tool call chain.

[0038] Multi-source evidence consistency verification module: used to calculate semantic consistency, temporal consistency, multimodal consistency, guideline consistency, and conflict intensity of evidence returned from different tools, modalities, and sources, and generate a structured evidence package.

[0039] The suggestion card generation control module is used to determine the level of clinical decision support suggestion card to be generated based on whether the structured evidence package meets the preset minimum sufficient evidence set conditions; when the evidence is insufficient, it generates evidence completion prompts instead of directly generating treatment suggestions.

[0040] Doctor feedback and threshold adaptation module: This module collects doctors' acceptance, rejection, neglect, modification, and reason annotation of suggestion cards, and adjusts the trigger threshold, tool selection weight, and reminder frequency based on patient status similarity, departmental differences, and historical feedback.

[0041] Example 2 Combination Figure 2 As shown, this embodiment describes the AI-CDSS method based on multi-source medical event graphs and risk constraint tools used in the system operation provided in Embodiment 1, which includes the following steps: Step S1: Connect to the multi-source medical data access module through a standard interface to obtain multi-source medical data of the target patient from multiple terminals, including electronic medical record system, hospital information system, laboratory system, image archiving and communication system, and medical order system.

[0042] Step S2: Convert the acquired multi-source medical data into medical event nodes, and construct a patient medical event graph based on the temporal, supporting, conflicting, and causal relationships between the medical event nodes. .

[0043] In this embodiment, the multi-source medical data of the target patient is represented as a patient medical event graph:

[0044] in, A diagram representing the medical events of the target patient. Represents a set of medical event nodes. This represents a set of relationships between event nodes. This represents the set of attributes for event nodes and edges. Each event node... It can be defined as:

[0045] in, Event types, such as diagnosis, symptoms, tests, imaging, medical orders, surgery, nursing care, follow-up, etc. For the event source system, The time when the event occurred. For standard medical coding, For event values, For the confidence level of the event, For the level of evidence, For the effective time window of the event, This is the original data content. Event edge. It can be defined as:

[0046] in, This indicates the type of relationship between two events, including temporal relationships, supporting relationships, conflict relationships, causal relationships, path relationships, etc. Indicates the time difference between events. Indicates the relation weight.

[0047] Step S3: Generate a clinical state vector based on the patient's medical event graph, physician's actions, and treatment stages. Medical Capability Map The tool nodes in the dataset are matched, and the matching score of each tool is calculated to form a set of candidate tools.

[0048] In this embodiment, a clinical state vector is generated based on the patient's medical event graph, the doctor's operational behavior, and the stage of diagnosis and treatment. :

[0049] in, Represents the clinical state vector. Represents a patient's medical event diagram. This indicates the doctor's current action, such as opening medical records, writing prescriptions, reviewing imaging, or filling out a discharge summary. This indicates the stages of a patient's treatment, such as admission, pre-operative, post-operative, discharge, and follow-up. This indicates the set of identified risk labels. This represents the current medical order status. The clinical status vector can be expanded as follows:

[0050] in, Indicates a disease or diagnostic status. Indicates the stage of the diagnosis and treatment process. Indicates a risk label. This indicates that the inspection and testing are complete. Indicates the status of medical orders. Indicates contraindications or conflicting conditions. This indicates the data quality or missing status.

[0051] Redefining the Healthcare Capability Map for:

[0052] in, Represents a set of medical tool nodes. This indicates the dependency, prerequisite, mutual exclusion, or composition relationships between tools. This represents a collection of utility attributes.

[0053] Further define each medical tool node for:

[0054] in, Constraints for input fields, Constrain the output fields. To meet the indications, For contraindication conditions, As for the risk level of the tool, To grant access permissions, As a credibility threshold, This refers to the cost of invocation or the consumption of computing resources.

[0055] The final candidate tool matching score is:

[0056] in, These are the weighting coefficients for each item. Indicates the completeness of the input field. Indicates the degree of indication matching. Indicates the degree of matching at each stage of diagnosis and treatment. This indicates the degree of risk level matching and the degree of permission fulfillment. Indicates the intensity of the contraindication conflict.

[0057] The integrity representation of the input field is also defined as follows:

[0058] in, Representation tools The set of required input fields, This indicates the set of fields currently available to the patient. Below the preset confidence threshold At this time, the tool does not output a final conclusion, but only outputs the following set of missing fields: .

[0059] Step S4: Based on the patient's risk level, tool risk level, action type, input field completeness, indications, contraindications, and access permissions, utilize the risk constraint function. Allow, downgrade, force confirmation, or block candidate actions.

[0060] In this embodiment, combined with Figure 3 As shown, the risk constraint function is defined as follows:

[0061] in, This indicates that execution is permitted. This indicates a downgrade in execution, for example, from "generate medical advice suggestions" to "remind doctor to review". This means that the procedure must be performed only after manual confirmation by a doctor. This indicates that the action is disabled.

[0062] Risk constraints can be represented by a risk matrix:

[0063] in Indicates the patient's risk level and action risk level The following action control strategy.

[0064] For example:

[0065] Step S5: Generate a controlled tool call chain based on the tool nodes that have passed the risk constraint verification. The order of invocation is determined according to tool dependencies, input-output relationships, and risk levels.

[0066] In this embodiment, a controlled tool call chain is generated after tool matching and risk constraints. as follows:

[0067] in, Indicates by arrive A total of r tools are arranged in sequence, and the call chain must satisfy: Input confidence constraints: That is, it iterates through all tool instances in the call chain, uses the model's quantitative evaluation value (usually a probability value between 0 and 1) of the degree of matching between the current input and the tool, and determines the tool. The relationship between input confidence and input confidence threshold is defined so that a tool is only allowed to be added to the call chain when the confidence is higher than the set threshold. This is to ensure that each selected tool is highly matched with the user input and to avoid calling irrelevant tools.

[0068] Risk constraint check: ; This flag represents the system's assessment of the risk of using the tool; true indicates that there is risk, and false indicates that there is no risk. For different business scenarios, such as "customer service refunds" and "financial transfers", different risk control strategies are adopted to ensure that all tools in the call chain are safe and free of risks in the current scenario.

[0069] User permission verification: ; For users to use tools The permission verification result, This indicates the user identity of the current user, meaning the system checks whether the current user has permission to call the tool. True indicates permission, and false indicates no permission, ensuring that only users with the appropriate permissions can call sensitive tools and preventing unauthorized operations.

[0070] Risk Action Interception: ; For tools Risk action assessment results in scenario Sc This refers to the system's assessment of the potential risk level of actions that may result from tool calls. It is typically divided into four levels: allow, degrade, require_confirm (evidence supplementation or manual confirmation), and block. When this occurs... When an interception flag is set, it indicates that the tool call is high-risk and must be blocked to ensure that there are no tool call actions marked as high-risk by the system in the call chain.

[0071] If any of the above conditions are not met, the tool call chain will be suspended, downgraded, or converted to an evidence completion process. Specifically: Abort the process: Directly terminate the execution of the current tool call chain and return an error message to the user; Downgrade processing: Replace the original tool with a low-risk alternative tool or a manual review process; Evidence supplementation: Requires users to provide more information or verify their identity to meet the constraints.

[0072] Step S6: Sequentially call the risk scoring tool, guideline rule tool, imaging AI tool, pharmaceutical review tool, medical order completeness check tool, medical record quality control tool, and follow-up task tool to obtain multiple structured evidence items. .

[0073] In this embodiment, each piece of evidence returned by the definition tool call is defined. Represented as:

[0074] in, Indicate the source of the evidence. Indicate the type of evidence. Indicate the time of evidence, Indicates medical code, Indicates the evidence value. Indicate the direction of evidence, including support, opposition, and neutral. Indicates the confidence level of the evidence. This indicates information about the source of evidence.

[0075] Step S7: Calculate the semantic consistency, temporal consistency, multimodal consistency, guideline consistency, and conflicting evidence strength of multi-source evidence; identify supporting evidence, conflicting evidence, missing evidence, and expired evidence; and generate a structured evidence package. .

[0076] In this embodiment, the consistency score of multi-source evidence is... The calculation is as follows:

[0077] in, These are the weighting coefficients. Indicates semantic consistency; Indicates time consistency; Indicates multimodal consistency; This indicates consistency with the guidelines; Indicates the strength of conflicting evidence.

[0078] Semantic consistency is calculated based on standard medical coding, synonym mapping, or medical ontology path distance:

[0079] in, The semantic consistency score measures the semantic similarity between two medical terms, with values ​​ranging from [value range missing]. A higher score indicates a closer semantic connection; For two medical terms or concepts to be compared, in this invention they can be natural language descriptions (e.g., "ground-glass opacity in the lower lobe of the left lung"), medical codes (e.g., ICD-10 code J84.1), or standardized terms. This represents the path distance between two medical codes within a medical ontology or knowledge graph. This indicates a medical standard code.

[0080] Consistency in computation time is as follows:

[0081] in, For time consistency score, It indicates the time when the first medical event occurred, usually stored in timestamp or date format; Indicates the time of occurrence of the second medical event, and Use the same time format; This represents the time decay coefficient in the corresponding clinical setting.

[0082] Multimodal consistency regarding whether different modalities of evidence, such as text, verification, image AI, and medical orders, mutually support each other. Perform the calculation:

[0083] in, Represents a set of cross-modal evidence pairs. and The feature mapping function representing different modalities, here Indicates the first Article from the first The original evidence data for each modality, Indicates the first One piece of raw evidence data from the nth modality. Represents the similarity function. Indicates the quantity of evidence.

[0084] Guideline consistency can be defined as the degree of matching between evidence items and the triggering conditions of guideline rules:

[0085] in, This represents the set of guideline rules that the current evidence satisfies. This represents the set of guideline rules and conditions required to generate target recommendations.

[0086] Defining the strength of conflicting evidence for:

[0087] in, and Indicates the confidence level of a single piece of evidence, reflecting the reliability of the evidence. This represents the set of candidate conflicting evidence pairs. As an indicator function, when two pieces of evidence with high confidence and close time are semantically related but in opposite directions, the conflict strength is high. Indicates the first Article, No. The direction of the conclusions drawn from the evidence, such as the increase / decrease in disease progression or the abnormal direction of indicators, is considered. Through multi-dimensional weighted calculations, the conflict intensity significantly increases when high-confidence, time-proximity, and semantically relevant evidence points to opposing conclusions.

[0088] Step S8: Generate a comprehensive data structured evidence package containing multi-dimensional evidentiary information, and determine whether the structured evidence package meets the minimum sufficient evidence set for the corresponding scenario. It also determines whether the evidence consistency score exceeds the threshold and whether the number of conflicting evidences is below the threshold, and generates CDSS suggestion cards or evidence completion prompts based on the judgment results.

[0089] In this embodiment, combined with Figure 4 As shown, the final generated data structure evidence package contains multi-dimensional evidentiary information. :

[0090] in, Indicates the type of candidate conclusion, which is a possible result obtained from the system analysis; Indicates the risk level, reflecting the severity of the decision; This indicates a set of supporting evidence, representing positive evidence that supports the candidate conclusion; This refers to a set of conflicting evidence, which contradicts the candidate conclusion. This represents a set of neutral evidence. This indicates a missing set of evidence, representing key evidence that needs to be supplemented. This refers to a collection of expired evidence, evidence that has exceeded its validity period. The consistency score indicates the degree of coordination among pieces of evidence. This indicates the suggested action level for allowed output, or the system's recommended action intensity.

[0091] Furthermore, a minimum sufficient evidence set is defined for different CDSS scenarios. :

[0092] in, Indicates the first The minimum set of evidence fields required for clinical decision support tasks.

[0093] The generation of suggestion cards of the corresponding level is allowed when the following three conditions are met: Completeness of evidence: That is, the minimum sufficient evidence set (MSE) k It must be included in supporting evidence Z + and neutral evidence Z 0 The evidence has been collected and is now focused, meaning that key evidence has been gathered.

[0094] Consistency of evidence: That is, the consistency score of evidence. It must be greater than or equal to the set threshold. This ensures that there are no contradictions among the evidence.

[0095] Limitations on conflicting evidence: That is, the set of conflicting evidence The number is less than or equal to the threshold To avoid serious disagreements.

[0096] If the above three conditions are not met, no treatment suggestion will be generated; instead, a prompt to complete the missing evidence will be output. :

[0097] This means identifying the key evidence that needs to be supplemented.

[0098] For example, the CDSS recommendation card in this invention may include the following fields: {"card_id":"CDSS-20260702-0001", "patient_id_hash":" ", "scenario":"VTE_PREVENTION", "risk_level":"HIGH", "evidence_consistency_score":0.86, "supporting_evidence":[ { "type":"SURGERY", "value":"Day 1 post-hip replacement surgery", "source":"surgical record", "time":"2026-07-01 10:30:00" }, { "type":"NURSING", "value":"Limited mobility due to bed rest", "source":"nursing record", "time":"2026-07-02 08:00:00" } ], "conflicting_evidence":[], "missing_evidence":[], "expired_evidence":[], "allowed_action_level":"RISK_REMINDER_REQUIRE_CONFIRM", "recommendation": "There is evidence of high risk associated with VTE. Please have your doctor review the assessment to determine if preventative measures are necessary." "doctor_actions":[ "Accept", "Do not accept", "View evidence", "Fill in the reason for inapplicability" } The suggestion card of this invention does not automatically write diagnoses, automatically issue medical orders, or replace the doctor's clinical judgment.

[0099] Step S9: Receive feedback from doctors regarding the adoption, rejection, modification, or ignoring of suggestion cards, and update the tool selection weights, trigger thresholds, and departmental localization reminder strategies.

[0100] In this embodiment, doctor feedback is defined. for:

[0101] in, The system receives doctors' responses to suggestion cards, including acceptance, rejection, modification, neglect, and feedback, forming a feedback set.

[0102] Tool selection weights are dynamically adjusted based on feedback, clinical status vectors, and the quality of the evidence package, i.e., for each tool... The selection weights can be updated as follows:

[0103] in, Indicates the first Wheel tools The selection weight, Indicates the learning rate. This represents an update function based on physician feedback, clinical state vectors, and the quality of the evidence package.

[0104] The alert trigger threshold is adjusted based on the historical rejection rate; that is, the trigger threshold for a certain type of alert can be updated as follows:

[0105] in, The updated alert trigger threshold is t+1, which represents the next round and the optimized state. The alert specifically refers to the trigger threshold for various alerts in the clinical decision support system. This is the reminder trigger threshold for the current round (round t), which is the original threshold before optimization; Indicates the adjustment factor. This indicates the historical rejection rate of similar reminders in similar patient conditions, that is, the actual proportion of doctors rejecting such reminders, reflecting the effectiveness of the reminders; The target rejection rate, or target rejection rate, is the percentage of rejections the system aims to achieve. It balances the clinical value of alerts with the workload of physicians, preventing excessive invalid alerts from causing alarm fatigue. By comparing the actual rejection rate with the target value, the system dynamically adjusts the alert triggering threshold. When the actual rejection rate exceeds the target value, the system raises the triggering threshold to reduce the frequency of similar alerts; conversely, it appropriately lowers the threshold to ensure necessary clinical prompts. For example, if a certain type of alert is consistently rejected frequently in a particular department or among a certain type of patient, the system raises the triggering threshold or lowers the alert level to reduce alarm fatigue. This achieves fully controlled processing from the access of multi-source medical data to the output of clinical decision support suggestion cards. It comprehensively solves the technical problems of inconsistent representation of multi-source heterogeneous medical data, lack of security constraints in tool calls, unquantifiable evidence conflicts, and insufficient control over suggestion generation.

[0106] Example 3 Based on Example 1, this embodiment uses the prevention of postoperative venous thromboembolism in orthopedic surgery as an example to specifically illustrate the implementation of the present invention in a disease-specific clinical decision support scenario: Example scenario: The patient is a post-orthopedic surgery patient. The system automatically triggers a venous thromboembolism prevention assessment task when the doctor opens the post-operative medical order page.

[0107] (a) The system acquires the following data: Surgical record: Day 1 post-hip replacement surgery; Nursing record: Bedridden, limited mobility; Past medical history: history of venous thrombosis; Test results: D-dimer levels were elevated; Medical record: No description of active bleeding found; Medical order system: No orders for anticoagulants or mechanical prophylaxis were found; Pharmaceutical system: No clear anticoagulant drug conflicts were found.

[0108] (ii) The system constructs the following event nodes: Event node v1 is a surgical event, and its content is hip replacement surgery; Event node v2 is a time-phased event, and its content is the first day after surgery; Event node v3 is a nursing event, and its content is limited movement while in bed; Event node v4 is a medical history event, containing a history of venous thrombosis. Event node v5 is a test event, and its content is an increase in D-dimer levels; Event node v6 is a medical record event, and its content is "no active bleeding was found". Event node v7 is a medical order event, and its content is: no anticoagulation or mechanical prophylaxis orders were found.

[0109] Establish relationship edges between event nodes based on the patient medical event graph construction module: e12 indicates that the surgical event supports postoperative stage identification; e23 indicates that the postoperative stage is associated with limited mobility; e34 indicates that limited activity and a history of thrombosis together support an increased risk of venous thromboembolism; e57 indicates that elevated D-dimer levels and the absence of preventative medical advice jointly trigger a review reminder.

[0110] (III) System generates clinical state vector:

[0111] Each dimension corresponds to one of seven dimensions: D represents the orthopedic diagnosis status, T represents the postoperative stage, R represents the risk label for venous thromboembolism, M represents the completion status of the D-dimer test, O represents the status of no preventive medical advice, C represents the status of no bleeding contraindications, and Q represents the status of complete data.

[0112] (iv) Matching of medical capability maps The system matched the following candidate tools: Caprini scoring tool, bleeding risk review tool, anticoagulation contraindication review tool, medical order completeness check tool, venous thromboembolism guideline rule tool, and suggestion card generation tool. The completeness of the input fields for each tool met the preset input completeness threshold, the indication conditions matched the clinical state vector, and the contraindication conditions were conflict-free.

[0113] (v) Risk constraint action shielding Screening Strategy Determination: The system queries the risk constraint matrix through the risk constraint tool orchestration module and determines the "automatically generate anticoagulant orders" action as a screening strategy.

[0114] in, It is a risk constraint function used to determine the risk control strategy for medical procedures. This indicates a high-risk medical action that automatically generates anticoagulation orders. This is a current clinical scenario, specifically a scenario for the prevention of venous thromboembolism (VTE) after orthopedic surgery. This refers to the anticoagulant medication prescription generation tool, which is the functional module in the system responsible for automatically generating anticoagulant-related prescriptions. The blocking strategy is the highest level control strategy in the risk constraint matrix. It means that the action is prohibited from being executed automatically, directly intercepting high-risk operations and avoiding medical safety hazards.

[0115] Mandatory manual verification: The action of "generating a risk review recommendation card for venous thromboembolism (VTE)" is classified as a mandatory manual verification strategy.

[0116] in, In this embodiment, the action for generating clinical recommendation cards specifically refers to the action of "generating VTE risk review recommendation cards". This is a VTE risk assessment tool, specifically a functional module in the system responsible for generating risk-related recommendation cards for venous thromboembolism. This mandatory manual confirmation strategy is a medium-risk control strategy, meaning that the action cannot be executed automatically and must be manually confirmed by a doctor before it can proceed. This ensures both medical safety and the efficiency of clinical decision-making.

[0117] The controlled tool call chain is generated according to the above constraints, and the high-risk actions of automatically generating medical orders are effectively shielded.

[0118] (vi) Verification of Evidence Consistency In this embodiment, the system verifies the evidence items returned by each tool: the supporting evidence set includes five items: post-hip replacement surgery, limited bed rest, history of venous thrombosis, elevated D-dimer levels, and no current preventative medical advice. The conflicting evidence set, missing evidence set, and expired evidence set are defined as empty. The system calculates an evidence consistency score. The preset threshold for evidence consistency is ,because Furthermore, it satisfies the minimum sufficient evidence set for VTE, therefore the system generates a high-risk VTE recommendation card.

[0119] (vii) Output Results The system ultimately outputs evidence related to the patient's high risk of VTE. The system has identified postoperative status, limited activity, history of thrombosis, elevated D-dimer levels, and missing current preventative medication orders. The doctor should review whether a VTE preventative measures assessment is necessary. The doctor can choose to: adopt the suggestion, temporarily disregard it, review the chain of evidence, fill in the reason for inapplicability, or add it to the pending review.

[0120] This embodiment verifies the shielding effect of the risk constraint matrix on high-risk actions (automatic issuance of anticoagulation orders) and the effectiveness of the control suggestion card generation under the minimum sufficient evidence set condition (evidence consistency score of 0.86 is greater than the threshold of 0.75), proving that the system does not replace the doctor's clinical judgment.

[0121] Example 4 This embodiment, also based on Embodiment 1, takes the multi-source evidence conflict identification scenario of pan-vascular artificial intelligence clinical decision support (AI-CDSS) as an example to specifically illustrate the implementation of the present invention in the cross-modal evidence conflict processing scenario.

[0122] Scenario Description: A patient undergoes coronary computed tomography (CT) angiography. The image analysis system outputs the results of vascular stenosis and calcification scores. The system combines medical records, laboratory results, past medical history, doctor's orders, and guidelines to generate a comprehensive vascular risk assessment.

[0123] (a) Convert the acquired data into the following medical event nodes: Event node v1 is an image AI event, and its content is an increase in coronary artery calcium score; Event node v2 is an image AI event, and its content is the risk of moderate to severe coronary artery stenosis; Event node v3 is the test event, and its content is elevated low-density lipoprotein cholesterol; Event node v4 is a medical record event, containing a history of diabetes. Event node v5 is a medical order event, and its content is: no lipid-lowering medication was found. Event node v6 is a guideline rule event, and its content is that the conditions for further cardiovascular risk assessment are met.

[0124] (ii) Multimodal consistency verification: The system performs cross-modal consistency calculations on imaging AI, laboratory tests, medical records, and medical orders:

[0125] Where N is the total number of evidence pairs. Feature mapping similarity function 、 For feature mapping functions of different modalities, 、 For event nodes from different modalities, If the imaging AI indicates a high risk, and the test results and medical history also support an increased risk, and no corresponding risk management measures are found in the medical prescription, then a "Cardiovascular Risk Management Review Recommendation Card" will be generated.

[0126] If the image AI indicates an anomaly but the image report text does not describe it, the system will mark the result as a conflicting evidence pair as follows:

[0127] Instead of directly providing diagnostic suggestions, it generates a prompt stating, "There is an inconsistency between the AI ​​imaging results and the report text. Please have the doctor review the original images."

[0128] This embodiment verifies the effectiveness of the multimodal consistency verification mechanism in identifying inconsistencies between AI results and image report text, as well as the control capability of the minimum sufficient evidence set condition in preventing the output of misleading suggestions in the event of evidence conflict.

[0129] Example 5 In this embodiment, the system performs quality control on medical records and checks the consistency of medical orders. Specifically, when a doctor issues a medical order or submits a medical record, the system automatically checks whether the diagnosis, medical record description, examination and testing, medication orders, and path nodes are consistent.

[0130] In this embodiment, the system can identify the following conflicts: conflict between diagnosis and medical orders, conflict between medical record description and test results, conflict between AI imaging results and imaging reports, missing guideline path nodes, conflict between medication contraindications, missing high-risk scoring fields, examination results exceeding the effective time window, and inconsistencies between discharge summary and inpatient treatment process.

[0131] The system performs evidence consistency scoring and risk constraint processing on candidate quality control issues. For cases with insufficient evidence, the system only prompts for field completion: "Anticoagulation risk review cannot be completed at present; recent platelet counts and active bleeding records are missing. Please supplement and re-evaluate." For cases with sufficient evidence and clear conflicts, the system outputs a quality control suggestion card: "There is a potential conflict between the current diagnostic record and medication orders; please have the doctor review it." Supporting evidence includes: diagnostic events, medication events, contraindication rules, and recent test results. Through multimodal consistency verification and evidence constraint processing, the system effectively prevents misleading suggestions and improves medical quality.

[0132] Finally, compared with traditional CDSS, general intelligent agents, and ordinary medical large model systems, this invention has at least the following differences:

[0133] The above comparison results show that the present invention, through the synergistic effect of patient multi-source medical event graph, clinical state vector, medical capability graph matching, risk constraint matrix, multi-dimensional evidence consistency verification and minimum sufficient evidence set control, is significantly superior to the prior art in dimensions such as false trigger rate, evidence conflict identification rate, hallucination output control and high-risk action shielding, and verifies the unexpected technical effects brought about by the distinguishing technical features.

[0134] Meanwhile, the patient multi-source medical event graph in the above embodiments of the present invention is not limited to graph database storage. It can also be implemented by a hybrid storage method of relational database, document database or vector database. For example, the event node attributes can be stored in a relational database and the event relationship edges can be stored in a graph database, as long as it can support the query and reasoning of multiple types of relationships between nodes.

[0135] Furthermore, the standard medical codes in the above embodiments are not limited to the International Classification of Diseases (ICD) codes. They can also be the clinical version of the Systematic Medical Terminology Nomenclature, logical observation identifier names and codes, standardized drug nomenclature codes, medical insurance codes, hospital ontology codes, or multi-code mapping tables, as long as they can support medical ontology path distance calculation.

[0136] The medical tool invocation method in the above embodiments is not limited to the expressive state transfer application programming interface. It can also use remote procedure call protocol, message queue, clinical decision support hook interface, intelligent medical application programming interface or medical digital imaging and communication network service interface, as long as the input and output constraints of the controlled tool invocation chain can be met.

[0137] The semantic consistency calculation in the above embodiments is not limited to the exponential decay function based on the path distance of medical ontology. It can also be implemented by text embedding similarity, rule matching or knowledge graph reasoning. However, the high-risk action blocking rule should be retained as a deterministic safety boundary and should not be replaced by a purely probabilistic method.

[0138] Obviously, the suggested card output method in the above embodiments is not limited to embedding in the electronic medical record system. It can also be embedded in the hospital information system workstation, the image archiving and communication system reading workstation, the mobile application or the nurse station system, as long as the doctor's operation entry and audit number fields are retained.

[0139] It should be noted that, in this invention, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, 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 a process, method, article, or apparatus.

[0140] Finally, it should be noted that the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. An AI-CDSS method based on multi-source medical event graphs and risk constraint tools, characterized in that: The following steps are included: Acquire multi-source medical data of the target patient and convert it into medical event nodes, then construct a multi-source medical event graph of the patient based on the medical event nodes; Based on the patient's multi-source medical event graph, the doctor's current operational behavior, the patient's treatment stage, the set of identified risk labels, and the current medical order status, a clinical status vector is generated. The clinical status vector is matched with each tool node in the pre-constructed medical capability map, the matching score of each tool node is calculated, and a candidate medical tool set is obtained by screening. Based on the patient's risk level, the tool's risk level, the completeness of the input fields, and the calling permissions, a risk constraint control strategy is executed on each candidate action in the candidate medical tool set to generate a controlled tool calling chain. Using a controlled tool call chain, at least one medical tool is invoked sequentially, and multiple evidence items are output. Perform semantic consistency, temporal consistency, multimodal consistency, and guideline consistency checks on multiple evidence items, calculate the strength of conflicting evidence, identify supporting evidence sets, conflicting evidence sets, neutral evidence sets, missing evidence sets, and expired evidence sets, and generate a structured evidence package; Determine whether the structured evidence package meets the pre-set minimum sufficient evidence set conditions. When the structured evidence package meets the minimum sufficient evidence set conditions, generate a clinical decision support suggestion card. When the structured evidence package does not meet the minimum sufficient evidence set condition, an evidence completion suggestion is generated.

2. The AI-CDSS method based on multi-source medical event graphs and risk constraint tools as described in claim 1, characterized in that: Medical event nodes include: event type, event time, data source, standard medical code, event value, confidence level, and effective time window attributes; Constructing a multi-source medical event graph for patients based on medical event nodes includes: constructing a multi-source medical event graph for patients based on the temporal relationships, support relationships, conflict relationships, and causal relationships between medical event nodes; Each tool node in the medical capability graph includes: input field constraints, output field constraints, indication conditions, contraindication conditions, risk level, access permissions, and credibility threshold attributes.

3. The AI-CDSS method based on multi-source medical event graphs and risk constraint tools as described in claim 2, characterized in that: The calculation of the matching score for each tool node includes: Calculate the integrity of the input fields; Calculate the degree of matching of indications, degree of matching of treatment stage, degree of matching of risk level, degree of satisfaction of authority, and degree of conflict of contraindications; The matching score is obtained by weighting and summing the input field completeness, indication matching degree, treatment stage matching degree, risk level matching degree and permission satisfaction degree, and then subtracting the weighted value of the contraindication conflict intensity. When the completeness of the input fields is lower than the preset input completeness threshold, the tool node will not output the final conclusion, but only the set of missing fields.

4. The AI-CDSS method based on multi-source medical event graphs and risk constraint tools as described in claim 3, characterized in that: The tool nodes in the medical capability graph also include: dependency relationships, prerequisite relationships, mutual exclusion relationships, and composition relationships; the tool nodes also include applicable departments and applicable treatment stages attributes.

5. The AI-CDSS method based on multi-source medical event graphs and risk constraint tools as described in claim 4, characterized in that: The risk constraint control strategies include: allowing, downgrading, mandatory manual confirmation, or blocking; The controlled tool call chain also includes the requirement that each tool node must simultaneously satisfy: The integrity of input fields is not lower than the preset input integrity threshold; The contraindication criteria do not conflict with the clinical state vector; The access permissions satisfy the current user's permissions. The corresponding risk constraint control strategy is not shielded.

6. The AI-CDSS method based on multi-source medical event graphs and risk constraint tools as described in claim 5, characterized in that: Calculating the strength of conflicting evidence involves calculating the sum of the products of the four elements: Confidence product: the product of the confidence levels of the two pieces of evidence; Opposite direction indicator: An indicator that measures whether the directions of evidence conflict; Semantic consistency: Based on the path distance calculation of medical ontology, the smaller the distance, the higher the consistency; Time consistency: Calculated based on event time difference and time decay coefficient; the smaller the time difference, the higher the consistency.

7. The AI-CDSS method based on multi-source medical event graphs and risk constraint tools as described in claim 6, characterized in that: The minimum sufficient set of evidence conditions include: The minimum set of evidence fields required for the minimum sufficient evidence set is covered by the union of the supporting evidence set and the neutral evidence set; The evidence consistency score is not lower than the preset evidence consistency threshold; The number of elements in the conflict evidence set does not exceed a preset threshold for the number of conflict evidence elements; When the minimum sufficient evidence set condition is not met, the output evidence completion prompt contains the difference of the union of the minimum evidence field set, the supporting evidence set, and the neutral evidence set.

8. The AI-CDSS method based on multi-source medical event graphs and risk constraint tools as described in claim 1, characterized in that: It also includes a doctor feedback and threshold adaptation mechanism: Record the doctor's feedback on the adoption, rejection, modification, or neglect of the clinical decision support suggestion card, and indicate the reasons; By utilizing the collected feedback, combined with clinical state vectors and structured evidence packages, the selection weights of tool nodes are updated; The trigger threshold for the corresponding type of reminder is automatically adjusted based on the difference between the historical rejection rate and the target rejection rate for similar reminders in similar patient conditions.

9. An AI-CDSS system based on multi-source medical event graphs and risk constraint tools, used to execute the AI-CDSS method based on multi-source medical event graphs and risk constraint tools as described in any one of claims 1-8, characterized in that: The system includes: Multi-source medical data access module: used to obtain patient-related data from internal and external hospital systems; Medical event standardization module: used to uniformly convert data from different systems into medical event nodes; Patient Medical Event Graph Construction Module: Used to construct a patient medical event graph based on medical event nodes; Clinical status vector generation module: used to generate clinical status vectors based on the patient's medical event graph, the doctor's current operation behavior, the patient's treatment stage, department information, disease pathway nodes, and the current medical order status; Medical Capability Graph Module: Used for registering and managing callable medical tools; Risk-constrained tool orchestration module: used to screen, block, downgrade, or force manual confirmation of candidate tools and actions based on clinical status vector, tool risk level, patient risk level, input completeness, and calling permissions, and generate a controlled tool calling chain; Multi-source evidence consistency verification module: used to calculate semantic consistency, temporal consistency, multimodal consistency, guideline consistency, and conflict intensity of evidence returned from different tools, modalities, and sources, and generate a structured evidence package; Recommendation Card Generation Control Module: Used to determine the level of clinical decision support recommendation card to be generated based on whether the structured evidence package meets the preset minimum sufficient evidence set conditions; Doctor feedback and threshold adaptation module: This module collects doctors' acceptance, rejection, neglect, modification, and reason annotation of suggestion cards, and adjusts the trigger threshold, tool selection weight, and reminder frequency based on patient status similarity, departmental differences, and historical feedback.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by the processor, it implements the steps of the AI-CDSS method based on multi-source medical event graphs and risk constraint tools as described in any one of claims 1-8.

Images