Medical data exception analysis processing method and system, terminal and medium

Abstract

The invention provides a medical data exception analysis processing method and system, a terminal and a medium, and belongs to the technical field of medical data processing, and the method specifically comprises the steps: obtaining and preprocessing medical original data, preliminarily screening abnormal data according to a preset rule, marking types, and storing the data in a cache region according to clinical priorities. And for the abnormal data in the cache region, matching historical cases, extracting clinical, equipment and time associated information, and outputting an analysis report. And generating an instruction packet containing an exception type, an interface parameter and an execution time limit, wherein the instruction packet is used for correcting data, calibrating equipment and rechecking a result, synchronously recording a log, triggering upgrading by a new exception and generating a new instruction packet. And when the exception appears repeatedly, generating a reverse verification instruction packet, performing sandbox reproduction, comparing differences, updating the knowledge base and the like, verifying the correction validity, and performing iteration if the correction is not passed. A medical data exception processing closed loop is formed, the processing efficiency and accuracy are improved, the medical quality and the patient safety are guaranteed, and the system adaptability is enhanced.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of medical data processing, and particularly relates to a medical data abnormality analysis processing method and system, a terminal and a medium. BACKGROUND

[0002] In today's medical and health field, the importance of data is increasingly prominent. Medical institutions will generate a large amount of data every day, including but not limited to patients' electronic medical records, medical imaging data, laboratory test results, etc. How to effectively manage and utilize these massive amounts of data is crucial for improving medical services and promoting the development of personalized treatment plans. At the same time, with the development of Internet of Things technology, more and more wearable devices are also applied to daily health management, further enriching the data sources.

[0003] For related technologies, the abnormality detection rule is mostly a set threshold, such as blood glucose > 11.1 mmol / L, which is determined to be abnormal, without considering the differences in clinical scenarios: for example, the timeliness requirement of test reports for emergency patients is much higher than that of ordinary outpatients, but the traditional rule may be uniformly set to 1 hour, resulting in delayed identification of emergency reports; the normal range of blood pressure for elderly patients should be wider than that of ordinary adults due to underlying diseases, but the traditional rule uniformly determines it as systolic pressure > 140 mmHg, resulting in a large number of false positives and wasting of medical resources. In addition, the abnormal type label is ambiguous and cannot distinguish between device failure and human input error, and subsequent processing lacks pertinence.

[0004] Moreover, in the prior art, the instruction execution of the medical device is mostly a one-time operation, lacking full-process recording, and the responsibility cannot be traced back after a problem occurs. In addition, if a new abnormality is triggered during execution, the system cannot pause the current process and generate new instructions, leading to the spread of faults. After the reference value range of a certain test item is adjusted in the current new guidelines, the traditional system will not be updated in time, resulting in a large number of false abnormalities; when the same type of abnormality occurs repeatedly, the rules cannot be optimized through historical data. SUMMARY

[0005] The application provides a medical data abnormality analysis processing method, which improves the accuracy, reliability and clinical applicability of abnormality processing, and provides systematic protection for medical data quality control and diagnosis and treatment safety.

[0006] The method comprises the following steps: Step S101: acquiring medical raw data and preprocessing the medical raw data; Step S102: presetting an abnormality detection rule, performing abnormality preliminary screening on the preprocessed medical data, marking the clinical abnormality type of the preliminary screened abnormal data, and storing it in a cache area according to the clinical scene priority; Step S103: For the abnormal data in the cache area, match the historical cases, extract the clinical context, device association information and time association information of the abnormal data, and output the abnormal analysis report; Step S104, according to the abnormal analysis report, generate a medical data analysis instruction package carrying the abnormal type, event, target system interface parameter and execution time limit; Step S105, based on the medical data analysis instruction package, the data field value correction, calibration process and review of the test results of the medical equipment; Synchronize the information recorded in the medical quality control log; If a new abnormality is detected during execution, trigger abnormality escalation and generate a new instruction package; Step S106, when the abnormality repeatedly occurs, generate a reverse verification instruction package, and send the reverse verification instruction package to the medical abnormality self-repair process, replay the abnormal data flow in the sandbox, generate a reproduction result, compare the reproduction result with the original abnormality field by field, output the difference characteristics, update the medical knowledge base, detection rules and instruction templates according to the difference characteristics, execute the updated instruction package, verify whether the abnormality is eliminated, and if the test is passed, terminate.

[0007] Preferably, in step S106, the reverse verification instruction package execution mode comprises: Reproduce the processed abnormality in a controlled sandbox environment; Differential comparison between the reproduction result and the original abnormal data to extract difference characteristics; Reverse update the medical knowledge base, abnormality detection rules and instruction templates according to the difference characteristics; Execute the updated instruction package again to verify the correction effectiveness; Synchronize the updated instruction package to the medical terminal.

[0008] Preferably, step S102 specifically comprises: Based on medical guidelines and clinical needs, build abnormality detection rules; For different medical data, perform abnormality detection, specifically compare the preset integrity, logical contradiction and timeliness rules field by field through field matching rules; Use natural language processing technology to extract key information in the text and compare the time correlation; According to the potential impact on patient safety, divide the priority of the detected abnormal data; Store the abnormal data marked with clinical abnormality type, detection rule basis and priority in the medical abnormality cache area.

[0009] Preferably, step S103 specifically comprises: Instance all the test items, image sequences, medication orders and previous medical history nodes involved in the patient's current visit into a panoramic atlas, and the atlas edge weight represents the clinical correlation strength; Using the moment of abnormal triggering as the origin, extending forward to the first symptom record and backward to the latest medical order, a timeline is formed, and each data refresh or device status change is marked on the axis; The three modalities of information—textual disease course, numerical test, and image label—are converted into a unified evidence vector. Cross-modal joint representation is obtained by concatenating the vectors. The cross-modal evidence vector concatenation can be defined as text vector T, numerical vector N, and image vector I, with a unified vector V=[T;N;I], and L2 norm normalization is adopted. Encapsulate graph nodes, timeline events, and cross-modal evidence vectors into digitally watermarked event reports to ensure that any subsequent modifications can be traced.

[0010] Preferably, the step of converting the three modalities of information—textual disease history, numerical tests, and image labels—into a unified evidence vector specifically includes: For three types of data—textual disease progression, numerical tests, and image labels—clinical knowledge-driven extraction rules were used to extract key information. By comparing and extracting key information, contradictory content can be identified and corrected. The extracted features are assigned clinical relevance weights, which are adjusted according to the type of abnormality. The fused feature vectors are bound to modal metadata to generate cross-modal joint evidence vectors with version numbers. The final output joint evidence vectors are used for subsequent comparative analysis with historical cases and medical guidelines.

[0011] Preferably, step S105 specifically includes: The medical data analysis instruction package is broken down into one or more indivisible minimum operation units. Each minimum operation unit corresponds to a single data field correction, single point calibration, or single item review action, and is assigned a globally unique operation sequence number. Before the official release, the smallest operating unit is sent to a digital twin that is synchronized with the real device to generate a pre-rehearsal result. Only if the pre-rehearsal is successful can the result be released to the real device. Set a rollback time window for each minimum operation unit. If an abnormal rebound is detected within the window, immediately trigger a rollback and restore the device to its original state. The length of the window can be adjusted according to the clinical scenario. The smallest operation unit sequence number, pre-run result, actual execution result and timestamp are linked together into an indivisible chain record, and sealed and stored in the medical quality control log to ensure that no single record can be tampered with during subsequent audits.

[0012] Preferably, before the formal issuance of the steps, the smallest operating unit is sent to a digital twin that is synchronized with the real device for execution, and the generated pre-rehearsal results specifically include: Based on the hardware specifications, software configuration, and historical operation logs of real devices, a digital twin that is mapped 1:1 to the real device is constructed. The system converts the operation instructions of the smallest operating unit into execution instructions that the twin can recognize. The adaptation includes: converting clinical instructions into device control instructions; mapping the reference range field to the twin's test result storage module; and verifying whether the correction operation requires prior device calibration. Drive the twin to execute operations according to instructions, synchronously collect the status data and execution results of the twin during the execution process, and verify the execution results with the expected goals; If the rehearsal fails, analyze the reasons for the failure and adjust the twin or the operation instructions.

[0013] This application also provides a medical data anomaly analysis and processing system, the system comprising: The data preprocessing module is used to acquire raw medical data and preprocess it. The anomaly screening module is used to preset anomaly detection rules, perform anomaly screening on preprocessed medical data, mark the anomaly data in the initial screening as clinical anomaly type, and store it in the cache according to the priority of clinical scenario. The event analysis module is used to match abnormal data in the cache with historical cases, extract the clinical context, device association information and time association information of the abnormal data, and output an abnormal analysis report. The instruction generation module is used to generate medical data analysis instruction packages that carry the anomaly type, event, target system interface parameters, and execution time limit based on the anomaly analysis report. The instruction execution module corrects data field values, performs calibration procedures, and verifies test results for medical devices based on medical data analysis instruction packages; it also records the information of the issued instructions in the medical quality control log simultaneously; if a new anomaly is detected during execution, it triggers an anomaly escalation and generates a new instruction package. The reverse verification module is used to generate a reverse verification instruction package when an anomaly recurs. The reverse verification instruction package is then sent to the medical anomaly self-repair process, where the anomaly data stream is replayed in the sandbox to generate a reproduction result. The reproduction result is compared with the original anomaly field by field to output the difference features. Based on the difference features, the medical knowledge base, detection rules, and instruction templates are updated. The updated instruction package is then executed to verify whether the anomaly has been eliminated. If the test passes, the process terminates.

[0014] According to another embodiment of this application, a medical terminal is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the medical data anomaly parsing and processing method.

[0015] According to another embodiment of this application, a storage medium is also provided, on which a computer program is stored, which, when executed by a processor, implements the steps of the medical data anomaly analysis and processing method.

[0016] As can be seen from the above technical solutions, the present invention has the following advantages: The medical data anomaly analysis and processing method involved in this application preprocesses raw medical data to meet the requirements for medical data use and avoids analytical biases caused by the disorder of raw data. By pre-setting anomaly detection rules that are aligned with clinical practice, it accurately labels anomaly types and stores them according to clinical scenario priorities. It integrates clinical context, device association, and time information, and matches historical cases to make event localization more accurate. The generated instruction package carries the event, interface parameters, and execution time limit, specifically correcting data, calibrating equipment, and verifying results. By logging the entire operation process and responding to new anomalies, it not only meets the requirements of medical quality control traceability but also promptly interrupts the spread of risks. The reverse verification mechanism, through sandbox reproduction, difference comparison, and rule iteration, enables the system to autonomously adapt to new scenarios and reduce the recurrence of similar anomalies. This improves the accuracy, reliability, and clinical applicability of anomaly handling, providing systematic protection for medical data quality control and treatment safety. Attached Figure Description

[0017] To more clearly illustrate the technical solution of the present invention, the accompanying drawings used in the description will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 Flowchart of medical data anomaly analysis and processing method; Figure 2 This is a schematic diagram of a medical data anomaly analysis and processing system; Figure 3 This is a schematic diagram of a medical terminal. Detailed Implementation

[0019] The following will describe in detail the medical data anomaly analysis and processing method involved in this application. Specific details such as particular system structures and technologies are presented for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application can also be implemented in other embodiments without these specific details.

[0020] It should be understood that, when used in this specification, terms include indicating the presence of a described feature, integral, step, operation, element, and / or component, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or collections thereof. The terms include, encompass, have, and variations thereof mean including but not limited to, unless otherwise specifically emphasized.

[0021] The statements such as "one embodiment" or "some embodiments" described in this application mean that one or more embodiments of this application include the specific features, structures, or characteristics described in that embodiment. Therefore, the statements such as "in one embodiment," "in some embodiments," "in other embodiments," and "in still other embodiments" in this application do not necessarily refer to the same embodiment, but rather mean one or more, but not all, embodiments, unless otherwise specifically emphasized.

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

[0023] Please see Figure 1 The diagram shows a flowchart of a medical data anomaly parsing and processing method in a specific embodiment. The method includes: Step S101: Obtain raw medical data and preprocess it.

[0024] In some embodiments, the acquired raw medical data includes diagnostic codes, medication dosages, CT images, blood routine results, and real-time physiological signals from wearable devices in electronic medical records.

[0025] Optionally, during preprocessing, privacy fields are de-identified using an anonymization method, such as retaining the first 6 and last 4 digits of the patient's ID number and replacing the middle digits with asterisks; data that fails to be collected must have the reason for the failure recorded, and access permissions are set for the temporary isolation area, allowing only system administrators to view it.

[0026] Step S102: Preset anomaly detection rules, perform initial screening of preprocessed medical data for anomalies, mark the anomaly data in the initial screening as clinical anomaly types, and store them in the cache according to clinical scenario priority.

[0027] In this embodiment, the anomaly detection rules can combine clinical logical contradiction rules and data timeliness rules to set thresholds for different scenarios. For example, emergency ECG reports must be generated within 30 minutes, and inpatient medical record progress notes must be completed within 24 hours. Data integrity rules specify fields, such as surgical records must include anesthesia method, surgical duration, and blood loss. Format standardization rules require data to conform to industry standards, such as test results units must use the International System of Units (SI). Anomaly type markings include timeliness anomalies, emergency report delay anomalies, etc.

[0028] It should be noted that the preprocessed data is screened based on medical professional rules to accurately identify data that does not meet the requirements of clinical logic, timeliness, format or completeness. Through classification, labeling and prioritization, it provides focused abnormal data for subsequent event analysis.

[0029] Step S103: For abnormal data in the cache, match historical cases, extract the clinical context, device association information and time association information of the abnormal data, and output an abnormal analysis report.

[0030] This embodiment can be matched with medical guidelines and rules, retrieving corresponding clinical guideline clauses. For example, when analyzing an abnormal serum potassium level of 7.8 mmol / L, it matches the treatment guidelines for hyperkalemia in the "Clinical Practice Guidelines - Endocrinology" to check for related abnormalities such as failure to use potassium-depleting diuretics or unrecorded renal insufficiency. Historical case similarity matching requires searching for similar abnormal cases in recent times. For example, if a certain model of biochemical analyzer detects elevated serum potassium, the time of the abnormality is compared using a text similarity algorithm, such as the 6th day after equipment calibration, ambient temperature, and treatment results. Clinical context includes the patient's underlying diseases and medication history; equipment-related information includes the equipment's most recent calibration time and maintenance records; time-related information includes whether the abnormality coincides with system upgrades or personnel shift changes. The event analysis report provides specific causes and related factors.

[0031] In this way, through dual verification with medical guidelines and historical cases, combined with the clinical, equipment, and time aspects of abnormal data, the root cause of the anomaly can be accurately located. This improves the accuracy of event localization; multi-dimensional feature extraction avoids isolated analysis.

[0032] Step S104: Based on the anomaly analysis report, generate a medical data analysis instruction package that carries the anomaly type, event, target system interface parameters, and execution time limit.

[0033] The medical data analysis instruction package in this embodiment must include all the parameters required for execution. For example, a data correction instruction may involve: Target field: Surgical record; Blood loss; Correction value: 500ml; Correction basis: Anesthesia record.

[0034] The equipment calibration instruction may include the following: Target equipment: Biochemical analyzer XJ-2000; Calibration item: Serum potassium test; Calibration solution batch number: 20250612; Calibration procedure: Perform according to section 3.2 of the equipment manual. The result verification instruction specifies the verification equipment: Backup biochemical analyzer XJ-3000; Verification sample: Original blood sample number 20250726001; Number of verifications: 2.

[0035] This embodiment transforms event analysis results into specific executable instructions, clearly defining the operation targets, content, basis, and time limits to ensure the standardization and operability of subsequent processing steps.

[0036] Step S105: Based on the medical data analysis instruction package, correct the data field values ​​of the medical equipment, verify the calibration process and test results; simultaneously record the information of the issued instructions in the medical quality control log; if a new anomaly is detected during the execution process, trigger an anomaly escalation and generate a new instruction package.

[0037] In this embodiment, when correcting data field values, the electronic medical record system interface is invoked. An immutable modification log is generated after modification, which may include the values ​​before and after modification, the executor, and the time. Equipment calibration instructions are sent to the medical device, and calibration progress is fed back in real time. A calibration report is generated upon completion of calibration. During result verification, the system simultaneously retrieves the original sample and backup equipment, comparing the differences between the two test results. The medical quality control log must include a unique instruction identifier, the execution terminal IP address, the affected patient range, and the execution result code. Upon detection of a new anomaly, current non-emergency operations are immediately suspended. If equipment calibration fails, an alarm is pushed to the equipment management terminal. Process data is recorded to ensure traceability, and responses to new anomalies ensure the continuity and security of the processing.

[0038] Step S106: When an anomaly recurs, a reverse verification instruction package is generated and sent to the medical anomaly self-repair process. The anomaly data stream is replayed in the sandbox to generate a reproduction result. The reproduction result is compared with the original anomaly field by field to output the difference features. The medical knowledge base, detection rules, and instruction templates are updated based on the difference features. The updated instruction package is executed to verify whether the anomaly has been eliminated. If the test passes, the process terminates; if it fails, the process returns to continue iterating.

[0039] In this embodiment, "unexpected results" refers to data that still does not conform to clinical logic after correction, such as blood glucose values ​​still contradicting medication dosage or discrepancies exceeding the allowable range. "Recurrence of similar anomalies" refers to ≥3 calibration anomalies occurring within 30 days for the same device and the same item. The simulated reproduction sub-instruction in the reverse verification instruction package recreates the anomaly scenario in a sandbox environment, such as replicating the device parameters, network environment, and system load during the original data acquisition. Difference comparison is performed field by field; for example, the reproduced abnormal blood potassium value is 7.8 mmol / L, while the original abnormal value was 7.6 mmol / L, with the difference being 'device internal temperature'. The source correction sub-instruction updates rules based on the difference characteristics, such as including device temperature > 26℃ in the blood potassium detection anomaly warning condition. The self-healing test requires three consecutive executions of the updated instruction package, with each instance meeting the criteria of corrected data conforming to clinical logic and a verification difference < 0.3 mmol / L to pass. The iteration process is allowed a maximum of five times; if it still fails, a manual intervention warning is triggered.

[0040] It can be seen that by using sandbox simulation, difference analysis, rule updates, and iterative testing, a self-optimizing closed loop is constructed to continuously correct system defects and improve the accuracy and stability of anomaly handling.

[0041] In some specific embodiments, in step S106, the reverse verification instruction packet is executed in the following ways: Step S1061: Reproduce the handled exception in a controlled sandbox environment.

[0042] This embodiment reproduces the anomaly in a virtual sandbox consistent with the real environment, eliminating external interference factors and accurately restoring the conditions and processes that caused the anomaly, thus providing a reliable control sample for subsequent differential analysis.

[0043] Step S1062: Compare the reproduced results with the original abnormal data and extract the difference features.

[0044] This embodiment compares the reproduced results with the original abnormal data from multiple dimensions to identify the differences between the two in terms of data characteristics, equipment status, etc., and to locate the key factors that cause the differences.

[0045] Step S1063: Update the medical knowledge base, anomaly detection rules, and instruction templates in reverse based on the difference characteristics.

[0046] This embodiment can update the medical knowledge base based on the difference characteristics and supplement new abnormal correlations. For example, when the device status code is E02, it may be accompanied by a detection value that is 10% lower. When updating the abnormal detection rules, the threshold is adjusted or a judgment condition is added. For example, in the original rule, a blood glucose value > 13.9 mmol / L is abnormal. Based on the difference characteristics, it is adjusted to a blood glucose value > 13.9 mmol / L and a normal device status code as abnormal. When updating the instruction template, the operation steps are optimized. For example, the original calibration instruction only included parameter reset. A new step is added to solve the status code E02 problem.

[0047] Step S1064: Execute the updated instruction package again to verify the effectiveness of the correction.

[0048] To verify the effectiveness of the corrections, the updated instruction package is executed again in the sandbox, and the process is repeated 2-3 times. If no anomalies are found in multiple consecutive repetitions, the verification is considered successful. If anomalies still occur, the new differences are recorded and marked for further optimization. In this way, by repeatedly executing the updated instruction package, the effectiveness of rule and template adjustments in eliminating anomalies is verified, ensuring the reliability of the corrective measures and preventing rules that do not meet expectations from being directly applied to the real system.

[0049] Step S1065: Synchronize the updated instruction package to the medical terminal.

[0050] In this embodiment, when synchronizing to medical terminals, the instruction packet format is adapted according to the terminal type. For example, binary control instructions are sent to testing equipment, and visual rule descriptions are pushed to the doctor's workstation. During the synchronization process, the terminal receiving status is recorded, and priority push is initiated for terminals that fail to synchronize. This ensures that all relevant terminals use the latest rules, thereby improving the overall system's ability to handle anomalies.

[0051] In one embodiment of the present invention, based on step S102, the following will provide a possible embodiment and its specific implementation will be described in a non-limiting manner. Step S102 specifically includes: Step S1021: Construct abnormal detection rules based on medical guidelines and clinical needs.

[0052] Anomaly detection rules include: Specific criteria for determining logical contradictions in clinical practice; Clinical thresholds for data timeliness; A list of fields for data integrity, such as the inspector's signature and reference range in an inspection report; Medical-specific requirements for standardized formats.

[0053] For any preprocessed medical data D, the logical formula for detecting whether it is abnormal is: Anomaly flag = ∃ Rule R ∈ rule base, such that D satisfies the triggering condition of R.

[0054] The triggering conditions for rule R are defined by medical guidelines. If at least one rule R is triggered, then D is marked as abnormal data.

[0055] Step S1022: Detect abnormal fits in medical data. For different types of medical data, anomaly detection is performed. Specifically, by using field matching rules, each field is compared against preset rules for completeness, logical contradictions, and timeliness.

[0056] Key information in the text is extracted using natural language processing (NLP) techniques and compared with its temporal relevance.

[0057] Key descriptions are identified using a medical terminology dictionary (such as the ICD-10 terminology database) and compared with imaging diagnostic guidelines. When the adaptation module outputs test results, it simultaneously records the specific rule clauses upon which the test was based.

[0058] Step S1023: Prioritize the detected abnormal data according to their potential impact on patient safety. The prioritization method includes: clinical scenario risk, such as abnormal vital signs of ICU patients > abnormal test values ​​of general outpatients. The degree of correlation between data, such as abnormal preoperative test results of surgical patients > abnormal follow-up data of discharged patients; Timeliness requirements, such as abnormal test results for emergency patients exceeding the time limit compared to abnormal report formats for inpatients.

[0059] Priority classification is achieved through a clinical risk assessment form, and the classification results are stored in conjunction with abnormal data.

[0060] It should be noted that the priority score S is calculated based on three dimensions, using a weighted summation method: S = α × A + β × B + γ × C Where: A represents the patient scenario risk score, ICU=5, emergency room=4, general ward=3, outpatient=2, discharge follow-up=1; B represents the degree of data correlation, with surgical patients = 5, critically ill patients = 4, and ordinary patients = 3; C represents the processing time requirement: immediate processing = 5, processing within 24 hours = 4, and processing within 72 hours = 3. α, β, and γ are weighting coefficients. Optionally, α = 0.5, β = 0.3, and γ = 0.2, which are determined by clinical experts based on experience.

[0061] The final priority is determined based on the S value: S≥4.5 is Level 1, 3.5≤S<4.5 is Level 2, and S<3.5 is Level 3.

[0062] Step S1024: Store the abnormal data marked with clinical abnormality type, detection rule basis and priority in a medical abnormality cache area encrypted with AES-256.

[0063] Access control is set for the cache area, and the storage timestamp and data version number are recorded.

[0064] As can be seen, step S102 performs an initial screening for anomalies in medical data. By integrating medical expertise with medical business scenarios, the anomaly detection results are made more aligned with actual medical needs, avoiding processing deviations caused by misjudgments or omissions due to general rules.

[0065] In one embodiment of the present invention, based on step S103, the following will provide a possible embodiment and its specific implementation will be described in a non-limiting manner. Step S103 specifically includes: Step S1031: Instantiate all the test items, imaging sequences, medication orders and previous medical records related to the patient's current visit into a panoramic map, with the edge weights of the map representing the clinical correlation strength.

[0066] It should be noted that, using the de-identified patient ID as the root, all test results, images, medical orders, and key historical nodes of this visit are retrieved to form a read-only node pool.

[0067] Based on the deviation of the test results from the normal reference range, adjust the display size and color intensity of the nodes in the spectrum. The greater the deviation, the more prominent the node becomes.

[0068] At the moment an anomaly is triggered, the one-time association strength between all nodes is recorded and fixed into a snapshot to prevent the association from being lost due to subsequent data refresh.

[0069] Once the panoramic map is generated, an invisible watermark is immediately created for its entire content and written to a read-only area. Any subsequent retrieval must verify the integrity of the watermark to ensure that event analysis is based on the original map.

[0070] As can be seen, after receiving an anomaly record, the system first uses the patient's unique de-identified ID as an index to quickly aggregate all the patient's test values, image labels, medical orders, and key medical record fragments from the previous visit, constructing a real-time panoramic map. The size and color of the nodes in the map change in real time with the degree of deviation, helping analysts to locate high-risk areas at a glance. At the moment the anomaly is triggered, the system captures and saves the correlation strength between nodes as an instantaneous snapshot to prevent subsequent data updates from destroying the scene. Finally, the entire map is locked as read-only using invisible watermarking technology, and any subsequent analysis is based on this tamper-proof original map, thereby ensuring the timeliness and objectivity of the event analysis.

[0071] The correlation between nodes in a graph can be calculated using the Jaccard similarity coefficient, which measures the ratio of node intersection to union.

[0072] Step S1032: Using the moment of abnormal triggering as the origin, extend forward to the first symptom record and backward to the latest medical order to form a time axis with second-level resolution, and mark each data refresh or device status change on the axis.

[0073] Step S1033: Convert the three modal information of textual disease course, numerical test and image label into a unified evidence vector, and obtain a cross-modal joint representation by vector concatenation.

[0074] Optionally, cross-modal evidence vector concatenation can be defined as text vector T, numerical vector N, image vector I, and unified vector V=[T;N;I], using L2 norm normalization.

[0075] Step S1034: Encapsulate the graph nodes, timeline events, and cross-modal evidence vectors into an event report with a digital watermark to ensure that any subsequent modifications can be traced.

[0076] As can be seen, the panoramic atlas can intuitively present the correlation between patient diagnosis and treatment data, highlight abnormal nodes, and help to quickly focus on key information; the time axis accurately records temporal changes, providing a clear temporal background for event analysis and facilitating the identification of temporal correlation factors for the occurrence of abnormalities; cross-modal evidence vector integration realizes the effective fusion of different types of data, improving the comprehensiveness of the analysis; event reports with digital watermarks ensure the authenticity and traceability of the analysis results, avoid data tampering affecting the analysis conclusions, and provide a reliable basis for subsequent review and rule optimization, thereby improving the accuracy, comprehensiveness, and credibility of event analysis.

[0077] In one embodiment of the present invention, based on step S1033, the following will provide a possible embodiment and its specific implementation will be described in a non-limiting manner. Step S1033 specifically includes: Step S10331: For the three types of data—textual disease course, numerical test, and image label—key information is extracted using clinical knowledge-driven extraction rules.

[0078] Step S10332: Compare the extracted key information to identify and correct contradictory content: This includes determining whether there are text-to-value conflicts. For example, if the text-based medical record states that the patient did not have a fever, but the numerical check shows a body temperature of 38.5℃, a conflict flag is triggered, requiring manual or system-based correction based on the clinical context.

[0079] Check for conflicts between text and image data. For example, if the text describes no lesions in the liver, but the image label indicates a low-density nodule in the right lobe of the liver, a conflict marker is triggered. It is necessary to verify whether the image examination time matches the text record time.

[0080] Are there any conflicts between numerical values ​​and imaging findings? For example, if numerical tests show a hemoglobin level of 80 g / L (anemia), but the imaging label does not mention any anemia-related changes, a conflict marker is triggered. The rationality of this case needs to be analyzed in conjunction with the patient's underlying disease (such as chronic kidney disease).

[0081] Step S10333: Assign clinical relevance weights to the extracted features, adjusting the weights according to the abnormality type: In the emergency abnormality, the weight of the image label was set to 0.6, the weight of the numerical test was set to 0.3, and the weight of the text course was set to 0.1. In chronic abnormalities, the weight of numerical tests was set to 0.5, the weight of textual disease course was set to 0.3, and the weight of image labels was set to 0.2. After weighting, the modal features are superimposed according to their weights to generate a fusion feature vector that reflects clinical priority.

[0082] Step S10334: Bind the fused feature vector to the modal metadata to generate a cross-modal joint evidence vector with a version number. The final output joint evidence vector is used for subsequent comparative analysis with historical cases and medical guidelines.

[0083] As can be seen, step S1033 transforms scattered text, numerical, and image modal information into a cross-modal evidence vector with consistency and clinical relevance. Unlike existing technologies that simply splice together the physical fusion of multimodal data, this step achieves logical fusion of multimodal data through clinical knowledge-driven key information extraction, conflict detection and correction, and weight allocation. This makes the fused vector more aligned with the actual needs of medical scenarios, improving the comprehensiveness and accuracy of anomaly analysis.

[0084] In one embodiment of the present invention, based on step S105, the following will provide a possible embodiment and its specific implementation will be described in a non-limiting manner. Step S105 specifically includes: Step S1051: Divide the medical data analysis instruction package into one or more indivisible minimum operation units. Each minimum operation unit corresponds to a single data field correction, single point calibration, or single item review action, and is assigned a globally unique operation sequence number.

[0085] Step S1052: Before the formal distribution, the smallest operation unit is sent to the digital twin that is synchronized with the real device for execution to generate a pre-rehearsal result. Distribution to the real device is only allowed if the pre-rehearsal is successful.

[0086] Step S1053: Set a rollback time window for each minimum operation unit. If an abnormal rebound is detected within the window, immediately trigger a rollback and restore the device to its original state. The length of the window can be adjusted according to the clinical scenario.

[0087] Step S1054: Connect the smallest operation unit number, the pre-run result, the actual execution result and the timestamp into an indivisible chain record, and seal and store it in the medical quality control log to ensure that subsequent audits cannot tamper with a single record.

[0088] Step S105 of this embodiment breaks down the medical data analysis instruction package into the smallest operational unit, verifies the feasibility of the operation through digital twin pre-simulation, sets a rollback window to handle abnormal rebounds during execution, and finally seals the entire operation process with chained records, thereby achieving refined, secure, and traceable anomaly handling. Specifically, the instruction package is first broken down to ensure that the operation is simple and clear; then, execution risks are eliminated through digital twin pre-simulation; next, a rollback window is used to ensure the reversibility of the operation; and finally, the process data is solidified with chained records, forming a complete closed loop from instruction breakdown to execution traceability. This improves the security, reliability, and standardization of anomaly handling.

[0089] In one embodiment of the present invention, based on step S1052, the following will provide a possible embodiment and its specific implementation will be described in a non-limiting manner. Step S1052 specifically includes: Step S10521: Based on the hardware specifications, software configuration, and historical operation logs of the real device, construct a digital twin that is mapped 1:1 to the real device.

[0090] Hardware specifications may include the sensor model and calibration parameters of the testing equipment. Software configuration may include the testing reagent formulation and data processing algorithms.

[0091] The synchronization includes: equipment temperature and voltage; sample processing steps; and historical fault characteristics of data deviation caused by sensor drift, ensuring that the twin is completely synchronized with the real equipment.

[0092] Step S10522: Convert the operation instructions of the smallest operating unit into execution instructions recognizable by the digital twin. The adaptation includes: converting clinical instructions into device control instructions; mapping the reference range field to the test result storage module of the digital twin; and verifying whether the correction operation requires prior device calibration. The adapted instructions are sent to the digital twin for execution via the digital twin interface.

[0093] Step S10523: Drive the twin to execute operations according to instructions, and synchronously collect the status data and execution results of the twin during the execution process. Verify the execution results with the expected goals.

[0094] Verification methods include: data consistency, process compliance, and equipment compatibility. A pre-performance report is generated, containing verification conclusions and reasons for failure.

[0095] Step S10524: If the rehearsal fails, analyze the cause of the failure and adjust the twin or operation instructions.

[0096] Specifically, this includes: if the twin synchronization is off, resynchronizing the twin by acquiring real-time data from the actual device; if the command parameters are incorrect, adjusting the command parameters and regenerating the adapted command; if there is a conflict in the logical flow, adding preconditions to the command. After adjustment, the re-execution of the simulation is repeated until the simulation report is marked as successful, at which point commands are sent to the actual device.

[0097] It should be noted that the synchronization between the twin and the real device is based on a real-time data update mechanism, and the synchronization frequency is determined by the rate of change of the device's key parameters. For example, if the minimum change cycle of the device parameters is 0.5 seconds, and the maximum clinically permissible delay is 2 seconds, then T = 2 seconds, ensuring that the error between the twin's state and the real device is ≤5%. The iteration termination condition in this embodiment is: N consecutive successful pre-runs, and a verification pass rate ≥95%. If the termination condition is not met, the system adjusts the twin parameters or operation commands until the termination condition is met.

[0098] Step S1052 involves constructing a digital twin that is completely identical to the real device. Operation commands are adapted and converted before being executed within the twin. The matching of the execution results with the expected goals is verified, and targeted adjustments are made for failed rehearsals until the rehearsal is successful, ensuring the safety and feasibility of commands issued to the real device. Specifically, a 1:1 digital twin is first constructed based on the hardware, software, and operational data of the real device; then, operation commands are converted into a format recognizable by the twin and sent for execution; next, the execution results are verified to meet the requirements; finally, failures are analyzed, adjustments are made, and the rehearsal is repeated, forming a complete pre-verification process from twin construction to command verification. This process proactively identifies potential problems; the targeted adjustment mechanism after rehearsal failures efficiently resolves issues and improves the feasibility of commands. Through this series of steps, the failure rate and risk of operations performed by the real device are reduced, ensuring the stable operation of medical equipment and the accuracy of data processing, while also minimizing interference with clinical diagnosis and treatment caused by operational errors.

[0099] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0100] The following are embodiments of the medical data anomaly analysis and processing system provided in this disclosure. This system and the medical data anomaly analysis and processing methods in the above embodiments belong to the same inventive concept. For details not described in detail in the embodiments of the medical data anomaly analysis and processing system, please refer to the embodiments of the above medical data anomaly analysis and processing methods.

[0101] like Figure 2 As shown, the system includes: Data preprocessing module 201 is used to acquire raw medical data and preprocess the raw medical data; The anomaly screening module 202 is used to preset anomaly detection rules, perform anomaly screening on preprocessed medical data, mark the anomaly data in the screening as clinical anomaly types, and store them in the cache according to the priority of clinical scenarios. Event analysis module 203 is used to match abnormal data in the cache with historical cases, extract the clinical context, device association information and time association information of the abnormal data, and output an abnormal analysis report. The instruction generation module 204 is used to generate a medical data analysis instruction package carrying the anomaly type, event, target system interface parameters and execution time limit based on the anomaly analysis report; The instruction execution module 205 corrects data field values, performs calibration procedures, and verifies test results for medical devices based on medical data analysis instruction packages; it also records the information of the issued instructions in the medical quality control log; if a new anomaly is detected during the execution process, it triggers an anomaly escalation and generates a new instruction package. The reverse verification module 206 is used to generate a reverse verification instruction package when an anomaly recurs. The reverse verification instruction package is sent to the medical anomaly self-repair process, which replays the anomaly data stream in the sandbox, generates a reproduction result, compares the reproduction result with the original anomaly field by field, outputs the difference features, updates the medical knowledge base, detection rules and instruction templates based on the difference features, executes the updated instruction package, and verifies whether the anomaly has been eliminated. If the test passes, the process terminates.

[0102] like Figure 3 As shown, this application also provides a medical terminal, including a display module 103, a memory 102, a processor 101, and a computer program stored in the memory and executable on the processor 101. When the processor 101 executes the program, it implements the steps of a medical data anomaly analysis and processing method.

[0103] In embodiments of the present invention, medical terminals include, but are not limited to, laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. Medical terminals may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the embodiments described and / or claimed herein.

[0104] In this embodiment, processor 101 may be implemented using at least one of an application-specific integrated circuit, a programmable logic device, a field-programmable gate array, a processor, a controller, a microcontroller, a microprocessor, or an electronic unit designed to perform the functions described herein. In some cases, such an implementation may be implemented within a controller. For software implementation, implementations such as processes or functions may be implemented with separate software modules that allow the performance of at least one function or operation. Software code may be implemented by a software application (or program) written in any suitable programming language, and the software code may be stored in memory and executed by the controller.

[0105] The display module 103 is used to display information input by the user or information provided to the user. The display module 103 may include a display panel, which may be configured in the form of a liquid crystal display, an organic light-emitting diode, or the like.

[0106] The memory 102 can be used to store software programs and various data. The memory 102 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0107] This application also provides a storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the medical data anomaly analysis and processing method.

[0108] The storage medium may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example,, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of readable storage media include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0109] In a storage medium, a readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying readable program code. This propagated data signal may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0110] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A medical data anomaly resolution processing method, characterized by, The method comprises: Step S101: obtaining medical raw data and preprocessing the medical raw data; Step S102: presetting an abnormality detection rule, performing abnormality preliminary screening on the preprocessed medical data, marking a clinical abnormality type of the screened abnormal data, and storing the abnormal data in a cache area according to a clinical scene priority; Step S103: matching historical cases for the abnormal data in the cache area, extracting clinical context, device association information and time association information of the abnormal data, and outputting an abnormality analysis report; Step S104: generating a medical data analysis instruction package carrying an abnormality type, an event, a target system interface parameter and an execution time limit according to the abnormality analysis report; Step S105: correcting a data field value, a calibration process and a review of a test result of a medical device based on the medical data analysis instruction package; synchronously recording information of the instruction in a medical quality control log; if a new abnormality is detected during the execution, triggering abnormality escalation and generating a new instruction package; Step S106: when an abnormality repeatedly occurs, generating a reverse verification instruction package, issuing the reverse verification instruction package to a medical abnormality self-repair process, replaying abnormal data flow in a sandbox, generating a reproduction result, comparing the reproduction result with the original abnormality field by field, outputting a difference feature, updating a medical knowledge base, a detection rule and an instruction template according to the difference feature, executing the updated instruction package, verifying whether the abnormality is eliminated, and terminating if the test is passed.

2. The medical data abnormality analysis processing method according to claim 1, wherein the reverse verification instruction package in step S106 comprises: reproducing the processed abnormality in a controlled sandbox environment; comparing the reproduction result with the original abnormal data to extract a difference feature; updating the medical knowledge base, the abnormality detection rule and the instruction template according to the difference feature; executing the updated instruction package again to verify the correction effectiveness; synchronizing the updated instruction package to a medical terminal.

3. The medical data abnormality analysis processing method according to claim 1, wherein step S102 specifically comprises: constructing an abnormality detection rule based on medical guidelines and clinical needs; detecting abnormalities for different medical data, specifically comparing preset integrity, logical contradiction and timeliness rules field by field through field matching rules; and extracting key information in the text using natural language processing technology and comparing the information with time correlation; dividing the detected abnormal data into priorities according to their potential impact on patient safety; storing the abnormal data marked with a clinical abnormality type, a detection rule basis and a priority in a medical abnormality cache area.

4. The medical data abnormality analysis processing method according to claim 1, wherein step S103 specifically comprises: instantiating all test items, image sequences, medication orders and previous medical history nodes involved in the current visit of the patient into a panoramic atlas, and representing the clinical correlation strength by the edge weight of the atlas; extending from the abnormality triggering time to the first symptom record and to the latest medical order, forming a time axis, and marking each data refresh or device state change on the axis. ​ ​ ​ The text course, numerical test, and image label three modal information are converted into a unified evidence vector, and a cross-modal joint representation is obtained by vector splicing; the cross-modal evidence vector splicing can be set as text vector T, numerical vector N, and image vector I, and the unified vector V=[T;N;I], and L2 norm normalization is adopted; The atlas node, time axis event, and cross-modal evidence vector are encapsulated into an event report with digital watermarking, and any subsequent modification can be traced.

5. The medical data anomaly analysis processing method according to claim 4, wherein the step of converting the text course, numerical test, and image label three modal information into a unified evidence vector comprises: For the text course, numerical test, and image label three types of data, respectively, a clinical knowledge driven extraction rule is used for key information extraction; By comparing the extracted key information, contradictory content is identified and corrected: Assigning a clinical relevance weight to the extracted features, the weight is adjusted according to the abnormal type; The fused feature vector is bound with the modal meta information to generate a cross-modal joint evidence vector with a version number, and the final output joint evidence vector is used for subsequent comparison and analysis with historical cases and medical guidelines.

6. The medical data anomaly analysis processing method according to claim 1, wherein the step S105 specifically comprises: The medical data analysis instruction package is split into one or more indivisible minimum operation units, each minimum operation unit corresponds to a single data field correction, single point calibration or single item review action, and is assigned a globally unique operation serial number; Before formal issuance, the minimum operation unit is sent to the digital twin which is in synchronization with the real device to execute and generate a rehearsal result, and only when the rehearsal is successful, the real device is allowed to issue; A rollback time window is set for each minimum operation unit, and if an abnormal rebound is monitored within the window, the original state of the device is immediately restored by triggering rollback, and the window length is adjusted according to the clinical scene; The minimum operation unit serial number, rehearsal result, actual execution result and timestamp are concatenated into an indivisible chain record, and are encrypted and stored in the medical quality control log to ensure that subsequent audits cannot be tampered with individually.

7. The medical data anomaly analysis processing method according to claim 6, wherein the step of sending the minimum operation unit to the digital twin which is in synchronization with the real device to execute and generate a rehearsal result before formal issuance specifically comprises: Based on the hardware specifications, software configuration and historical running log of the real device, a digital twin which is 1:1 mapped with the real device is constructed; The operation instruction of the minimum operation unit is converted into an execution instruction recognizable by the twin, and the adaptation content includes: converting the clinical instruction into a device control instruction; mapping the reference value range field to the test result storage module of the twin; verifying whether the correction operation needs to be completed before the device calibration; The twin is driven to execute the operation according to the instruction, and the state data and execution result in the execution process of the twin are synchronously collected, and the execution result is verified with the expected target; If the rehearsal fails, analyze the failure reason and adjust the twin or the operation instruction. The system is used to realize the medical data anomaly analysis processing method according to any one of claims 1 to 7; the system comprises: ​ ​ 8. A medical data anomaly resolution processing system characterized by comprising: ​ The data preprocessing module is configured to acquire medical raw data and preprocess the medical raw data. The abnormality preliminary screening module is configured to preset an abnormality detection rule, perform abnormality preliminary screening on the preprocessed medical data, mark a clinical abnormality type of the screened abnormal data, and store the abnormal data in a cache area according to a clinical scene priority. The event analysis module is configured to match historical cases for the abnormal data in the cache area, extract clinical context, device association information and time association information of the abnormal data, and output an abnormality analysis report. The instruction generation module is configured to generate a medical data analysis instruction package carrying an abnormality type, an event, a target system interface parameter and an execution time limit according to the abnormality analysis report. The instruction execution module is configured to perform data field value correction, calibration process and review of test results on the medical equipment based on the medical data analysis instruction package, record information of the instruction in a medical quality control log, and trigger abnormality escalation and generate a new instruction package if a new abnormality is detected during the execution. The reverse verification module is configured to generate a reverse verification instruction package when the same abnormality repeatedly occurs, send the reverse verification instruction package to a medical abnormality self-repair process, replay abnormal data flow in a sandbox, generate a reproduction result, compare the reproduction result with the original abnormality field by field, output a difference feature, update a medical knowledge base, a detection rule and an instruction template according to the difference feature, execute the updated instruction package, verify whether the abnormality is eliminated, and terminate if the test is passed.

9. A medical terminal comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, The processor executes the program to implement the steps of the medical data abnormality analysis processing method according to any one of claims 1 to 7.

10. A storage medium having stored thereon a computer program, characterized in that The computer program is executed by the processor to implement the steps of the medical data abnormality analysis processing method according to any one of claims 1 to 7.

Images