Medical examination data anomaly detection system and method based on multi-algorithm fusion and dynamic early warning

Abstract

The invention discloses a medical examination data anomaly detection system and method based on multi-algorithm fusion and dynamic early warning, and relates to the technical field of medical big data processing. The method comprises the following steps: acquiring patient inspection data through a data interface layer, and converting unstructured data into a standardized entity object by utilizing an ORM mapping technology; constructing a multi-algorithm service pool, and integrating a plurality of detection service classes including threshold statistics, time sequence prediction (ARIMA / Prophet) and machine learning (SVM / random forest); dynamically loading algorithm parameters through an early warning rule configuration service, and calling a selected algorithm service in parallel by using a strategy mode to obtain a preliminary anomaly judgment result; a weighted voting mechanism is adopted to fuse multi-source results, and an early warning threshold value is dynamically calculated in combination with historical data statistical characteristics based on a sliding window; and finally, the abnormal level and attribution analysis are displayed through a visual module. According to the method, the problem of a single model detection blind area is solved through a software engineering algorithm fusion architecture, and the sensitivity and the specificity of data anomaly detection are remarkably improved by utilizing dynamic threshold calculation realized by code logic.

Description

[0001] This invention relates to the field of medical information processing technology, specifically to a medical laboratory data anomaly detection system and method based on multi-algorithm fusion and dynamic early warning, and in particular to a system that integrates multiple statistical and machine learning algorithms using software engineering architecture for real-time data analysis. Background Technology

[0002] Medical laboratory data is a core basis for clinical diagnosis. Traditional laboratory testing systems (LIS) primarily rely on the "fixed reference range method" for anomaly detection, which involves determining whether the test result falls between a preset minimum and maximum value. However, in practical software development and clinical applications, this hard-coded or statically configured approach has significant drawbacks:

[0003] (1) Lack of personalization: Different patients have different basic physiological indicators, and fixed thresholds cannot reflect individual differences (for example, although a patient's indicators are within the normal range, they have changed drastically relative to their historical data).

[0004] (2) Single algorithm: Existing systems usually only use simple logical judgments (if-else) and cannot integrate advanced algorithms such as ARIMA and SVM to process nonlinear or high-dimensional data.

[0005] (3) Poor scalability: When new detection rules need to be introduced, the core code often needs to be modified, lacking a flexible rule configuration and algorithm plug-and-play mechanism.

[0006] Therefore, there is an urgent need for an intelligent software system that supports dynamic configuration of multiple algorithms and can perform trend analysis by combining historical data. Summary of the Invention

[0007] The purpose of this invention is to provide a medical laboratory data anomaly detection system and method based on multi-algorithm fusion and dynamic early warning. The system achieves configurability and fusion of algorithms through software architecture design and dynamically calculates early warning thresholds using code logic.

[0008] Technical solution of the present invention

[0009] A method for detecting anomalies in medical laboratory data based on multi-algorithm fusion and dynamic early warning, the core logical process of which includes:

[0010] (1) Data materialization: The system receives test data in HL7 or JSON format and converts it into Java objects (such as LabResult) through ORM (Object Relational Mapping) to facilitate subsequent object-oriented logic processing.

[0011] (2) Dynamic strategy distribution: The system maintains an algorithm service pool. During detection, the specific algorithm implementation class is dynamically selected based on the WarningRule entities stored in the database. For example, if the rule is configured as algorithm="arima", the system calls ArimaAlgorithmService through reflection or dependency injection.

[0012] (3) Implementation of multiple algorithm logic:

[0013] 1) Dynamic Threshold Algorithm: In ThresholdAlgorithmService, the system queries the patient's historical data list for that item in real time through code logic, iterates through the list to calculate the mean and variance, and then derives the dynamic standard deviation (StdDev). The system determines whether |CurrentValue - Mean| > Param * StdDev is true, using this as the basis for anomaly detection, rather than consulting a static dictionary table.

[0014] 2) Machine learning algorithm: Integrate SVM or random forest services, load pre-trained model files, transform the current test results and context features into vector input models, and obtain classification results.

[0015] (4) Result fusion and persistence: The system aggregates the return results of each algorithm service through the controller layer. If an alert is triggered, the system instantiates a WarningResult object, automatically populates the alert level (high / medium / low), alert time and reason, and writes it to the relational database through the Repository layer.

[0016] Beneficial effects of the present invention

[0017] (1) High flexibility: By adopting the strategy pattern and configurable rules, users can switch the detection algorithm used in the front-end interface without modifying the code (such as switching from threshold method to ARIMA prediction). (2) High accuracy: The dynamic statistical logic implemented in the code can capture hidden anomalies that are "within the normal range but deviate from the personal baseline". (3) System decoupling: The algorithm logic is encapsulated in an independent Service class, which does not interfere with each other and facilitates the subsequent expansion of new AI models. Attached Figure Description

[0018] Figure 1 This is a diagram of the overall software architecture of the system of the present invention. Figure 2 This is a system interface diagram for multi-algorithm fusion detection. Figure 3 This is a data processing detection graph for the clustering analysis engine. Figure 4 To verify the project's abnormal early warning chart. Detailed Implementation

[0019] The invention will be further explained below with reference to specific code logic and business scenarios.

[0020] Example 1: System Architecture and Data Model This system is developed based on the Spring Boot framework and adopts a typical MVC layered architecture.

[0021] (1) Entity layer: Defines the core data model.

[0022] 1) WarningRule: Stores warning rules, including fields testItem (test item), algorithm (algorithm identifier), and algorithmParams (algorithm parameters, such as threshold multiplier).

[0023] 2) WarningResult: Stores warning results, including patientId, warningLevel, warningTime, etc.

[0024] (2) Data Access Layer (Repository): Inherits from JpaRepository, provides CRUD operations on the database, and supports complex queries by time, project, and level.

[0025] Example 2: Software Implementation of Multi-Algorithm Fusion Detection In the WarningController class, the core interface / api / warning / trigger is defined. When new inspection data is received, the system executes the following logic:

[0026] Rule matching: Search for the corresponding rule entity in warningRuleRepository based on the inspection item name (e.g., "GLU").

[0027] Algorithm routing: The system reads the `algorithm` field from the rules and routes the data to the specific Service implementation class using a switch-case structure or a factory pattern.

[0028] switch (algorithm) {

[0029] case "threshold":

[0030] isAbnormal = thresholdAlgorithmService.isAbnormal(...); break;

[0031] case "arima":

[0032] isAbnormal = arimaAlgorithmService.isAbnormal(...); break;

[0033] case "svm":

[0034] isAbnormal = svmAlgorithmService.isAbnormal(...); break;

[0035] / / ... Other algorithms

[0036] }

[0037] Result processing: If isAbnormal is true, the system automatically generates the current timestamp, combines it with the warningLevel in the rule, constructs and saves a WarningResult object, and triggers a front-end alarm.

[0038] Example 3: Implementation of Dynamic Threshold Logic Based on Statistics

[0039] ThresholdAlgorithmService implements dynamic alerts based on patients' personal historical data. Its core code logic is as follows:

[0040] (1) Obtain historical data: Call historicalDataService to query the patient's past N test values ​​for the same item and store them in a List. <double>.

[0041] (2) Calculate the statistic:

[0042] 1) Iterate through the List to calculate the sum, then divide by Size to get the mean.

[0043] 2) Iterate through the List again, calculate the sum of squares of the differences between each data point and the mean, calculate the variance and take the square root to get the standard deviation (StdDev).

[0044] (3) Anomaly detection:

[0045] 1) Parse the algorithmParams passed from the front end (e.g., set it to 3.0).

[0046] 2) Judgment logic: Math.abs(currentValue - Mean) > 3.0 * StdDev.

[0047] 3) This logic ensures that the threshold changes dynamically with the patient's historical data, rather than being a fixed value.

[0048] Example 4: Implementation of the K-Means Clustering Analysis Engine

[0049] To uncover group characteristics, the system implements the ClusteringEngine class. This class does not rely on third-party black-box libraries but instead implements complete K-Means iteration logic:

[0050] (1) Initialization: Randomly select $K$ data points as initial centroids.

[0051] (2) Assignment: Traverse all test samples, calculate their Euclidean distance from each centroid, and assign them to the nearest cluster.

[0052] (3) Update: Traverse each cluster, calculate the arithmetic mean of all samples in the cluster, and use the mean as the new centroid.

[0053] (4) Iteration: Repeat the above steps until the centroid position no longer changes or the maximum number of iterations is reached (e.g., 100 times).

[0054] This module is used for cluster analysis of test results, helping doctors identify patient groups with similar test characteristics.< / double>

Claims

1. A method for detecting anomalies in medical laboratory data based on multi-algorithm fusion and dynamic early warning, characterized in that, Includes the following steps: Step S1: Data Objectification and Preprocessing. Raw medical test data is obtained through a data access interface and mapped to test result entity objects using Object Relational Mapping (ORM) technology. Null value filtering and normalization are performed on the numerical fields of these entity objects. S2: Constructing a Configurable Algorithm Service Pool. An algorithm service layer is built in the system backend. This layer contains at least two anomaly detection service classes implementing a unified interface. These anomaly detection service classes include at least a statistics-based threshold algorithm service, a time-series-based prediction algorithm service, and a machine learning-based classification algorithm service. S3: Dynamic Rule Loading and Strategy Distribution. In response to anomaly detection requests, preset warning rule entities are loaded from the database. The `algorithm` and `algorithm_params` fields in the rule entities are parsed, and the corresponding algorithm service classes are instantiated using the strategy pattern. S4: Parallel Detection of Multiple Algorithms and Result Fusion. The preprocessed test data is input in parallel into multiple instantiated algorithm service classes to obtain the Boolean-type abnormal state or floating-point-type abnormal probability of each algorithm output; the multi-source output results are aggregated through weighted voting logic to generate a comprehensive abnormality label; Step S5: Dynamic threshold determination based on historical sliding window. For the item to be tested, the patient's historical test data list is retrieved, the mean and standard deviation within the sliding window are calculated, and the deviation is dynamically calculated in combination with the current test results. If the deviation exceeds the dynamic threshold, a graded warning is triggered, and the warning result is persistently stored in the warning result data table. The method according to claim 1, characterized in that, The algorithm service pool in step S2 specifically includes the following: (1) Threshold Algorithm Service: used to calculate the statistical characteristics of historical data and determine whether the current value exceeds the range of $N$ times the standard deviation calculated dynamically; (2) Time Series Algorithm Service (ArimaAlgorithmService / ProphetAlgorithmService): used to predict the theoretical value range of the current time point based on historical time series data; (3) Classification Algorithm Service (SvmAlgorithmService / RandomForestAlgorithmService): used to perform binary or multi-class classification on the current test sample based on multi-dimensional feature vectors. The method according to claim 1, characterized in that, The code logic for dynamic threshold determination in step S5 executes the following process: Obtaining the historical data set List of the target inspection items. <double> history;< / double> Iterate through the set to calculate the mean (Mean) and standard deviation (StdDev); Parse the algorithm parameters to obtain the multiplier factor K (default value is 3.0); calculate the absolute difference Diff between the current test result Val$ and the mean Mean$; if Diff > K · StdDev, it is judged as an anomaly, and is mapped to three warning levels: "high", "medium" and "low" according to the size of Diff. The method according to claim 1, characterized in that, The method also includes a clustering analysis step for the test results: constructing a clustering engine class (ClusteringEngine) to receive a list of multidimensional test data; Initialize K centroid vectors; execute iterative logic: calculate the Euclidean distance from each sample point to each centroid, assign the sample to the cluster to which the nearest centroid belongs, and update the centroid coordinates of each cluster; stop when the centroid change is less than a preset threshold or the maximum number of iterations is reached, and output the clustering results to identify potential abnormal patient groups. The method according to claim 1, characterized in that, The method also includes a trend prediction step: obtaining historical data for a specified time span through the TrendPredictionService; executing linear regression logic: calculating the covariance and variance of the time series X and the test value Y, solving for the slope and intercept of the regression coefficient; and extrapolating the test value at future time points based on the regression equation y = Slope · x + Intercept. If the predicted value shows a deteriorating trend, an early warning signal is generated in advance. A medical laboratory data anomaly detection system based on multi-algorithm fusion and dynamic early warning, characterized in that, include: (1) Data layer (DAO): includes WarningRuleRepository, WarningResultRepository and PatientRepository, used to persist warning rules, warning results and patient information through JPA interface; (2) Algorithm service layer (Service): integrates ThresholdAlgorithmService, ArimaAlgorithmService and SvmAlgorithmService, used to provide specific anomaly detection logic implementation; integrates ClusteringEngine, used to perform K-Means or DBSCAN clustering operation; integrates TrendPredictionService, used to perform linear regression prediction; (3) Control layer (Controller): includes WarningController, used to receive front-end requests, parse warning rules, schedule algorithm service layer to perform calculation, and encapsulate ResponseEntity to return detection results; (4) Warning rule configuration module: used to provide a graphical interface, allowing users to configure test items, select algorithm type and set algorithm parameters through front-end form, and save the configuration information to the WarningRule entity. The system according to claim 1, characterized in that, The WarningController contains a triggerWarning interface, which is configured to: receive a WarningResult object containing the inspection items and results; query the WarningRuleRepository to obtain a list of matching rules; call the corresponding algorithm service using a switch-case logic branch based on the algorithm identifier (Stringalgorithm) in the rule; and if an anomaly is detected, automatically fill in the warning level and warning time, and call the save method to write it to the database. A computer device includes a memory and a processor, wherein the memory stores a computer program, characterized in that... When the processor executes the computer program, it implements the steps of the method as described in claim 1. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in claim 1.

Images