A real-time quality monitoring and control method and system applied to a clinical diagnosis and treatment process

Abstract

The application discloses a medical in-process quality control method and system based on closed-loop coupling and self-evolution rules, relates to the technical field of electronic digital data processing, and aims to solve the problems of existing quality control scheme rule update lag, AI and quality control logic fault, single variable dimension and alarm fatigue and the like. The method collects multi-source medical real-time data and standardizes processing, constructs a high-dimensional variable pool to generate a characteristic vector; an AI rule generation module calculates a risk probability and a key variable subset to generate a candidate quality control rule; a hot plug rule engine verifies and pushes a high-priority alarm in real time; the rule quality increment is calculated in combination with doctor feedback to realize rule self-adaptive upgrading, reservation or elimination, and feedback data backflow forms a closed loop. The application realizes real-time rule updating and self-adaptive optimization, reduces alarm fatigue, and improves the accuracy and efficiency of medical quality monitoring.

Description

Technical Field

[0001] This invention relates to the field of electronic digital data processing technology, and in particular to a method and system for real-time quality monitoring and control applied in clinical diagnosis and treatment. Background Technology

[0002] With the deepening of medical informatization, medical data is exhibiting characteristics of multi-source, real-time, and high-dimensionality. Utilizing information systems for real-time quality monitoring and intervention in the clinical diagnosis and treatment process (i.e., in-process quality control) has become a core means to improve medical quality, reduce medical risks, and ensure patient safety. In-process quality control can promptly detect violations, potential risks, or treatment behaviors that do not conform to clinical guidelines during medical procedures. Through real-time alerts and interventions, it can prevent adverse medical outcomes, making it far more important than traditional quality control models that rely on post-event review. Currently, mainstream medical in-process quality control solutions generally adopt a "rule engine" core architecture. Its technical implementation logic includes building a real-time data center that integrates structured data sources such as hospital information systems, electronic medical records, and laboratory systems. Medical experts pre-write static "if-then" rules based on clinical guidelines and store them in a rule base. Data streams are captured in real-time via message queues to trigger pattern matching, generating alerts that are then pushed to medical staff. Simultaneously, the rectification process is recorded, forming a preliminary quality control closed loop.

[0003] However, the aforementioned existing technical solutions have significant drawbacks in practical applications. Severely delayed rule updates: Rules rely on manual writing and review processes. When new risk scenarios or clinical guidelines are updated, the rule base cannot respond in a timely manner, resulting in monitoring blind spots and an inability to cover dynamically changing medical environments. Disconnect between AI technology and core quality control logic: Existing AI models are mostly used for post-event data analysis and fail to be deeply coupled with the in-process quality control rule engine, resulting in insufficient intelligence and an inability to achieve dynamic rule generation and adaptive optimization. Limited dimensionality of quality control variables: Existing solutions only focus on simple discrete variables, such as single vital sign thresholds, while ignoring high-dimensional and complex variables such as patient journey stages, time-series physiological variables, physician behavioral profiles, and environmental contexts. This results in weak ability to characterize complex medical scenarios, high false alarm rates, and difficulty in capturing multi-factor interaction risks. Lack of rule lifecycle management: After rule deployment, there is a lack of effective evaluation, upgrade, or elimination mechanisms. Low-quality rules accumulate continuously, leading to "alarm fatigue." Healthcare staff reduce their trust in the system due to frequent invalid alarms, and may even ignore critical alarms, weakening the quality control effect. Summary of the Invention

[0004] The purpose of this application is to provide a medical in-process quality control method and system based on closed-loop coupling and self-evolutionary rules, which has real-time rule update capability and adaptive optimization mechanism, effectively reducing alarm fatigue and improving the accuracy and efficiency of medical quality monitoring.

[0005] This application provides a medical in-process quality control method based on closed-loop coupling and self-evolution rules, including the following steps: Step S1: Collect multi-source real-time medical data and perform standardized processing; Step S2: Based on the standardized real-time data, calculate and update the high-dimensional variable pool in real time to generate feature vectors. ; Step S3: Process the feature vector using the AI ​​rule generation module. The process is performed to calculate the probability of a patient having a specific quality defect. and subset of key variables ; Step S4: Based on risk probability and subset of key variables Generate candidate quality control rules And assign an initial confidence level C0; Step S5: Utilize rules from the official rule base and candidate quality control rules through the hot-swappable rule engine. It performs millisecond-level verification on real-time data and generates alerts; Step S6: Record the doctor's response to the alert, including whether to accept or ignore it; Step S7: Calculate the rule quality increment for each rule based on feedback behavior using the rule evaluator. According to the rules, the quality increment The confidence function c(t) of the rule is used to upgrade, retain, or eliminate the rule; Step S8: Monitor and audit through a visual interface, and at the same time, feed back the feedback data corresponding to the feedback behavior to step S2 or step S3 to start the next learning cycle and form an R-AI-VAR closed loop.

[0006] Furthermore, in step S1, the data sources of multi-source real-time medical data include Hospital Information System (HIS), Electronic Medical Record (EMR), Laboratory Information System (LIS), vital signs monitors, and hand anesthesia systems; the standardization process involves uniformly converting heterogeneous data streams into HL7 or FHIR format and continuously writing them to the med_raw topic of the Kafka message queue with a 5-second time window.

[0007] Furthermore, the variables in the high-dimensional variable pool include patient journey stage variables, time-series physiological variables, physician behavioral profile variables, and environmental context variables; The patient journey stage variables include eight stage labels, such as "0-2 hours after admission", "24 hours before surgery", "0-72 hours after surgery", and "day of discharge". Time-series physiological variables include the 1-minute mean, slope of change, and coefficient of variation of heart rate (HR), blood pressure (BP), and blood oxygen saturation (SpO2); The physician behavior profile variables include the Z-score of the deviation between the physician's "antibiotic selection-discontinuation timing" and the clinical guideline recommendations when performing similar surgeries in the past 30 days; Environmental context variables include the status of the operating room laminar flow system and whether the current time is a holiday or night shift. Feature vector Updated once per second.

[0008] Furthermore, the AI ​​rule generation module includes a deep temporal subnet, an interpretable subnet, and a rule template engine; Step S3 includes: S31: The deep temporal subnetwork uses a 4-layer Transformer encoder as the backbone network, with input feature vectors... Output risk probability ; S32: Interpretable subnets can apply integrated gradients techniques to assess risk probability. Perform feedback calculations to obtain the contribution score of each input variable, and select the Top-K variables with the highest contribution to form the key variable subset Mt; S33: Rule template engine for risk probability and subset of key variables Make a judgment when the risk probability When the threshold is exceeded, a subset of key variables is generated. Corresponding candidate quality control rules .

[0009] Furthermore, in step S8, the visualization interface displays the lineage diagram of the rules, the confidence decay curve, and the real-time alarm queue, meeting the traceability requirements of medical supervision; the feedback data includes the doctor's feedback behavior and the corresponding patient variable data, which are used to retrain and fine-tune the model parameters of the deep time series subnet.

[0010] Furthermore, in step S4, the initial confidence level C0 is calculated using the formula C0 = ×Information gain; Candidate quality control rules Using the "IF-THEN" format, when the subset of key variables Mt contains "no anticoagulant administered 6 hours post-procedure", the generated candidate quality control rule is "IF post-procedure stage > 6h AND anticoagulant status = 'not administered' THEN trigger VTE prevention alarm".

[0011] Furthermore, the hot-swappable rule engine includes an inference kernel and a rule cache. The inference kernel uses an improved Rete-NN network, which can complete pattern matching and inference for more than 10,000 rules within 100ms. The rule cache is used to store candidate quality control rules Rnew. Candidate quality control rules Rnew must be triggered at least 3 times in real clinical scenarios and the corresponding alarm must be adopted by doctors before entering the rule verification stage.

[0012] Further, in step S7, the formula for calculating the rule quality increment ΔQ is ΔQ = (post-adoption defect correction rate − baseline correction rate) × weight; when the ΔQ of a candidate quality control rule > 0.05, it is automatically upgraded to a formal rule and added to the formal rule base; the formula for calculating the confidence function c(t) is... Where C0 is the initial confidence level, λ is the decay coefficient, and t is the time; when the confidence level of the rule continues to be lower than the lower threshold or ΔQ is negative, it is automatically migrated to the elimination zone and stopped from use.

[0013] Furthermore, in step S5, the alarm push adopts an intelligent push strategy. The priority of each alarm is calculated based on the comprehensive priority = c(t) × clinical impact × doctor's historical adoption rate. Only the top-N highest priority alarms are pushed, where N is a preset positive integer and N≥1.

[0014] Furthermore, a medical in-process quality control system based on closed-loop coupling and self-evolution rules, used to execute the above-mentioned medical in-process quality control method, includes: The system includes a multi-source real-time data acquisition module, a high-dimensional variable pool module, an AI rule generation module, a hot-swappable rule engine, and a closed-loop feedback and visualization module. These modules work together through a streaming data bus and a microservice channel. The streaming data bus is Kafka, and the microservice channel is REST or gRPC.

[0015] Compared with the prior art, this application has the following beneficial effects: This application provides a medical in-process quality control method and system based on closed-loop coupling and self-evolutionary rules. Through closed-loop coupling and self-evolutionary rules, it realizes real-time updating and adaptive optimization of medical in-process quality control. It has real-time rule updating capability and adaptive optimization mechanism, effectively reduces alarm fatigue, and improves the accuracy and efficiency of medical quality monitoring. Attached Figure Description

[0016] The following description, in conjunction with the accompanying drawings, further illustrates this application: Figure 1 A flowchart illustrating a medical in-process quality control method based on closed-loop coupling and self-evolution rules, provided as one embodiment of the present invention; Figure 2 This is a schematic diagram of the R-AI-VAR closed-loop workflow provided in one embodiment of the present invention; Figure 3 A schematic diagram illustrating the workflow of an AI rule generation module provided in one embodiment of the present invention; Figure 4 A schematic diagram illustrating the workflow of a hot-swap rule engine provided in one embodiment of the present invention; Figure 5 A schematic diagram illustrating a visual interaction provided in one embodiment of the present invention; Figure 6 This is a schematic diagram of a medical in-process quality control system based on closed-loop coupling and self-evolution rules, provided as one embodiment of the present invention. Detailed Implementation

[0017] The technical solutions of this application will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this application, and not all embodiments. The components of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0018] It should be noted that similar labels and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first" and "second" are used only to distinguish descriptions and should not be construed as indicating or implying relative importance. Traditional, existing medical in-process quality control schemes suffer from problems in practical applications, including lagging rule updates, untimely responses to new risks, a disconnect between AI technology and core quality control logic, insufficient intelligence, a single dimension of quality control variables, weak ability to characterize complex scenarios, and alarm fatigue due to a lack of rule lifecycle management. These problems limit the continuous improvement of medical quality and the effective protection of patient safety.

[0019] In this regard, such as Figures 1-5 As shown, this application proposes a medical in-process quality control method based on closed-loop coupling and self-evolutionary rules. This method dynamically generates, evaluates, and optimizes quality control rules to adapt to constantly changing clinical scenarios, thereby improving the real-time performance, accuracy, and effectiveness of quality control. The method includes the following steps: Step S1: Collect multi-source real-time medical data and perform standardized processing; Step S2: Based on the standardized real-time data, calculate and update the high-dimensional variable pool in real time to generate feature vectors. ; Step S3: Use the AI ​​rule generation module to process the feature vector. The process is performed to calculate the probability of a patient having a specific quality defect. and subset of key variables ; Step S4: Based on this risk probability and subset of key variables Generate candidate quality control rules And assign an initial confidence level C0; Step S5: Utilize the rules in the official rule base and the candidate quality control rule through the hot-swappable rule engine. It performs millisecond-level verification on real-time data and generates alerts; Step S6: Record the doctor's response to the alert, including whether to accept or ignore it; Step S7: Calculate the rule quality increment ΔQ for each rule based on the feedback behavior using the rule evaluator, and upgrade, retain, or eliminate the rule according to the rule quality increment ΔQ and the rule's confidence function c(t); Step S8: Monitor and audit through a visual interface, and at the same time, feed back the feedback data corresponding to the feedback behavior to step S2 or step S3 to start the next learning cycle and form an R-AI-VAR closed loop.

[0020] It should be noted that multi-source real-time medical data refers to a dynamic data stream continuously collected from different information systems and devices during medical activities, reflecting the patient's condition and medical behavior. This data may include the patient's basic information, diagnostic results, treatment plans, physiological parameters, and the execution status of medical orders.

[0021] A high-dimensional variable pool is a dynamically maintained collection of variables that includes various indicators extracted from standardized real-time data to describe patient status and medical processes. These variables are multi-dimensional and multi-granular, enabling a comprehensive portrayal of complex clinical scenarios.

[0022] Feature vector It is a set of numerical values ​​extracted from a high-dimensional variable pool, representing the patient's current state and related medical behaviors at a specific point in time. This vector serves as input to the AI ​​model to assess potential quality defect risks.

[0023] The AI ​​rule generation module is a component that uses artificial intelligence technology to automatically identify potential risks and generate quality control rules based on the input feature vector xt. This module can learn patterns from complex data and transform them into executable rules.

[0024] Risk probability This indicates the probability that a patient has a specific quality defect in their current state. This probability value is calculated by the AI ​​rule generation module and is used to quantify potential medical risks.

[0025] Key variable subset This refers to calculating the probability of risk. At that time, it refers to the set of variables that contribute significantly to risk assessment. These variables are the core factors that cause or indicate the occurrence of specific quality defects.

[0026] The candidate quality control rule Rnew is based on risk probability. and subset of key variables Automatically generated, verifiable quality control rules. These rules, expressed in the form of "IF-THEN," are designed to provide early warnings of potential quality defects.

[0027] The initial confidence level C0 is assigned to the newly generated candidate quality control rules. The initial level of trustworthiness. This value reflects the reliability assessment of the rule at the initial stage of its generation.

[0028] The rule quality increment ΔQ represents the degree to which the quality or effectiveness of a rule improves or declines relative to a baseline after receiving feedback from physicians. This increment is the basis for upgrading, retaining, or eliminating a rule.

[0029] The confidence function c(t) is a time-varying function used to represent the reliability of a rule at different points in time. This function takes into account the rule's initial confidence, decay, and quality increment.

[0030] The R-AI-VAR closed loop refers to the closed-loop learning and evolution mechanism constructed by this method, with rules, artificial intelligence (AI), and variables as its core elements. This closed loop ensures the dynamic generation, evaluation, optimization, and continuous improvement of quality control rules.

[0031] In the medical process quality control method, step S1 involves collecting multi-source real-time medical data and standardizing it. This can be done by deploying data acquisition agents or interfaces to obtain data from various internal hospital information systems (e.g., patient management systems, medical order systems, and examination and testing systems) and external medical equipment (e.g., various monitors and infusion pumps). The collected raw data typically has different formats, encodings, and semantics. To ensure data consistency and usability, this heterogeneous data needs to be standardized. Standardization can include data cleaning, format conversion, missing value imputation, and data type unification. For example, all date and time fields are standardized to ISO 8601 format, and all numerical indicators are standardized to standard units. The processed data is organized into a unified structure to facilitate subsequent analysis and processing.

[0032] After data standardization, step S2 involves calculating and updating a high-dimensional variable pool in real time based on the standardized real-time data, generating a feature vector xt. The system continuously calculates and updates a high-dimensional variable pool based on this real-time data. This pool contains various indicators and features derived from the original data, such as the patient's physiological indicators, treatment progress, medication use, and doctor's actions. These variables can be direct mappings of the original data or composite indicators obtained through aggregation, statistics, or transformation. The high-dimensional variable pool is updated in real time to reflect the latest changes in patient status and medical processes. Subsequently, a feature vector xt describing the patient's status at the current time point is extracted from this high-dimensional variable pool. This feature vector xt serves as the input for the AI ​​model's risk assessment, and its dimensions and content are configured according to the specific quality control scenario.

[0033] After receiving the feature vector xt, step S3: The AI ​​rule generation module processes the feature vector xt to calculate the risk probability that the patient has a specific quality defect. and subset of key variables The AI ​​rule generation module performs in-depth processing on the feature vector xt. This module can contain one or more machine learning models, such as those based on decision trees, support vector machines, or shallow neural networks. These models are trained to identify patterns associated with specific medical quality defects. By processing the feature vector x... t Through analysis, this module can calculate the risk probability of a patient having a specific quality defect. In addition, to improve the interpretability of the results, this module also identifies the probability of risk. Key variables with high contribution, and these variables constitute a subset of key variables. This subset of key variables It can help healthcare workers understand the main causes of risks.

[0034] When the AI ​​rule generation module calculates the risk probability pt and the subset of key variables Then, proceed to step S4: based on this risk probability. and subset of key variables Generate candidate quality control rules An initial confidence level of C0 is assigned. The system will then generate candidate quality control rules based on this information. This rule can be generated using a preset rule template, for example, by using a subset of key variables. The variables in the code are combined into conditional statements, and when these conditions are met, corresponding alerts are triggered. For example, if a subset of critical variables... If the data includes information such as "patient's body temperature remains elevated" and "abnormal infection indicators," a candidate quality control rule for "suspected infection" can be generated. Simultaneously, to evaluate the reliability of this newly generated rule, the system will assign a quality control rule to the candidate based on a certain strategy, such as the magnitude of the risk probability pt. An initial confidence level C0. This initial confidence level C0 reflects the system's preliminary judgment on the validity of the rule.

[0035] Generated candidate quality control rules It will be sent to the hot-swappable rule engine. Step S5: The hot-swappable rule engine utilizes the rules in the formal rule base and the candidate quality control rule. It performs millisecond-level verification of real-time data and generates alerts. This hot-swappable rule engine is a high-efficiency rule execution environment that not only includes rules from the validated and deployed official rule library, but also dynamically loads and executes newly generated candidate quality control rules. This hot-swappable rule engine continuously performs pattern matching and conditional judgment on the incoming real-time medical data. When the real-time data meets the triggering condition of any rule (whether a formal rule or a candidate rule), the rule engine completes the verification in a very short time (e.g., at the millisecond level) and immediately generates the corresponding alert. These alerts are designed to promptly remind medical staff to pay attention to potential risks or non-compliant behaviors.

[0036] Once an alert is generated and pushed to healthcare staff, step S6 records the doctor's feedback behavior, including acceptance or ignore. Doctor feedback is key data for evaluating alert effectiveness and rule quality. Feedback typically falls into two categories: "acceptance," indicating the doctor considers the alert effective and has taken appropriate interventions or conducted further investigations based on its content; and "ignore," indicating the doctor considers the alert inaccurate, irrelevant, or unnecessary and has not taken any substantive action. This feedback information is collected and stored by the system as a basis for subsequent rule evaluation and optimization.

[0037] The system includes a rule evaluator. Step S7: The rule evaluator calculates the rule quality increment ΔQ for each rule based on the feedback behavior. Based on the rule quality increment ΔQ and the rule's confidence function c(t), the rule is upgraded, retained, or eliminated. The rule evaluator collects doctors' feedback behavior data periodically or in real-time. Based on this feedback, the rule evaluator calculates the rule quality increment ΔQ for each rule. This increment reflects the rule's contribution to medical quality in practical application. For example, if a rule is frequently adopted and the patient's condition improves after adoption, its quality increment may be positive. Simultaneously, the rule evaluator also combines the rule's confidence function c(t) for a comprehensive judgment. This confidence function c(t) considers the rule's initial confidence and its performance during operation. Based on the comprehensive evaluation results of the rule quality increment ΔQ and the confidence function c(t), the system will perform corresponding lifecycle management operations on the rules: rules with excellent performance may be "upgraded" to formal rules; rules with stable performance will be "retained" in the current state; while rules with poor performance or that have been ignored for a long time may be "eliminated" to avoid the occurrence of "alarm fatigue".

[0038] To ensure the transparency and traceability of the entire quality control process, step S8 involves monitoring and auditing through a visual interface. Simultaneously, the feedback data corresponding to the feedback behavior is fed back to step S2 or S3, initiating the next learning cycle and forming an R-AI-VAR closed loop. The system provides a visual interface for real-time monitoring and historical auditing of the quality control method's operational status. This interface displays information such as alarm generation, rule operation status, and physician feedback statistics. Simultaneously, physician feedback behaviors and their corresponding patient variable data—i.e., feedback data—are fed back to earlier steps in the system. Specifically, this feedback data can be used to optimize the construction of the high-dimensional variable pool (step S2) or improve the model parameters of the AI ​​rule generation module (step S3). Through this data feedback mechanism, the system can initiate the next learning cycle, continuously optimizing its quality control capabilities and forming a continuously evolving R-AI-VAR closed loop. This closed loop ensures that quality control rules can be dynamically adjusted and self-evolved based on actual clinical feedback.

[0039] This embodiment collects multi-source medical data in real time and performs standardized processing. Combined with an AI rule generation module, it dynamically identifies risks and generates candidate quality control rules, which are then validated at the millisecond level using a hot-swappable rule engine. Doctors' feedback is recorded and used for rule evaluation, enabling adaptive upgrades, retention, or elimination of rules. This closed-loop learning mechanism effectively solves problems in traditional solutions such as lagging rule updates, insufficient intelligence, limited variable dimensions, and alarm fatigue, significantly improving the real-time performance, accuracy, and effectiveness of in-process quality control in healthcare.

[0040] In some embodiments, in step S1, the data sources of multi-source real-time medical data include hospital information system (HIS), electronic medical record (EMR), laboratory system (LIS), vital signs monitor, and hand anesthesia system; the standardization process is to uniformly convert the heterogeneous data streams into HL7 or FHIR format and continuously write them to the med_raw topic of the Kafka message queue with a time window of 5 seconds.

[0041] Specifically, the data sources for multi-source real-time medical data encompass the Hospital Information System (HIS), Electronic Medical Record (EMR), Laboratory Information System (LIS), vital signs monitors, and anesthesia systems. The HIS is the core of hospital operations, covering management data such as basic patient information, medical orders, and costs. The EMR records detailed clinical diagnosis and treatment processes, including diagnosis, treatment plans, and progress notes. The LIS manages various laboratory test results, providing objective physiological data. Vital signs monitors continuously collect key physiological parameters such as heart rate, blood pressure, and blood oxygen saturation, crucial for real-time monitoring of surgical or critically ill patients. The anesthesia system specifically records data during surgery and anesthesia, such as medication administration, changes in vital signs, and surgical events. These data sources collectively constitute a comprehensive, multi-dimensional view of real-time patient information, providing a rich data foundation for medical quality control.

[0042] Given that the aforementioned multi-source data systems typically employ different data structures, encoding standards, and transmission protocols, direct integration and analysis would face significant technical obstacles. Therefore, this application employs a standardized process to convert these heterogeneous data streams into the industry-standard HL7 (Health Level Seven) or FHIR (Fast Healthcare Interoperability Resources) formats. HL7 is a widely used data exchange standard in the medical field, while FHIR is its next-generation standard, better suited to modern internet technology architectures. Through this conversion, data from different sources is given a unified semantics and structure, greatly improving data interoperability and resolvability, and ensuring data consistency in subsequent processing stages.

[0043] To meet the stringent real-time requirements of medical quality control, the standardized data is not processed in batches but rather in a streaming manner. Specifically, the data is organized into 5-second time windows, meaning that data generated within each 5-second window is processed as a batch. This data is then continuously written to the `med_raw` topic in a Kafka message queue. Kafka, as a high-throughput, low-latency distributed stream processing platform, reliably receives and stores massive amounts of real-time data streams and supports parallel reading by multiple consumers, ensuring efficient and stable data transmission and providing a robust data pipeline for subsequent real-time computation and analysis.

[0044] In some embodiments, the variables in the high-dimensional variable pool are further refined. These variables include patient journey stage variables, time-series physiological variables, physician behavioral profile variables, and environmental context variables. The patient journey stage variables are used to identify the current stage of the patient throughout the entire medical process. By dividing the patient's treatment process into discrete, clinically significant stages, targeted contextual information can be provided for quality control at different stages. For example, in addition to eight stage labels such as "0-2 hours after admission," "24 hours before surgery," "0-72 hours after surgery," and "day of discharge," more macroscopic stages such as "diagnosis period," "treatment period," and "rehabilitation period," or stages specific to a particular department or scenario such as "emergency observation period" and "ICU treatment period," can be included. Accurate identification of these stage labels is crucial for triggering quality control rules for specific stages. The time-series physiological variables reflect the dynamic trends of the patient's vital signs over time. By continuously monitoring physiological parameters (such as heart rate (HR), blood pressure (BP), and blood oxygen saturation (SpO2) and extracting their statistical characteristics, such as 1-minute mean, slope of change, and coefficient of variation, subtle changes and abnormal trends in the patient's physiological state can be captured, rather than just instantaneous values. In addition to the above parameters, similar time-series characteristics of other key physiological indicators such as respiratory rate, body temperature, and blood glucose can also be included. These characteristics are important for early identification of patient deterioration or poor treatment outcomes. The physician behavior profile variables aim to quantify and assess the degree to which physicians' behavioral patterns in specific clinical decisions or procedures conform to standard guidelines. By analyzing the deviation (e.g., expressed by Z-scores) of key behaviors such as "antibiotic selection-discontinuation timing" from clinical guideline recommendations when physicians perform similar surgeries over a period of time (e.g., the past 30 days), potential individualized operational risks or experience differences can be identified. Besides antibiotic use, behavioral deviations in other key diagnostic and treatment aspects such as surgical indications, anesthesia protocols, and postoperative analgesia management can also be included, thus providing a basis for personalized quality control interventions. The environmental context variables describe the patient's medical environment or external conditions, which may affect the quality of care or patient risk. For example, the status of the operating room laminar flow system can reflect the cleanliness of the surgical environment, directly affecting the risk of infection; whether the current time is a holiday or night shift may be related to the staffing, experience level, or fatigue level of medical personnel, thus indirectly influencing medical decisions. Other environmental context variables may include ward bed availability, equipment availability, and epidemiological characteristics of a specific season, which help to more comprehensively assess the risk. Furthermore, the feature vector x... t The system updates once per second, meaning it recalculates and generates feature vectors x containing information about all high-dimensional variables at a high frequency. tThis high-frequency update ensures that the system can capture the latest changes in patient status and environment in real time, thereby providing a basis for subsequent risk probability p. t The calculation and quality control rule generation provides the latest and most accurate input.

[0045] In some embodiments, the AI ​​rule generation module includes a deep temporal subnet, an interpretable subnet, and a rule template engine. Specifically, step S3 includes: First, the deep temporal subnet uses a 4-layer Transformer encoder as the backbone network, and inputs the feature vector x. t Output the risk probability p t Secondly, the interpretable subnet applies Integrated Gradients (IPG) technology to the risk probability p. t The backpropagation calculation is performed to obtain the contribution score of each input variable, and the top-K variables with the highest contribution scores are selected to form the key variable subset M. t Finally, the rule template engine calculates the risk probability p. t And make a judgment with the subset of key variables Mt, when the risk probability p t When the threshold is exceeded, the key variable subset M is generated. t Corresponding candidate quality control rules .

[0046] The AI ​​rule generation module is a core component of the entire medical in-process quality control method. Its main function is to transform complex, high-dimensional real-time medical data into understandable and actionable quality control rules. By integrating advanced machine learning techniques with rule logic, this module aims to automatically identify potential quality defect risks and generate corresponding intervention recommendations. Its design goal is to improve the efficiency, accuracy, and interpretability of rule generation, thereby supporting clinical decision-making and improving the quality of medical care.

[0047] The deep temporal subnet described is a deep learning model specifically designed for processing time series data. In this embodiment, it employs a 4-layer Transformer encoder as the backbone network. The Transformer encoder is a neural network architecture based on a self-attention mechanism, particularly adept at capturing long-range dependencies and complex temporal patterns in sequential data. By using the feature vector xt as input, this subnet can learn and extract key information from the patient's real-time state and historical data, thereby outputting the risk probability p of the patient having a specific quality defect. t This network can effectively handle the nonlinearity, high dimensionality, and temporal correlations commonly found in medical data, providing an accurate predictive basis for subsequent risk assessment.

[0048] The interpretable subnet aims to address the "black box" problem of deep learning models and improve the transparency of model decisions. This subnet applies Integrated Gradients (IGR) technology, an attribution method that quantifies the impact of each input feature on the model output (i.e., the risk probability) by calculating the integral of the gradient along the path from the baseline input to the actual input. The system can identify which variables in the feature vector xt contribute to the risk probability. The predictions of these variables have the greatest impact. Subsequently, the top-K variables with the highest contribution were selected; these variables collectively constitute the subset of key variables. The introduction of this subnet means that risk prediction results are no longer isolated numerical values, but can be linked to specific clinical indicators, thereby enhancing doctors' trust in risk alerts and their willingness to adopt them.

[0049] The rule template engine is responsible for transforming the outputs of the deep temporal subnet and the interpretable subnet into structured candidate quality control rules Rnew. The engine first determines the risk probability. Does it exceed a preset threshold? When the risk reaches a warning level, the engine will utilize a subset of key variables. This is used to populate predefined rule templates. These templates typically take the form of "IF-THEN," such as "IF [condition]THEN [action]." In this way, the engine can automatically generate candidate quality control rules with clear trigger conditions and intervention recommendations based on the identified specific risk factors. The engine ensures that the generated rules conform to clinical logic and format requirements, laying the foundation for subsequent rule validation and deployment.

[0050] In some implementations, in step S8, a visual interface displays the lineage graph of the rules, the confidence decay curve, and the real-time alarm queue to meet the traceability requirements of medical supervision. Simultaneously, the feedback data includes doctors' feedback behaviors and corresponding patient variable data, used to retrain and fine-tune the model parameters of the deep temporal subnet.

[0051] Specifically, the rule lineage diagram graphically displays the complete lifecycle of each rule, including its initial generation time, which AI model version generated it, which training data it was based on, what modifications or upgrades it underwent, and its evolution path from candidate rule Rnew to official rule. For example, when a rule is modified or merged, the lineage diagram clearly shows the relationship between its parent and child rules, thus providing a traceable audit path. The confidence decay curve visually depicts the trend of the confidence c(t) of each rule over time t. It not only shows the initial confidence C0 of the rule but also dynamically updates to reflect the impact of the rule quality increment ΔQ on the confidence after a doctor adopts or ignores an alert, as well as the natural decay trend of the confidence over time. Through this curve, quality control personnel can clearly assess the current effectiveness and stability of the rule, assisting in decisions on whether to retain, upgrade, or eliminate the rule. The real-time alert queue displays all alerts currently generated by the system in real time, including the alert's priority, trigger time, associated patient information, the specific rule that triggered the alert, and the doctor's feedback status for the alert. This queue supports filtering and sorting across multiple dimensions, enabling quality control personnel to quickly locate and handle critical alerts, ensuring timely medical intervention. Through the aforementioned visualization elements, this method ensures a high degree of transparency and traceability throughout the entire chain, from raw data to alert generation, rule evolution, and physician feedback. This is crucial for the healthcare field because it allows regulatory agencies, auditors, or clinicians to comprehensively review the system's decision-making process, verifying its compliance, security, and effectiveness, thereby enhancing the system's credibility.

[0052] Furthermore, the feedback data is key information collected by the system from doctors' responses to alerts (acceptance or ignoring). Specifically, when a doctor responds to an alert, the system not only records the doctor's acceptance or ignoring behavior but also captures the patient's real-time variable data at the time the alert was triggered, i.e., the feature vector xt at that time. This data is integrated into a structured feedback sample. The collected feedback data is considered as new supervisory signals, used to continuously optimize the model parameters of the deep temporal subnet in the AI ​​rule generation module. For example, when a doctor accepts an alert, the feedback sample can be used to strengthen the deep temporal subnet's ability to identify similar risk patterns; when a doctor ignores an alert, it can be used to correct the model's risk assessment of certain feature combinations. This continuous retraining and fine-tuning mechanism enables the deep temporal subnet to continuously learn from real clinical practice, adapt to new clinical patterns and doctor preferences, thereby improving the accuracy and robustness of its predicted risk probability pt, and ultimately enhancing the quality and effectiveness of the rules generated by the entire system.

[0053] In some embodiments, when generating candidate quality control rules Rnew, the initial confidence level C0 is calculated using the formula C0 = ×Information gain; The candidate quality control rule Rnew adopts the "IF-THEN" form. When the subset of key variables Mt contains "no anticoagulant medication administered 6 hours post-operation", the generated candidate quality control rule is "IF post-operation stage > 6h AND anticoagulant status = 'not administered' THEN trigger VTE prevention alarm".

[0054] Specifically, the initial confidence level C0 is used to quantify the initial reliability or importance of the newly generated candidate quality control rule Rnew. Its calculation method incorporates risk probability. And information gain. Risk probability. This reflects the likelihood of a patient having specific quality defects, determined by the AI ​​rule generation module based on feature vectors. The calculation yields the information gain, which measures the contribution of a subset of key variables, Mt, to predicting the probability of that risk. The degree of contribution or discriminative power of the feature. By multiplying the two, the degree of risk targeted by the rule and the predictive value of the key variables on which it is based can be comprehensively considered, thus giving the new rule a more convincing initial assessment value. Information gain can be calculated in various ways, such as by assessing the importance of features in decision tree or random forest models, or by calculating a subset of key variables. Risk Probability Mutual information between variables. Mutual information quantifies the degree to which the presence of one variable reduces the uncertainty of another variable, thus reflecting its information content. Specifically, it can be used to calculate subsets of key variables. Risk Probability The conditional entropy or relative entropy between them is used to obtain the numerical value of information gain.

[0055] Meanwhile, the "IF-THEN" format is a logical expression widely used in expert systems and rule engines to clearly define the triggering conditions and execution actions of rules. The "IF" part describes the conditions under which the rule takes effect, typically involving a specific combination of key variables such as the patient's clinical state, physiological indicators, and treatment process; the "THEN" part specifies the action to be taken when the conditions are met, such as triggering an alarm, recommending an intervention, or recording a specific event. This structured expression makes rules easy to understand, maintain, and automate, ensuring the transparency and traceability of quality control logic. The "IF" condition can contain multiple logical operators (such as AND, OR, NOT) to combine different variable judgments, for example, "IF(variable A>threshold 1) AND (variable B=state X)". The "THEN" action can be a simple alarm trigger command or a more complex command, such as invoking a specific clinical decision support module.

[0056] Furthermore, this application provides a specific rule generation example, demonstrating how to transform high-risk factors in a subset of key variables Mt into executable "IF-THEN" rules. When the AI ​​rule generation module identifies the key risk factor "no anticoagulant administered within 6 hours post-surgery," the system automatically constructs the corresponding quality control rule based on a preset rule template or semantic parsing mechanism. This rule explicitly states that if the patient is in the post-operative stage and more than 6 hours have passed, and the anticoagulant status is "not administered," a deep vein thrombosis (VTE) prevention alarm should be triggered. The rule template engine can preset multiple rule templates, such as those for risk factors of different diseases and treatment stages. After the subset of key variables Mt is identified, the engine matches the most suitable template and fills the placeholders in the template with the specific variable values ​​in Mt, thereby generating a specific "IF-THEN" rule. For example, there could be a general template such as "IF [stage] > [time threshold] AND [drug status] = 'not administered' THEN trigger [alarm type] alarm."

[0057] In some implementations, the hot-swappable rule engine includes an inference kernel and a rule cache; the inference kernel employs an improved Rete-NN network, capable of completing pattern matching and inference for over 10,000 rules within 100ms; the rule cache is used to store the candidate quality control rules. The candidate quality control rules The rule verification phase begins only after the rule has been triggered at least three times in a real clinical setting and the corresponding alert has been adopted by the doctor.

[0058] This hot-swappable rule engine aims to provide a highly flexible and scalable rule processing framework. Its "hot-swappable" nature means that rules can be dynamically added, deleted, or modified at runtime without interrupting service or restarting the entire system. This is crucial for healthcare quality control systems, as clinical guidelines and best practices are constantly evolving, requiring rule bases to respond quickly to these changes. As the core component of the hot-swappable rule engine, the inference kernel receives real-time data streams and performs pattern matching and logical reasoning based on predefined rule sets to identify potential quality defects or risks. Its performance directly determines the timeliness and accuracy of the entire system's response. The improved Rete-NN network is an efficient pattern matching algorithm widely used in expert systems and rule engines. It accelerates the rule matching process by building a discriminative network to avoid redundant computation. The "improved Rete-NN network" used in this application is further optimized on this basis, potentially incorporating certain characteristics of neural networks, such as learning to optimize matching paths, weight allocation, or introducing parallel computing mechanisms, to handle more complex and larger-scale rule sets. This improvement enables the inference kernel to handle massive amounts of rules while maintaining extremely high processing speed, capable of completing pattern matching and inference for over 10,000 rules within 100ms. This performance metric highlights the inference kernel's exceptional efficiency when processing large-scale rule sets. In medical quality control scenarios, millisecond-level response times are crucial to ensuring timely alerts and preventing missed intervention windows. For example, in real-time monitoring of cardiovascular events or adverse drug reactions, any delay can lead to serious consequences. The rule cache is a dedicated area for temporarily storing and managing rules. It provides a buffer for newly generated candidate quality control rules. It provides an isolated environment for observation and validation before formal deployment. Candidate quality control rules It is generated by the AI ​​rule generation module based on real-time data and risk probability. Dynamically generated potential effective rules. These rules may not have undergone sufficient clinical validation in the initial stage, therefore requiring a dedicated area for management. The candidate quality control rules... A rule must be triggered at least three times in a real clinical scenario, and the corresponding alerts must be adopted by doctors before it enters the rule validation phase. This mechanism is crucial for ensuring the reliability of new rules. It sets strict conditions, requiring candidate rules not only to be triggered multiple times in actual clinical data, but also that the alerts they trigger must be actually adopted by doctors, demonstrating that the rule has clinical value and accuracy. Only when these conditions are met can candidate rules enter a higher-level validation phase and may eventually be upgraded to formal rules. This prevents insufficiently validated rules from directly influencing clinical decisions and ensures the robustness of the system.

[0059] In some implementations, in step S7, the formula for calculating the rule quality increment ΔQ is ΔQ = (post-adoption defect correction rate − baseline correction rate) × weight; when the ΔQ of a candidate quality control rule > 0.05, it is automatically upgraded to a formal rule and added to the formal rule base; the formula for calculating the confidence function c(t) is... Where C0 is the initial confidence level, λ is the decay coefficient, and t is the time; when the confidence level of the rule continues to be lower than the lower threshold or ΔQ is negative, it is automatically migrated to the elimination zone and stopped from use.

[0060] Specifically, the formula for calculating the rule quality increment ΔQ is ΔQ = (Post-adoption defect correction rate − Baseline correction rate) × weight. Here, "Post-adoption defect correction rate" refers to the proportion of a specific quality defect (e.g., failure to administer anticoagulants in a timely manner) that is corrected within a subsequent period after a physician adopts an alert triggered by a rule. This requires the system to track patient status or physician behavior after alert adoption and to statistically analyze the actual correction of the defect. "Baseline correction rate" refers to the natural or historical correction rate of the specific quality defect without the intervention of the rule alert; this can be obtained by statistically analyzing historical data or control group data. "Weight" is a configurable parameter used to adjust the degree of influence of ΔQ on rule quality assessment; for example, different weights can be assigned based on the severity or clinical importance of the defect. Through this formula, the system can quantify the actual clinical benefit of the rule.

[0061] When the ΔQ value of a candidate quality control rule exceeds a preset threshold of 0.05, the system will automatically perform an upgrade operation, moving it from the candidate rule base to the formal rule base, making it a formal rule and adding it to the formal rule base. This threshold of 0.05 can be adjusted according to clinical practice and system performance requirements to ensure that only validated rules with significant clinical benefits can enter the formal rule base, thereby guaranteeing the quality of the rule base.

[0062] The confidence function c(t) is calculated using the following formula: Where C0 is the initial confidence level assigned when the rule is first generated, which can be determined based on the output of the AI ​​rule generation module (such as risk probability pt) and information gain. λ is the decay coefficient, reflecting the timeliness of the rule or the speed of clinical knowledge updates, and e−λt represents the portion of the confidence level that naturally decays over time. t is the time since the rule took effect. This indicates the confidence boosting effect of the quality increment obtained from actual clinical feedback on the rule, and this boosting effect accumulates over time, but is also subject to decay effects. The system periodically updates the c(t) value of each rule according to this formula, thereby dynamically evaluating and updating the reliability and effectiveness of each rule.

[0063] When a rule's confidence level c(t) consistently falls below a preset threshold (e.g., 0.2) or ΔQ is negative, the system will automatically remove the rule from the official rule base and mark it as "obsolete," ceasing its use in the hot-swappable rule engine. A consistently low confidence level indicates insufficient reliability of the rule, while a negative ΔQ means that adoption of the rule has actually led to a decrease in defect correction rates or failed to achieve the expected results, typically indicating a problem with the rule or that it is outdated. This mechanism is used to identify and remove rules that are no longer effective or may even have negative impacts, preventing them from interfering with system performance or misleading clinical decisions.

[0064] In some implementations, in step S5, the alarm push adopts an intelligent push strategy, which calculates the priority of each alarm based on the comprehensive priority = c(t) × clinical impact × doctor's historical adoption rate, and only pushes the top-N alarms with the highest priority, where N is a preset positive integer and N≥1.

[0065] This intelligent push strategy aims to optimize the delivery of alerts, selecting the most critical and attention-grabbing alerts from a massive volume of generated alerts for immediate distribution. It goes beyond simply generating alerts; it focuses on effective distribution and the doctor's receiving experience to ensure timely and accurate guidance for intervention. The calculation of comprehensive priority incorporates several key factors: the confidence function c(t) originates from the rule evaluator's continuous assessment of rule quality, reflecting the reliability and effectiveness of the current rule; a higher confidence level indicates that the alert triggered by the rule is more trustworthy. The clinical impact parameter quantifies the degree of harm that the potential medical risks or defects indicated by the alert may cause to the patient's health. For example, life-threatening alerts have high clinical impact, while minor, observable risks have lower clinical impact. Clinical impact can be determined through a pre-set medical expert knowledge base, clinical guidelines, or real-time assessment of the patient's condition based on a machine learning model. The physician historical adoption rate parameter records the adoption behavior of a specific physician or physician group towards similar alerts in the past. If a physician has a high historical adoption rate for a certain type of alert, it indicates that the alert is highly relevant and useful to that physician. This data can be continuously learned and updated from the physician feedback behavior recorded in step S6. By multiplying these three dimensions (rule reliability, event severity, and physician acceptance), the comprehensive importance of each alert can be comprehensively and dynamically assessed, thus providing a quantitative basis for subsequent screening. After calculating the overall priority of all alerts, the system sorts them in descending order of priority and only selects the N highest priority alerts for push notifications. N is a configurable parameter that can be dynamically adjusted based on clinical workload, physician roles, or specific scenario requirements.

[0066] Through the above embodiments, this application further introduces an intelligent push strategy based on alarm generation. This strategy dynamically calculates the comprehensive priority of each alarm by comprehensively considering the confidence function c(t) of the rules, the clinical impact of the alarm, and the doctor's historical adoption rate. Therefore, the system can accurately identify and push only the Top-N highest priority alarms. This mechanism effectively solves the problems of alarm overload and doctor alarm fatigue that may occur with traditional alarm systems, ensuring that doctors can focus on dealing with the most critical and urgent medical quality defects. By optimizing the quality and relevance of alarms, this application significantly improves the doctor's alarm adoption rate and response speed, thereby improving the efficiency and accuracy of in-process quality control in healthcare, ultimately ensuring patient safety and treatment outcomes.

[0067] like Figure 6 As shown, this application also proposes a medical in-process quality control system based on closed-loop coupling and self-evolutionary rules. This system is used to execute the aforementioned medical in-process quality control methods. The system includes a multi-source real-time data acquisition module, a high-dimensional variable pool module, an AI rule generation module, a hot-swappable rule engine, and a closed-loop feedback and visualization module. These modules work collaboratively through a streaming data bus and a microservice channel, where the streaming data bus is Kafka and the microservice channel is REST or gRPC.

[0068] Specifically, the multi-source real-time data acquisition module is responsible for acquiring medical data in real time from various heterogeneous data sources, including the Hospital Information System (HIS), Electronic Medical Records (EMR), Laboratory Information System (LIS), vital signs monitors, and anesthesia systems. Its role is to aggregate raw data scattered across different systems onto a unified platform and perform preliminary standardization processing, laying the foundation for subsequent data processing. This module can establish connections with various data sources through adapters or connectors, continuously monitor data changes, and convert the acquired data into a unified format, such as HL7 or FHIR, to ensure data consistency and resolvability.

[0069] The high-dimensional variable pool module, based on standardized real-time data, calculates and maintains a high-dimensional variable set in real time, including patient journey stage variables, time-series physiological variables, physician behavioral profile variables, and environmental context variables. Its role is to transform raw, discrete data into feature representations with higher semantic and analytical value, providing rich input for AI rule generation. This module typically employs streaming processing techniques to aggregate, transform, and feature-engineer the incoming standardized data, such as calculating the mean, slope, and coefficient of variation of physiological indicators, and updating the patient's current journey stage according to preset logic.

[0070] The AI ​​rule generation module utilizes artificial intelligence technology to analyze the feature vectors output by the high-dimensional variable pool module to identify specific quality defects that patients may have and automatically generate candidate quality control rules. Its role is to learn and generalize clinical experience and expert knowledge through AI models, thereby discovering potential quality risk points not covered by existing rules. This module typically includes a deep learning model for risk prediction, interpretable AI technology for identifying key influencing factors, and a rule template engine to transform these findings into structured "IF-THEN" rules.

[0071] The hot-swappable rule engine is a high-performance rule processing system capable of performing millisecond-level verification on real-time data using rules from the official rule base and candidate quality control rules generated by an AI rule generation module. Its "hot-swappable" feature means it can dynamically load, update, or remove rules without interrupting service. Its function is to apply pre-defined or newly discovered quality control logic to clinical data streams in real time, promptly detecting anomalies and triggering alerts. This engine typically employs optimized pattern matching algorithms to handle the real-time inference needs of large-scale rule sets and features a rule caching mechanism to manage the lifecycle of candidate rules.

[0072] The closed-loop feedback and visualization module collects doctors' feedback on alerts (adoption or ignoring) and provides an intuitive interface for system monitoring and auditing. Its role is to integrate human expert judgment into the self-evolution of rules, forming a closed loop of continuous learning and improvement, while ensuring transparency and traceability throughout the quality control process. This module not only records feedback data but also visualizes the rule's operational status, confidence level trends, and real-time alert queues, supporting medical supervision and quality management.

[0073] As the core infrastructure for data transmission between various modules within the system, Kafka provides a high-throughput, low-latency, and persistent distributed message queue. Its role is to decouple data and enable asynchronous communication between modules, ensuring that massive amounts of real-time medical data can flow stably and efficiently between different processing stages, thereby supporting the real-time requirements of the entire quality control methodology. Through Kafka, data producers (such as the data acquisition module) and data consumers (such as the variable pool module and rule engine) can operate and scale independently, improving the overall resilience and fault tolerance of the system.

[0074] Besides streaming data buses for large-scale data transmission, microservice channels (such as REST or gRPC) are used to implement non-streaming, request-response communication between modules, such as control commands, configuration information, and status queries. Their role is to provide a flexible and efficient inter-service call mechanism, supporting independent deployment and management of modules, enabling the system to be built in a microservice architecture, thereby enhancing the system's modularity, maintainability, and scalability. REST is typically suitable for lightweight, stateless API interactions, while gRPC, with its high performance and multi-language support, is suitable for scenarios with higher requirements for communication efficiency.

[0075] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A medical in-process quality control method based on closed-loop coupling and self-evolution rules, characterized in that, Includes the following steps: Step S1: Collect multi-source real-time medical data and perform standardized processing; Step S2: Based on the standardized real-time data, calculate and update the high-dimensional variable pool in real time to generate feature vectors. ; Step S3: Process the feature vector using the AI ​​rule generation module. The process is performed to calculate the probability of a patient having a specific quality defect. and subset of key variables ; Step S4: Based on the risk probability and subset of key variables Generate candidate quality control rules And assign an initial confidence level C0; Step S5: Utilize the rules in the formal rule base and the candidate quality control rules through the hot-swappable rule engine. It performs millisecond-level verification on real-time data and generates alerts; Step S6: Record the doctor's response to the alarm, including acceptance or ignoring; Step S7: Calculate the rule quality increment for each rule based on the feedback behavior using the rule evaluator. According to the rules, the quality increment The confidence function c(t) of the rule is used to upgrade, retain, or eliminate the rule; Step S8: Monitor and audit through a visual interface, and simultaneously feed back the feedback data corresponding to the feedback behavior to step S2 or step S3 to start the next learning cycle and form an R-AI-VAR closed loop.

2. The medical in-process quality control method according to claim 1, characterized in that, In step S1, the data sources of multi-source real-time medical data include Hospital Information System (HIS), Electronic Medical Record (EMR), Laboratory Information System (LIS), vital signs monitors, and hand anesthesia systems. The standardization process involves converting the heterogeneous data streams into HL7 or FHIR format and continuously writing them to the med_raw topic of the Kafka message queue with a 5-second time window.

3. The medical in-process quality control method according to claim 1, characterized in that, The variables in the high-dimensional variable pool include patient journey stage variables, time-series physiological variables, physician behavior profile variables, and environmental context variables. The patient journey stage variables include stage labels for admission, preoperative, postoperative, and discharge. The time-series physiological variables include the 1-minute mean, slope of change, and coefficient of variation of heart rate (HR), blood pressure (BP), and blood oxygen saturation (SpO2). The physician behavior profile variables include the Z-score of the deviation between the physician's antibiotic selection and discontinuation timing and the clinical guideline recommendations when the physician performed similar surgeries within 30 days; The environmental context variables include the status of the operating room laminar flow system and whether the current time is a holiday or night shift. The feature vector Updated once per second.

4. The medical in-process quality control method according to claim 1, characterized in that, The AI ​​rule generation module includes a deep temporal subnet, an interpretable subnet, and a rule template engine; Step S3 includes: S31: The deep temporal subnetwork uses a 4-layer Transformer encoder as the backbone network, and the input feature vector is... Output the risk probability ; S32: The interpretable subnet applies Integrated Gradients technology to the risk probability. The backpropagation calculation is performed to obtain the contribution score of each input variable, and the top-K variables with the highest contribution scores are selected to form the subset of key variables. ; S33: The rule template engine determines the risk probability. and subset of key variables Make a judgment when the risk probability is... When the preset threshold is exceeded, the subset of key variables is generated. Corresponding candidate quality control rules .

5. The medical in-process quality control method according to claim 4, characterized in that, In step S8, the visualization interface displays the lineage diagram of the rules, the confidence decay curve, and the real-time alarm queue, meeting the traceability requirements of medical supervision; the feedback data includes the doctor's feedback behavior and the corresponding patient variable data, which are used to retrain and fine-tune the model parameters of the deep time series subnet.

6. The medical in-process quality control method according to claim 1, characterized in that, In step S4, the initial confidence level C0 is calculated using the formula C0 = ×Information gain; the candidate quality control rules Use the IF-THEN format.

7. The medical in-process quality control method according to claim 1, characterized in that, The hot-swappable rule engine includes an inference kernel and a rule cache. The inference kernel uses an improved Rete-NN network, capable of completing pattern matching and inference for over 10,000 rules within 100ms. The rule cache stores the candidate quality control rules. The candidate quality control rules The rule verification phase begins only after the rule has been triggered at least three times in a real clinical setting and the corresponding alert has been adopted by the doctor.

8. The medical in-process quality control method according to claim 1, characterized in that, In step S7, the formula for calculating the rule quality increment ΔQ is ΔQ = (post-adoption defect correction rate − baseline correction rate) × weight; when the ΔQ of a candidate quality control rule is greater than 0.05, it is automatically upgraded to a formal rule and added to the formal rule library; The confidence function c(t) is calculated using the following formula: Where C0 is the initial confidence level, λ is the decay coefficient, and t is the time; when the confidence level of the rule continues to be lower than the lower threshold or ΔQ is negative, it is automatically migrated to the elimination zone and stopped from use.

9. The medical in-process quality control method according to claim 1, characterized in that, In step S5, the alarm push adopts an intelligent push strategy. The priority of each alarm is calculated based on the comprehensive priority = c(t) × clinical impact × doctor's historical adoption rate. Only the top-N highest priority alarms are pushed, where N is a preset positive integer and N≥1.

10. A medical in-process quality control system based on closed-loop coupling and self-evolution rules, used to execute the medical in-process quality control method as described in any one of claims 1-9, characterized in that, include: Multi-source real-time data acquisition module, high-dimensional variable pool module, AI rule generation module, hot-swappable rule engine, and closed-loop feedback and visualization module; The multi-source real-time data acquisition module, high-dimensional variable pool module, AI rule generation module, hot-swappable rule engine, and closed-loop feedback and visualization module work together through a streaming data bus and a microservice channel. The streaming data bus is Kafka, and the microservice channel is REST or gRPC.

Images