Edge computing data collaborative processing system based on medical internet of things

Abstract

The application discloses an edge computing data collaborative processing system based on a medical Internet of Things, a multi-source data acquisition unit, and a medical laboratory test scene. The multi-source data acquisition unit is used for accessing sample processing related equipment and information sources in the medical laboratory test scene, acquiring sample image information, sample loading information, label identification information, sample collection to detection time information, transportation temperature information, and centrifugal record information of a sample to be tested. The edge computing data collaborative processing system based on the medical Internet of Things performs project level coupling processing on sample state information, target test item requirements, and detection resource states on the edge side, forms a closed loop processing link from multi-source acquisition, feature extraction, template matching, project level detectability determination, collaborative action determination, task issuing and execution tracking to parameter updating, so that corresponding disposal results can be formed for different target test items corresponding to the same sample, and the project level disposal pertinence and execution traceability in the medical laboratory test process are improved.

Description

Technical Field

[0001] This invention relates to the field of edge computing technology, specifically to an edge computing data collaborative processing system based on the Internet of Things in healthcare. Background Technology

[0002] Medical testing laboratories are widely equipped with sample receiving equipment, barcode recognition equipment, pretreatment equipment, centrifugation equipment, automated production lines, analyzers, and laboratory information systems to complete processes such as sample receiving, sample identification, pretreatment, on-machine testing, and result feedback. Existing technologies fall into three categories: one focuses on identifying or detecting single information such as sample image, label status, sample volume, hemolysis / lipemia / jaundice interference, transportation status, or centrifugation status to determine if a sample is abnormal; another focuses on combining analyzer load, queuing status, and route planning for sample routing or testing task scheduling; and yet another focuses on digitally managing the rule parameters, sample quality requirements, turnaround time requirements, and environmental requirements of testing items. While these solutions can play a role in sample identification, process tracking, anomaly alerts, and equipment scheduling, most still revolve around the overall sample status, a single anomaly type, or a single scheduling objective, and are still unable to form a collaborative control mechanism oriented towards specific testing items.

[0003] For example, a digital management system and method for medical laboratory specimens, published in CN115101184A, includes functional modules such as a user center, material center, test item center, test request fulfillment center, search center, technical tool center, message center, report center, operation monitoring center, interconnection center, log center, and data service center. The method is based on specimen identification codes, managing specimens throughout the entire process before, during, and after testing. This decouples user identification from specimen identification, addressing the issues of fragmented user information across different application systems and the lack of independent specimen identification, hindering full lifecycle management. The document also explicitly states that information such as sampling tube type, sample quality, sample quantity, turnaround time at each stage, and environmental requirements are entered during the pre-processing of test items.

[0004] For example, patent document US20140129172A1 discloses a sample workflow management architecture for sample processing control in automated diagnostic laboratories. This architecture interacts with the laboratory information system, generating processing plans based on sample testing orders and considering analyzer status, reagent status, queue status, and sample preparation steps to select and schedule optimal processing routes for samples. Its key focus is integrating the sample preparation system, multiple analyzers, and transportation system into a unified process control framework to improve the overall processing efficiency and capacity of the laboratory. The document also explicitly mentions that the workflow management layer can generate processing plans containing multiple possible routes, and the process control layer then selects the optimal route from these possible routes for execution.

[0005] While existing laboratory automation systems can collect sample and equipment status information, this information is often scattered across different devices or business processes, lacking unified organization and correlation processing for testing projects. Especially at sample entry, pre-processing nodes, or analyzer access nodes, existing systems mainly focus on data reporting, anomaly alerts, or central-side summary analysis, lacking the ability to directly complete status analysis, project constraint matching, and action determination at the edge. As a result, when faced with situations such as insufficient sample volume, critical time limits, slight deviations in transportation conditions, insufficient centrifugation, increased interference, or main instrument congestion, laboratories still rely heavily on human experience to decide whether to continue testing, supplement pre-processing, switch analyzers, transfer to manual review, or return and re-collect samples, resulting in insufficient integrity of the automation chain. Summary of the Invention

[0006] The purpose of this invention is to provide an edge computing data collaborative processing system based on the Internet of Things in healthcare, in order to solve the problems mentioned in the background art.

[0007] To achieve the above objectives, the present invention provides the following technical solution: an edge computing data collaborative processing system based on the Internet of Things for Medical Applications, comprising: The multi-source data acquisition unit is used to access sample processing-related equipment and information sources in experimental medical testing scenarios to acquire sample image information, sample volume information, label identification information, sample collection to testing time information, transportation temperature information, centrifugation record information, sample interference information, target test item information, and candidate analyzer operating status information of the sample to be tested. An edge feature extraction unit is deployed at the laboratory sample entry node, preprocessing node, or analyzer access node to perform edge-side parsing on the multi-source data and extract sample state features. The project requires a template management unit to store sample requirement templates for different testing items. The project-level detectability determination unit is used to match the sample state characteristics with the sample requirement template of the corresponding test item, and generate project-level detectability determination results for different target test items of the same sample. The collaborative processing decision unit is used to generate collaborative processing actions that correspond one-to-one with each target test item based on the test item-level testability determination results, so that different test items corresponding to the same sample can enter different subsequent processing paths. The task assignment and execution tracking unit is used to assign the collaborative processing actions to the corresponding pre-processing equipment, analyzer, or manual review station, and to collect the execution results.

[0008] Preferably, the sample image information acquired by the multi-source data acquisition unit includes at least one or more of the following: test tube image, liquid level image, label image, and tube cap status image; and the acquired analyzer operating status information includes at least one or more of the following: analyzer load, queuing status, item coverage relationship, and standby instrument availability status.

[0009] Preferably, the sample state features extracted by the edge feature extraction unit include at least one or more of the following: liquid level height feature, sample volume distribution feature, label occlusion rate feature, label contamination rate feature, sample collection to detection time offset feature, transportation temperature deviation feature, centrifugation adequacy feature, sample interference intensity feature, and instrument waiting congestion feature.

[0010] Preferably, the project requirement template management unit establishes sample requirement templates for different inspection items. The sample requirement template includes at least sample type requirements, minimum filling quantity requirements, label identification reliability requirements, maximum acceptable duration requirements, transportation conditions requirements, centrifugation conditions requirements, acceptable interference range requirements, and instrument usage requirements. Furthermore, the sample requirement templates corresponding to different inspection items differ in at least one of the minimum filling quantity requirements, maximum acceptable duration requirements, acceptable interference range requirements, and instrument usage requirements.

[0011] Preferably, the project-level detectability determination unit is configured to output the detectability score or detectability level of the corresponding target test item based on the matching result of the sample state characteristics and the sample requirement template, and to output different detectability scores or detectability levels for different target test items of the same sample.

[0012] Preferably, the collaborative processing decision unit is configured to determine whether the current abnormal state is a recoverable abnormality or a rigidly rejected abnormality based on the detectability score or detectability level corresponding to the target inspection item, and generate a supplementary pre-processing and post-detection action when the abnormality is a recoverable abnormality, and generate a sample withdrawal and re-sampling action when the abnormality is a rigidly rejected abnormality.

[0013] Preferably, the collaborative processing decision unit is further configured to split and transfer the multiple target inspection items according to the detectability judgment results corresponding to each target inspection item when the same sample corresponds to multiple target inspection items, so that some target inspection items enter the direct detection path, and other target inspection items enter the supplementary preprocessing, analyzer switching, manual review or sample return and re-sampling path.

[0014] Preferably, the collaborative processing action includes at least one or more of the following: direct detection, supplementary pre-processing and post-detection, switching analyzer detection, transferring to manual review, and sample return and re-sampling. When generating the switching analyzer detection action, the collaborative processing decision unit is also used to combine the candidate analyzer operating status information and the instrument usage requirements of the corresponding test item to determine the alternative analyzer corresponding to the target test item.

[0015] Preferably, the execution results collected by the task issuance and execution tracking unit include at least one or more of the following: detection completion status, manual review conclusion, re-inspection status, sample return status, and abnormal reason label.

[0016] Preferably, the self-calibration update unit is used to update the project requirement template parameters according to the execution result. The project requirement template parameters include detectability judgment threshold, project rule parameters, anomaly judgment rule parameters, or instrument switching rule parameters.

[0017] Compared with existing technologies, the beneficial effects of this invention are as follows: This edge computing data collaborative processing system based on the Internet of Things in healthcare couples sample status information, target test item requirements, and test resource status at the edge, forming a closed-loop processing link from multi-source acquisition, feature extraction, template matching, test item detectability determination, collaborative action determination, task issuance and execution tracking to parameter updates. This enables the generation of corresponding treatment results for different target test items corresponding to the same sample, improving the targeting and traceability of test item-level treatment in the experimental medical testing process, as detailed below.

[0018] 1. Establish sample requirement templates for different target inspection items, and match sample status characteristics with corresponding templates. This allows the same sample to generate corresponding item-level inspectability judgment results when facing different inspection items. This avoids uniform processing based solely on the overall state of the sample and improves the correspondence between the judgment results and the specific inspection item requirements.

[0019] 2. Generate corresponding collaborative processing actions based on the project-level inspectability determination results, and send the collaborative processing actions to the pre-processing equipment, analyzer, or manual review station. This enables the project-level determination results to be connected with subsequent execution steps, which is beneficial to improving the coordination of the processing flow in the perimeter analysis stage.

[0020] 3. By collecting execution results, the template parameters for project requirements, the threshold for detectability, the parameters for anomaly judgment rules, or the parameters for instrument switching rules can be updated. This allows the subsequent processing of the system to be adjusted according to the actual execution situation, thereby improving the system's adaptability to the actual operating conditions of the laboratory. Attached Figure Description

[0021] Figure 1 This is a schematic diagram of the overall system structure of the present invention; Figure 2 This is a schematic diagram of the overall process of the method of the present invention; Figure 3 This is a flowchart of the S2 edge feature extraction sub-process of the present invention; Figure 4 This is a flowchart of the S3 to S4 project template matching and action determination sub-flowcharts of the present invention; Figure 5 The flowchart for S5 to S6 of this invention is a process flow chart of the execution tracking and self-correction sub-process. Detailed Implementation

[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 Figures 1-5 The present invention provides the following technical solution: This invention targets the experimental medical testing scenario, focusing on the coordinated handling of test samples in various stages, including receiving, pre-processing, pre-detection judgment, collaborative triage, manual review, and sample return and re-collection. Unlike solutions that only identify single-point anomalies in samples, this invention emphasizes the joint processing of sample images, loading volume, labels, transportation, centrifugation, interference status, target test requirements, and candidate analyzer status at edge nodes. This results in a project-level testability judgment for specific test items, and the judgment results drive subsequent collaborative actions, enabling different test items corresponding to the same sample to enter different subsequent processing paths.

[0024] It includes a multi-source data acquisition unit, an edge feature extraction unit, a project requirement template management unit, a project-level inspectability determination unit, a collaborative handling decision-making unit, a task issuance and execution tracking unit, and a self-correction update unit. Each unit can be implemented as an independent hardware node, edge service program, or software functional module, or it can be implemented in an integrated manner by one or more edge computing devices, servers, or workstations. The units interact with each other through the laboratory LAN, device communication bus, medical IoT access link, or message middleware.

[0025] 1. Multi-source data acquisition unit, used to access sample processing related equipment and information sources in experimental medical testing scenarios to obtain basic status data and resource status data of the sample to be tested.

[0026] The multi-source data acquisition unit can establish communication connections with sample container image acquisition equipment, label recognition equipment, transportation monitoring equipment, centrifugation equipment, interference detection equipment, analyzer status acquisition equipment, and laboratory information system to acquire sample image information, sample volume information, label recognition information, sample acquisition to testing time information, transportation temperature information, centrifugation record information, sample interference information, target test item information, and candidate analyzer operating status information. Among them, sample image information may include one or more of test tube images, liquid level images, label images, and tube cap status images; analyzer operating status information may include one or more of analyzer load, queuing status, item coverage relationship, and standby instrument availability status.

[0027] 2. Edge feature extraction unit, deployed at laboratory sample entry node, preprocessing node or analyzer access node, is used to perform edge-side parsing on the raw data obtained by the multi-source data acquisition unit to form sample state features that can be directly called for subsequent project-level judgment.

[0028] The edge feature extraction unit can perform liquid level recognition, test tube posture recognition, label occlusion recognition, label contamination recognition, and tube cap status recognition on sample images; it can perform sample acquisition to detection time offset calculation on time information; it can perform temperature deviation analysis on transportation temperature information; it can perform centrifugation adequacy analysis on centrifugation records; it can perform interference intensity grading on sample interference information; and it can also perform waiting congestion analysis on the operating status of candidate analyzers.

[0029] Therefore, the sample state features output by the edge feature extraction unit may include at least one or more of the following: liquid level height feature, sample volume distribution feature, label occlusion rate feature, label contamination rate feature, sample collection to detection time offset feature, transportation temperature deviation feature, centrifugation adequacy feature, sample interference intensity feature, and instrument waiting congestion feature.

[0030] 3. Project Requirements Template Management Unit, used to create, store and maintain sample requirement templates corresponding to different testing items.

[0031] The sample requirement template includes at least the following: sample type requirements, minimum filling quantity requirements, label identification reliability requirements, maximum acceptable duration requirements, transportation conditions requirements, centrifugation conditions requirements, acceptable interference range requirements, and instrument usage requirements. Furthermore, the sample requirement templates for different testing items differ in at least one of the minimum filling quantity requirements, maximum acceptable duration requirements, acceptable interference range requirements, and instrument usage requirements. In other words, this embodiment does not uniformly release or reject samples, but rather establishes corresponding project requirement templates based on the different sensitivities of different testing items to sample status.

[0032] 4. Project-level inspectability determination unit, which is used to match the sample state features output by the edge feature extraction unit with the corresponding test item template provided by the project requirement template management unit, and generate project-level inspectability determination results for different target test items of the same sample.

[0033] The testability determination result at the project level can be expressed as a testability score, testability grade, determination label, disposal priority, or a combination thereof. In the current preferred embodiment, the testability determination result at the project level preferably includes a testability score or a testability grade. With this setting, the same sample can obtain different determination results when facing different target test items, thereby providing a basis for subsequent splitting and transfer.

[0034] 5. Collaborative processing decision unit, used to generate collaborative processing actions corresponding to each target inspection item based on the project-level inspectability judgment results of each target inspection item.

[0035] In some embodiments, the collaborative processing actions include at least one or more of the following: direct detection, supplementary pre-processing followed by detection, switching analyzer for detection, transfer to manual review, and sample return and re-sampling. When the same sample corresponds to multiple target test items, the collaborative processing decision unit can split and transfer multiple target test items, so that some target test items enter the direct detection path, and other target test items enter the supplementary pre-processing, analyzer switching, manual review, or sample return and re-sampling path, thereby enabling differentiated collaborative processing of the same sample, different items, and different processing.

[0036] 6. Task Issuance and Execution Tracking Unit: This unit is used to issue collaborative processing actions output by the collaborative decision-making unit to the corresponding pre-processing equipment, analyzers, or manual review stations, and to collect and record the execution results of the actions.

[0037] The execution results may include at least one or more of the following: test completion status, manual review conclusion, re-inspection status, sample return status, and abnormality cause label. This unit ensures that the aforementioned project-level judgment results are truly transformed into executable equipment actions or manual workstation actions, and provides feedback data sources for subsequent parameter updates.

[0038] 7. Self-correcting update unit, used to update the project requirement template parameters based on the execution results collected by the task issuance and execution tracking unit.

[0039] The template parameters required for the project may include detectability threshold, project rule parameters, anomaly judgment rule parameters, or instrument switching rule parameters. By introducing a self-calibrating update unit, this embodiment can not only complete the project-level collaborative processing of the current sample, but also continuously revise the judgment rules based on historical execution results, thereby forming a closed-loop optimization mechanism that adapts to the actual operating conditions of the laboratory. 8. The collaborative relationship between modules: The multi-source data acquisition unit first accesses the data of samples and related equipment status entering the laboratory process; the edge feature extraction unit parses the raw data at the edge to obtain sample status features; the project requirement template management unit provides corresponding templates according to the target inspection items; the project-level inspectability determination unit generates determination results for each target inspection item based on this; the collaborative handling decision unit outputs actions such as direct detection, supplementary preprocessing, switching analyzers, manual review, or sample return and re-sampling based on the determination results; the task issuance and execution tracking unit is responsible for action execution and result collection; and the self-correction update unit updates relevant parameters based on the collection results, thus forming a complete and inseparable data processing and control link, so that the system does not stop at the level of anomaly reporting, but has the ability to make edge-side determinations and edge-side collaborative executions.

[0040] In this embodiment, the multi-source data acquisition unit, edge feature extraction unit, project requirement template management unit, project-level inspectability determination unit, collaborative handling decision-making unit, task issuance and execution tracking unit, and self-correction update unit are not independent functional stacks, but rather form a closed-loop collaborative relationship around the same processing main line. Specifically, this embodiment does not only perform anomaly identification or rule comparison on the sample as a whole, but forms project-level judgment results for different target inspection items corresponding to the same sample, and further generates collaborative processing actions corresponding to each target inspection item. Therefore, the technical essence of this embodiment does not lie in introducing sample image recognition, interference recognition, or project template input separately, but in performing project-level coupling processing on the edge side of the sample state, project requirements, and equipment execution conditions, and further forming a closed-loop control mechanism for project-level action determination, task execution, and result collection.

[0041] The specific steps are as follows: S1: Collect multi-source state data of the sample. Specifically, when the sample to be tested enters the laboratory receiving node, pre-processing node, or pre-detection node, the system accesses the sample processing related equipment and information sources through the medical Internet of Things, collects the multi-source state data corresponding to the sample to be tested, and sends the collection results to the edge feature extraction unit.

[0042] Data Sources: Sample image information comes from image acquisition devices located at the sample receiving station, the entrance to the transport track, or the entrance to the pre-processing equipment. These devices can acquire images of the overall appearance of the test tube, the liquid level, the label, and the tube cap status. Sample volume information can be provided directly from image measurement results, liquid level recognition results, or the volume detection device. Label recognition information can be provided by a barcode scanner, OCR module, or image recognition module, at least reflecting whether the barcode is readable, whether the label is complete, and whether there is any obstruction or damage. The time information from sample collection to detection can be obtained by combining the sample collection time, signing time, receiving time, pre-processing waiting time, and the current time. Transport temperature information can be obtained from the sample transport box temperature recorder, cold chain monitoring device, or temperature control tag. Centrifugation record information can be obtained from centrifugation equipment or pretreatment pipeline controller, including at least the number of centrifugations, centrifugation speed, centrifugation duration, and centrifugation completion time. Sample interference information can be obtained from interference detection modules such as hemolysis, lipemia, and jaundice, or the output results of the corresponding analyzers. Target test item information can be obtained from the test request form, task form, or sample-bound item list in the laboratory information system. Candidate analyzer operating status information can be obtained from the analyzer monitoring module or scheduling management platform, reflecting at least the current load, queuing status, item coverage relationship, and standby instrument availability of the candidate analyzers.

[0043] Data organization method: After the data collection is completed, the system uses the unique identifier of the sample as an index to bind the multi-source state data corresponding to the same sample, forming the original state dataset of the sample.

[0044] If a sample corresponds to multiple target inspection items, the system will bind the sample's unique identifier and further associate it with the list of target inspection items so that the subsequent item-level inspectability determination unit can process different target inspection items for the same sample separately. Through this organization, the output of S1 is not a discrete or isolated image result or monitoring result, but a unified input basis for subsequent item-level determination.

[0045] To improve the stability of subsequent edge resolution, stage S1 may also include one or more of the following preprocessing actions: Timestamp alignment for data uploaded from different devices; Mark missing fields as missing; Standardize and convert abnormal format data; Remove duplicate records of the same sample; Generate a reacquisition flag for images or temperature records that failed to be acquired.

[0046] For example, in a preferred embodiment, the laboratory receives a blood sample corresponding to liver function, electrolyte, and immune tests. During stage S1, the system collects the following data: the test tube label is partially damaged but the barcode is readable; the sample volume is lower than the usual empirical value but not below the minimum imaging recognition liquid level; the time from sampling to laboratory reception is excessive; the transport temperature record shows a slight deviation from the limit; the centrifugation record shows one insufficient centrifugation; interference detection results show a slightly elevated hemolysis index; the current biochemical analyzer has a long queue while the backup analyzer is idle.

[0047] In this embodiment, the aforementioned data is uniformly bound to the unique identifier of the sample and its corresponding item list in stage S1, serving as the input basis for subsequent edge feature extraction in S2 and item-level template matching in S3. In this way, instead of giving a single conclusion for the sample as a whole, it is possible to make differentiated judgments for liver function items, electrolyte items, and immune items separately. S2: Extracting sample state features at edge nodes. Specifically, after receiving the multi-source state data output by S1, the edge feature extraction unit uses the sample's unique identifier as the primary index and the target test item list as the association index to structurally reorganize the sample image information, sample quantity information, label recognition information, sample collection to testing time information, transportation temperature information, centrifugation record information, sample interference information, and candidate analyzer operating status information corresponding to the same sample, forming an edge input dataset oriented towards sample-item object pairs. During the formation of the edge input dataset, timestamp alignment, field name standardization, missing field marking, and duplicate data can also be performed on data uploaded from different devices. The system records deduplication and abnormal format correction to ensure that data from different devices and information sources can be uniformly parsed at the edge nodes. Based on this, the edge feature extraction unit further performs local calculations and state mapping on the edge input dataset, extracting one or more of the following features: liquid level height, sample volume distribution, label occlusion rate, label contamination rate, sample collection to detection time offset, transportation temperature deviation, centrifugation adequacy, sample interference intensity, and instrument waiting congestion. The extracted sample state features are then sent to the project-level inspectability determination unit as direct input for subsequent sample requirement template matching and project-level inspectability determination.

[0048] In a preferred embodiment, after receiving multiple target inspection items corresponding to the same sample, the edge feature extraction unit does not extract a single conclusion for the entire sample. Instead, it extracts state features related to the judgment of each target inspection item. That is, for items A, B, and C corresponding to the same sample, the edge feature extraction unit can extract different sets of item-related features based on the same original data. The reason for this is that different inspection items have different sensitivities to loading volume, timeliness, transportation conditions, centrifugation conditions, interference levels, and instrument compatibility. Therefore, the feature results output by the edge nodes should not be uniform, but should be differentiated feature results for specific items. Through the above data recombination, preprocessing, and item-related extraction, this step can transform the discrete information originally scattered in images, time, temperature control, centrifugation, interference, and equipment status into structured inputs that can be directly used in the subsequent item-level inspectability judgment. This avoids the system only staying at the level of anomaly reporting and provides a project-specific computational basis for subsequent collaborative processing.

[0049] Furthermore, in some embodiments, the edge feature extraction unit may first extract sample quantity sufficiency features based on sample quantity information and the minimum quantity requirement of the corresponding item. The sample quantity sufficiency features can be expressed as follows: , of which Indicates that the sample is for The adequacy characteristic value of the loading quantity of each target inspection item This represents the actual usable sample volume of the current sample. Indicates the first The minimum required sample volume for each target test item, when When the quantity is less than the preset threshold, it indicates that the current sample is at risk of insufficient quantity for the corresponding target test item. When the sample reaches or exceeds the preset fill volume threshold, it indicates that the current sample meets the basic requirements of the corresponding target test item in terms of fill volume. The fill volume threshold can then be further set. and fill volume critical threshold In the embodiments, it is possible to take =1.00, =0.90, when ≥ The filling volume was determined to be sufficient. < This is clearly insufficient, when ≤ < When this occurs, it is determined that the fill volume is critically insufficient.

[0050] Furthermore, the edge feature extraction unit can extract the sample acquisition to detection time offset feature based on the sample acquisition time and the current processing time, combined with the longest acceptable duration requirement of the corresponding project. The sample acquisition to detection time offset feature can be expressed as: , Indicates the sample is for the first The time offset characteristic value of each target test item. This indicates the current time when the edge node is performing feature extraction. This indicates the time when the sample was collected. Indicates the first The maximum allowable collection to testing time for each target testing item, when As the value gradually increases, it indicates that the urgency of the sample in terms of timeliness is gradually increasing. When the time exceeds the preset time threshold, it indicates that the sample has approached or exceeded the allowable time limit for the corresponding target test item, and a further time warning threshold can be set. and time limit threshold In the embodiments, it is possible to take =0.80, =1.00, when ≥ The timeliness was deemed normal. < Then it is determined that the time limit has been exceeded. < ≤ When it is determined to be at the critical point of expiration, Furthermore, the edge feature extraction unit can extract transportation temperature deviation features based on transportation temperature records and the temperature control requirements of the corresponding project. The transportation temperature deviation features can be represented as: , Indicates the sample is for the first The transport temperature deviation of each target inspection item from the characteristic value This indicates that the sample is facing the first... When inspecting a target item, the cumulative time during transportation exceeding the allowable temperature range for that item is considered. Show the first The cumulative duration of temperature exceedance allowed for each target inspection item. When the value is small, it indicates that the temperature control conditions during transportation have a weaker impact on the corresponding target inspection items; when When the temperature increases and approaches or exceeds the preset temperature control threshold, it indicates that the sample has generated a temperature control deviation risk related to the corresponding target inspection item during transportation, and a further temperature control warning threshold can be set. and temperature control over-limit threshold In a preferred embodiment, it is possible to =0.5, =1.0, when ≤ At that time, it was determined that the temperature control deviation was low. > At that time, it was determined that the temperature control deviation was high. When it falls between the two, the degree of deviation is moderate.

[0051] Furthermore, the edge feature extraction unit can extract centrifugation adequacy features based on centrifugation record information and the centrifugation condition requirements of the corresponding project. Centrifugation adequacy features can be represented as: Indicates the sample is for the first The centrifugation adequacy characteristic value of each target test item This indicates the actual number of centrifugations completed for the current sample. Indicates the first The number of centrifugation cycles required for each target test item. This indicates the current actual centrifugation speed of the sample. Indicates the first The centrifugation speed required for each target inspection item. This indicates the actual duration of centrifugation of the current sample. Indicates the first The centrifugation duration required for each target test item is determined by the following principle: if any critical condition—the number of centrifugations, the centrifugation speed, or the centrifugation duration—is insufficient, the centrifugation adequacy characteristic value for the corresponding target test item will be lowered. This ensures that subsequent judgments better align with the actual constraints of pretreatment in laboratory medicine. A centrifugation threshold can be further set. and centrifugation critical threshold In a preferred embodiment, it is possible to =1.00, =0.85, when centrifugation adequacy characteristic Not less than Centrifugation should be thorough and less than 100°C. If it is clearly insufficient, then it is considered critically insufficient if it is between the two.

[0052] Furthermore, the edge feature extraction unit can extract sample interference intensity features based on sample interference information. For blood samples, the interference indices corresponding to hemolysis, lipemia, and jaundice can be jointly mapped to interference intensity features specific to the target. The interference intensity features can be expressed as: , Indicates the sample is for the first The interference intensity characteristic value of each target test item This indicates the hemolysis interference index of the current sample. This indicates the lipid interference index of the current sample. This indicates the jaundice interference index of the current sample. Indicates the first The sensitivity coefficient of each target test item to hemolytic interference. Indicates the first The sensitivity coefficient of each target test item to the interference of lipid levels. Indicates the first The sensitivity coefficient of each target test item to interference from jaundice varies because different test items have different sensitivities to hemolysis, lipemia, and jaundice. , and The interference intensity characteristics output by edge nodes can vary depending on the target test item. Therefore, the interference intensity characteristics are not a uniform interference conclusion for all samples, but rather a differentiated interference characterization result for specific items. To give the judgment of high interference and low interference clear boundaries, interference warning thresholds can be further set. and interference rejection threshold In a preferred embodiment, it can be , , Pre-normalized to the interval between 0 and 1, we can take... =0.30, =0.70, when Not greater than Low time interference, greater than If the interference level is high, then the interference level is high; if it is in between, then the interference level is moderate.

[0053] Furthermore, the edge feature extraction unit can also combine candidate analyzer operating status information to extract instrument waiting congestion features, reflecting the waiting pressure if the current sample is assigned to a candidate analyzer. The instrument waiting congestion features can be expressed as: , Indicates the first Each target test item in the candidate analyzer The waiting congestion characteristic value on the above, Indicates candidate analyzer The current predicted waiting time, Indicates the first The maximum allowable waiting time for each target inspection item. Indicates candidate analyzer Current queued task volume Indicates candidate analyzer By extracting this feature, edge nodes can not only determine the state of the sample itself, but also reflect in advance whether the item is suitable to continue waiting on the current analyzer, thus providing a data basis for subsequent analyzer switching actions. Furthermore, an acceptable congestion threshold can be set. And a high-risk congestion threshold, in a preferred embodiment, may be taken as follows: =1.00, =1.50, Not greater than The time-based judgment is that the waiting congestion level is low or greater than If the level is high or low, the congestion level is low; if it is in between, the congestion level is moderate.

[0054] The edge feature extraction unit does not require all features to be extracted for each sample. Instead, it can adaptively select corresponding features for extraction based on the sample type, the type of target test item, the type of connected equipment, and the current data completeness. For example, for scenarios where no transport temperature recording equipment is connected, the transport temperature deviation feature can be marked as missing. For items that do not require pre-centrifugation processing, the participation of centrifugation adequacy features in subsequent judgments can be reduced. For sample types that do not involve HIL interference, the corresponding interference intensity feature can be disabled. This improves the applicability of the system under different laboratory configuration conditions without disrupting the overall main chain of the invention.

[0055] Furthermore, the output of this step can be organized into a set of item-related features for each target test item. For example, for the nth target test item corresponding to the same sample, a set containing... , , , , , One or more feature sets in the sample; for another target test item, due to its different minimum loading requirements, maximum acceptable duration requirements, acceptable interference range requirements and instrument usage requirements, the corresponding feature sets and their values ​​may also be different. In this way, S2 outputs the feature results oriented towards sample-item object pairs, rather than a single anomaly label oriented towards the sample as a whole.

[0056] Through the above methods, in S2, the edge nodes complete the structured organization and preprocessing of multi-source data for the same sample, enabling data from different sources, formats, and time granularities to be uniformly incorporated into the subsequent judgment process. On the other hand, by extracting features such as loading volume, timeliness, temperature control, centrifugation, interference, and instrument congestion, the original monitoring information is transformed into state features that can be directly involved in project-level inspectability judgment. Thus, this invention not only achieves data cleaning and state analysis on the edge side, but also further forms differentiated feature expressions for specific inspection projects, providing a calculable, comparable, and traceable input basis for project requirement template matching and project-level inspectability judgment in the subsequent S3.

[0057] It should be noted that the liquid level height feature, sample volume distribution feature, label occlusion rate feature, label contamination rate feature, sample interference intensity feature, and other state features extracted in S2 are not limited to a single algorithm. These features can be obtained by edge nodes parsing the input sample images, device-recorded data, and detection results. The focus of this invention is to organize these state features into a unified set of project-related features that can be directly invoked for subsequent project-level detectability determination, thereby driving subsequent project-level template matching and collaborative processing actions. Therefore, this invention does not require a specific image recognition algorithm, occlusion compensation algorithm, or interference recognition algorithm as a necessary limitation, but allows any implementation method that can obtain the corresponding state features. This setting allows the protection focus of this invention to concentrate on the project-level determination and collaborative processing closed loop, rather than on a specific feature extraction algorithm itself.

[0058] S3: Construct project requirement templates and perform matching. Specifically, after receiving the set of project association features for sample-project object pairs output by S2, the project requirement template management unit calls the sample requirement templates that correspond one-to-one with each target inspection item according to the target inspection item list, and matches the set of project association features with the sample requirement templates item by item at the edge nodes to form project constraint compliance results for each target inspection item.

[0059] The sample requirement template includes at least the following: sample type requirements, minimum fill quantity requirements, label identification reliability requirements, maximum acceptable duration requirements, transportation conditions requirements, centrifugation conditions requirements, acceptable interference range requirements, and instrument usage requirements. For different target test items corresponding to the same sample, the system does not use a unified template but instead calls different item templates. Therefore, the same sample in S3 is organized into multiple independent sample-item-template matching units to output matching results for different target test items. To ensure consistency in the matching process, before executing the template call, the system can also uniformly verify the template field name, template version number, threshold unit, and item code. If a template is found to be missing, has a field conflict, or has an inconsistent threshold unit, a template correction flag is generated or the default template rule is called, thus avoiding subsequent judgment deviations due to inconsistent template structures. In this way, S3 does not simply match a sample to a unified rule set for overall judgment but splits the same sample into multiple item templates for comparison, forming truly differentiated matching results tailored to specific test items.

[0060] In a preferred embodiment, template matching in S3 can be divided into two layers of logic. The first layer is rigid constraint matching, which prioritizes determining whether the current sample meets the non-release condition of a certain target test item. The second layer is general constraint matching, which, under the premise that the non-release condition is not met, comprehensively determines the compliance of features such as loading quantity, timeliness, transportation, centrifugation, interference, and instrument compatibility.

[0061] Rigid constraint matching primarily targets constraints that cannot be recovered through supplementary preprocessing or waiting once they are not met. Examples include incorrect sample type, unrecognizable barcode that cannot be added, sample volume significantly lower than the project's minimum requirement, project requirements necessitating transportation under specific temperature control conditions that are currently severely exceeded, or no available analyzer covering the target project. General constraint matching, on the other hand, targets constraints that can be remedied through re-centrifugation, machine replacement, manual verification, or priority queueing. Examples include insufficient fill volume, collection-to-detection time approaching the upper limit, slight deviation in transportation temperature, insufficient centrifugation degree, interference in the medium-risk range, or high congestion on the current main instrument. By splitting template matching into the above two layers of logic, the matching results output by S3 can reflect not only compliance but also whether the non-compliance is recoverable, thus directly supporting the distinction between recoverable anomalies and rigid rejection anomalies in S4.

[0062] Furthermore, the system can target the first The project constraint compliance of the target inspection project. This characterizes the degree to which the current sample meets the general constraints of the target test item without triggering a rigid veto. The item constraint compliance can be expressed as: , Indicates the first The number of feature terms involved in the general constraint matching for each target test item. Indicates the first The first target inspection item Matching weights corresponding to each feature term Indicates the current sample is at the th . The first target inspection item The constraint compliance values ​​on each feature term include one or more of the following: adequacy of fill volume, time offset, transport temperature deviation, adequacy of centrifugation, interference intensity, label identification reliability, and candidate analyzer compatibility; matching weights. The sensitivity of different feature items to the corresponding target test items is pre-configured in the project requirement template; constraint compliance values The values ​​can then be assigned based on the range to which the feature values ​​output in S2 belong. For example, when a feature is in the satisfied range, the corresponding constraint compliance value can be a higher value; when a feature is in the warning range, the corresponding constraint compliance value can be a middle value; when a feature is in the range that is clearly not satisfied but can still be recovered, the corresponding constraint compliance value can be a lower value. The actual reflection is that the sample is facing the first When inspecting individual target items, the overall degree of matching with general constraints.

[0063] To prevent general constraint compliance from masking cases of rigidity non-compliance, the system can also construct a rigid rejection flag for the nth target inspection item. This is used to indicate whether the current sample meets the non-acceptance condition of the target test item. A rigid rejection flag can be represented as: Indicates the first Does the sample type corresponding to each target test item trigger a rigid veto? These respectively indicate whether sample identification triggers a rigid veto, whether sample quantity triggers a rigid veto, whether transportation conditions trigger a rigid veto, and whether instrument coverage relationship triggers a rigid veto. All can be binary variables, where a value of 1 indicates that the corresponding rigid condition is triggered, and a value of 0 indicates that the corresponding rigid condition is not triggered. Thus, if any of the listed rigid conditions is triggered, then... A value of 1 indicates that the current sample is for the th . Individual inspection items should not be directly entered into the general release or remedial judgment process, but should instead enter the rigid veto branch.

[0064] Based on the above two-layer matching logic, the system can perform template matching in the following manner: First, call the... The sample requirement templates corresponding to each target test item are retrieved, and the template parameters concerning sample type, label recognition reliability, minimum filling quantity, maximum acceptable duration, transportation conditions, centrifugation conditions, interference threshold, recommended analyzer, and alternative analyzer are read. Subsequently, the set of project-related features output by S2 is compared item by item with the template parameters, and constraint compliance values ​​are generated for each feature item. And the rigid trigger flags corresponding to each rigid condition; If the sample type is found to be inconsistent with the project template requirements, the identity cannot be confirmed, the sample volume is lower than the project's rigid lower limit, the transportation conditions exceed the project's rejection limit, or the current laboratory does not have an analyzer that can cover the project, then the corresponding rigid trigger flag will be set to the triggered state, and the following will be obtained: =1; If a rigid veto is not triggered, the project constraint compliance degree is calculated based on the matching results of general constraints such as loading quantity, timeliness, transportation, centrifugation, interference, and instrument compatibility. This forms the input basis for subsequent project-level inspectability determinations.

[0065] The key here is not in a general comparison of sizes, but in the fact that the composition of rigid constraints, general constraints, and their corresponding weights can all differ when the same sample faces different project templates. Therefore, the template matching results for the same sample for different target test items can also be different. For example, for electrolyte items, the hemolysis sensitivity in the sample interference items can be higher than the transport time sensitivity; while for some immunological items, the importance of transport conditions and timeliness constraints can be higher than the centrifugation adequacy constraint. Through this differentiated matching method of project templates, this invention can truly transform the project association features extracted in S2 into subsequent decision-making project-level matching results, rather than remaining at a general judgment under a unified rule.

[0066] Furthermore, the system can also be based on and Forming project matching status labels, specifically, when When =1, the first one can be directly... Each target test item is marked as rigid mismatch; when =0 and When the value exceeds the release matching threshold in the corresponding project template, the target inspection item can be marked as a good match; when =0 and When the target is within the warning matching range, the test item can be marked as the matching threshold; when =0 and When the target inspection item is below the warning matching range but still above the remedial lower limit, it can be marked as a recoverable mismatch. In this embodiment, the release matching threshold, warning matching range, and remedial lower limit can all be preset in the corresponding item requirement template. The thresholds for different inspection items can be different. Since these thresholds are relatively conventional range judgment parameters and are mainly used to support the action mapping in S4, no separate formula is introduced in this embodiment.

[0067] S3 can also organize edge-side results for template matching. Specifically, the system can output a set of project-level matching results based on the unique identifier of the sample. This set of results includes at least the target test item number, the corresponding project template version number, the rigid rejection mark, the project constraint compliance, the matching status label, and the corresponding main mismatch source. The main mismatch source can be directly determined based on the feature item with the lowest constraint compliance value or the triggered rigid condition. For example, it can be marked as insufficient loading, transportation exceeding limits, insufficient centrifugation, high interference, main instrument congestion but alternative or no available instrument coverage, etc. The significance of this result organization method is that S3 outputs not a single abstract score, but can simultaneously provide the project matching result and its source explanation, which facilitates S4 to further map the states such as good matching, critical matching, recoverable mismatch, and rigid mismatch to collaborative processing actions such as direct detection, supplementary preprocessing, switching analyzers, manual review, or sample return and resampling.

[0068] For example, in one embodiment, a blood sample corresponds to liver function, electrolyte, and immune tests. S2 has already extracted the following: the sample volume is slightly low, the time taken is relatively long, the transport temperature is slightly out of range, the centrifugation was insufficient (one centrifugation was not performed), the hemolysis index is slightly elevated, and the main biochemical analyzer is in a long queue while the standby analyzer is idle.

[0069] In S3, the system calls the liver function test template, electrolyte test template and immune test template respectively for matching. For the electrolyte test, since its test template allows a certain degree of slight transport deviation and fill volume critical state, and the backup instrument can cover the test, it does not trigger rigid rejection. At the same time, the general constraint compliance is high, which can form a good match or a critical match state.

[0070] For liver function tests, since they have high requirements for the adequacy of centrifugation, and the current sample has insufficient centrifugation, although a rigid rejection was not triggered, the compliance with general constraints decreased, which could lead to a recoverable mismatch. For immunization projects, since their templates are more sensitive to the combined effects of timeliness and interference, if the current timeliness offset and interference intensity both fall below the warning range of the project template, a recoverable mismatch or even a rigid mismatch state can be formed. In this way, the same sample can output three different project-level matching results in S3, providing a direct basis for the subsequent sub-project collaborative handling in S4.

[0071] Through the above methods, in S3, the system completes the project-level differentiated matching between the output features of S2 and the project requirement template, enabling the same sample to form different matching conclusions under different project templates. On the other hand, through a two-layer structure of rigid constraint priority judgment + general constraint compliance calculation, the simple feature extraction results are further transformed into matching status results that can directly support subsequent action decisions. Thus, this embodiment does not only realize the conventional comparison between feature values ​​and thresholds, but also establishes a templated constraint mapping mechanism for specific inspection projects at the edge, so that a computable, traceable, and interpretable project-level correlation is formed between the sample status, project requirements, and detection resource status, providing a clear, stable, and project-specific judgment basis for the generation of collaborative handling actions in S4.

[0072] It should be further clarified that the project requirement template in this invention is not merely used for statically storing sample requirement information corresponding to inspection items, nor is it simply a rule library for inputting pass / fail data. Rather, it exists as a control interface connecting project constraint matching results with subsequent collaborative handling actions. In other words, the project requirement template in this invention not only serves to parameterize sample type, quantity, timeliness, transportation, centrifugation, interference, and instrument usage requirements, but also transforms these requirements into calculable project-level matching boundaries, rigid rejection conditions, recoverable conditions, and action mapping bases. When the same sample corresponds to different target inspection items, the system independently calls different project templates to complete the matching, and the resulting matching states are independent of each other and do not overlap due to the overall sample being uniformly approved or rejected. Therefore, the project requirement template in this invention is not simply an information input unit, but a constraint carrier and action interface for project-level collaborative control.

[0073] S4: Generate project-level inspectability determination results and map collaborative processing actions. Specifically, after receiving the project-level matching result set output by S3, the project-level inspectability determination unit establishes project-level determination objects for each target inspection item corresponding to the same sample, using the sample's unique identifier as the primary index and the target inspection item number as the sub-index. It also reads the rigid rejection flag, project constraint compliance, main mismatch sources, candidate analyzer coverage relationship, and remedial processing path information corresponding to each project-level determination object. Before generating the project-level inspectability determination results, the system can also perform consistency checks on the above input results. Preprocessing includes verifying the template version number, normalizing the mismatch source labels, deduplicating duplicate candidate paths for the same project, and generating evidence conflict markers for conflicting result items. Subsequently, the project-level inspectability determination unit generates project-level inspectability determination results for each target inspection item at the edge node based on the rigid rejection status, general constraint matching degree, and remedial accessibility. The project-level inspectability determination results are then mapped to one of the following collaborative processing actions or a set of preferred actions: direct detection, supplementary preprocessing and post-detection, switching analyzer detection, manual review, or sample return and resampling.

[0074] In this way, the output of S4 is no longer a simple feature value or template matching value, but a project-level judgment result and action mapping result that can directly drive the subsequent processing, so that different test items corresponding to the same sample enter different subsequent processing paths.

[0075] The decision logic in S4 can still be divided into two layers. The first layer is the rigid rejection priority decision logic, that is, if a target inspection item has already formed a rigid rejection mark in S3, the target inspection item will be given priority to enter the sample return and re-sampling or manual review and confirmation branch, and will no longer participate in the general release decision. The second layer is the recoverability decision logic, that is, when a target inspection item has not triggered a rigid rejection, the system further determines whether its current mismatch status can be recovered by supplementing preprocessing, switching analyzers or manual review, and maps actions between direct detection, remedial post-detection and manual review accordingly.

[0076] The aforementioned "recoverable" is not an abstract concept, but rather requires that the current project meet at least one of the following conditions: the existence of an executable supplementary pretreatment path, the existence of an alternative analyzer that meets the project template requirements, or the existence of an acceptable manual review and release path. If none of the above paths exist, even if a project does not trigger a rigid veto, it can still be judged as unsuitable for continued automatic processing due to the lack of an effective remedial channel. A recoverable anomaly refers to a situation where the sample status corresponding to the current target testing project, although not meeting the conditions for direct detection, still has an executable remedial path, thus allowing for continued testing after remediation. Typical scenarios for recoverable anomalies include: centrifugation at a critically insufficient level but allowing for re-centrifugation; main analyzer congestion but the existence of an alternative analyzer that meets the project requirements; slight deviations in transportation conditions but still within the remedial range set by the template; or partial conflicts in evidence that can be further confirmed through manual review. A rigid veto anomaly refers to a situation where the current target testing project has reached the boundary conditions for unsuitable continued automatic processing, and no acceptable remedial path exists. Typical scenarios for rigid rejection anomalies may include: sample type not matching the target test requirements, sample identity unable to be confirmed or barcode information unable to be reliably linked, sample quantity below the project's rigid lower limit, transportation or timeliness conditions exceeding the project's rejection boundary, or the current laboratory lacking an available analyzer capable of covering the target test. By distinguishing between these two types of anomalies, this invention can further transform the project template matching results into executable collaborative processing logic, thereby supporting differentiated mapping of actions such as direct detection, supplementary pretreatment, analyzer switching, manual verification, and sample return and resampling.

[0077] Furthermore, to reflect the remedialability of the current abnormal state of a certain target inspection item, the system can construct the first... Remediation Availability of Each Target Inspection Item , can be represented as ,in Indicates the first The supplementary preprocessing path weights corresponding to each target inspection item Indicates the first The switching analyzer path weights corresponding to each target inspection item. Indicates the first The weight of the manual review path corresponding to each target inspection item Indicates the first Does each target test item meet the conditions for supplementary preprocessing? Indicates the first Does each target test item meet the conditions for switching to an alternative analyzer? Indicates the first In a preferred embodiment, to determine whether each target inspection item is feasible for manual review,... , and It can be a binary variable, where a value of 1 indicates that the corresponding remediation path is executable, and a value of 0 indicates that the corresponding remediation path is not executable. , and It can be preset in the project requirement template corresponding to the target inspection item, and must meet the requirement that the sum is 1 or be normalized.

[0078] For example, for projects with insufficient centrifugation but still sufficient sample volume, the supplementary pretreatment path can be given a higher weight; for projects with main analyzer congestion but backup analyzers meeting project coverage and timeliness requirements, the analyzer switching path can be given a higher weight; for projects with conflicting evidence but not triggering a rigid veto, the manual review path can be given a higher weight. Therefore, It not only reflects whether it can be remedied, but also which type of remedial approach is more suitable.

[0079] Furthermore, the system can use the rigid veto flag obtained in S3. Project constraint compliance and the availability of remedies , construct the first Project-level inspectability criteria for each target inspection item , and These represent the weights for determining the project's compliance with constraints and the weights for determining the accessibility of remediation, respectively. and This can be preset in the corresponding project requirement template, and the sum of the two is 1 or after normalization processing. Through this setting, when When =1, The value drops directly to 0, indicating that the target test item has reached the rigid veto condition; when =0, This simultaneously reflects the general degree of matching and the degree of remediation of the current sample for the target test item. Therefore, S4 is not just a simple restatement of the results of S3, but integrates whether it is rigidly rejected, the degree of matching, and whether it can be remedied into a unified project-level judgment basis at the edge.

[0080] The project-level inspectability determination unit can be based on In addition, the project template contains preset action mapping thresholds, which generate project-level inspectability judgment results for the target inspection project. Specifically, direct detection thresholds can be preset in the project template. That is, the minimum judgment threshold and the remedial release threshold for the target inspection item that are allowed to be directly detected. That is, the minimum judgment threshold and the manual review threshold for the target inspection item to be allowed to enter the remedial testing branch. That is, the minimum judgment threshold for the target inspection item to enter the manual review branch, and the lower limit of remedies that can be achieved. That is, the minimum reachability threshold for identifying a target test item as having an effective remediation path. In the embodiment, it can be taken as... =0.85, =0.60, =0.40, =0.50, different values ​​can be used for different target inspection items; Based on the above thresholds, in some embodiments, project-level inspectability determination results can be generated and collaborative processing actions mapped according to the following rules: when When =1, a rigid rejection decision result is directly generated and prioritized as a sample rejection and re-sampling action; if the project template allows rigid anomalies to enter the final manual confirmation process, it can be mapped to manual review to decide whether to reject and re-sampling. when =0 and ≥ At that time, a directly detectable judgment result is generated and mapped to a direct detection action; when =0 and ≤ < ,and ≥ At that time, a recoverable anomaly determination result is generated, and further priority mapping is performed between the supplementary preprocessing post-detection action and the switching analyzer detection action based on the executable path with the highest remedial path weight; when =0、 ≤ < When this happens, a result requiring manual review is generated and mapped to a "transfer to manual review" action; when =0、 < At that time, if If so, a decision result indicating that automatic processing should not continue is generated and mapped to a desampling and resampling action; if If there are evidence conflict markers, then manual review will be prioritized.

[0081] Furthermore, after the system generates a recoverable anomaly determination result, it does not immediately send all items to the same remedial action. Instead, it further refines the action mapping rules based on the mismatch source label and the executableness of the remedial path. For example, when the main mismatch source is insufficient centrifugation, and When =1, it can be preferentially mapped to supplementary preprocessing and post-detection actions; when the main mismatch source is master instrument congestion, and the current candidate alternative analyzer meets the project coverage relationship and When =1, it can be preferentially mapped to the switching analyzer detection action; when the main source of mismatch is tag occlusion, mild interference superimposed on the time limit, or there is a conflict between multiple sources of evidence, but When =1, it can be preferentially mapped to the action of transferring to manual review. The action subdivision formula is not introduced separately here because the above action selection is essentially based on the established project-level inspectability judgment results, and is mapped according to the priority of the mismatch source and remedial path execution rules. It is a relatively conventional process decision.

[0082] S4 can also organize edge-side results for project-level detectability determination results. Specifically, the system can output a set of project-level determination results for the same sample. The result set includes at least the target inspection item number, the project-level detectability determination value, the determination result label, the priority collaborative processing action, the alternative collaborative processing action, and the main basis for triggering the determination result. The main basis may include one or more of the following: rigid rejection source, the lowest constraint compliance item, the path with the highest remedy reachability, and evidence conflict marker. With this result organization method, S5 can directly read the priority action and alternative action of each target inspection item when issuing tasks, without having to recalculate the aforementioned features or templates item by item, thereby improving the efficiency of edge-side action issuance.

[0083] For example, a blood sample corresponds to liver function tests, electrolyte tests, and immune tests. The S3 output results show that for the electrolyte test, no rigid rejection was triggered, the test constraint compliance is high, and the backup instrument is available. Therefore... =0 and It is also relatively high, corresponding to It can reach or exceed the direct detection threshold or the remedial release threshold, thereby generating item-level detectability judgment results that can be directly detected or detected after switching analyzers; For liver function tests, no rigid rejection was triggered, but centrifugation was insufficient, and the supplementary pretreatment pathway was executable. =0 Decline Keep it high It can fall into the recoverable abnormal range, thereby generating a project-level detectability determination result for supplementary pre-processing and post-detection. For immunization projects, if the current project template is more sensitive to timeliness and interference, and a manual review pathway is available, then It may still be 0, but Low Take the median value, the corresponding It may fall into the manual review range, thus generating a project-level inspectability judgment result that is transferred to manual review. In this way, the same sample can be mapped into multiple different project-level judgment results and their corresponding collaborative actions in S4, providing direct input for the subsequent sub-project task distribution in S5.

[0084] Through the above methods, in S4, the system, on the one hand, forms a project-level detectability judgment value for specific testing items based on the output results of S3, so that rigid rejection, general matching degree, and remedial accessibility can be uniformly expressed under the same judgment framework. On the other hand, it establishes a clear mapping relationship between the project-level judgment results and collaborative processing actions such as direct detection, supplementary pre-processing and post-detection, switching analyzer detection, manual review, and sample return and re-sampling. Thus, this invention does not only complete project template matching at the edge, but further transforms the matching results into directly executable project-level disposal decisions, thereby enabling edge nodes to truly possess project-level collaborative decision-making capabilities for experimental medical testing processes, and providing stable, interpretable, and traceable action basis for task issuance and execution tracking in the subsequent S5.

[0085] S5: Issue collaborative processing actions and execute tracking. Specifically, after receiving the project-level judgment result set output by S4, the task issuance and execution tracking unit uses the sample's unique identifier as the primary index and the target inspection item number as the sub-index to read the priority collaborative processing actions, alternative collaborative processing actions, main basis, target equipment information, and execution preconditions for each target inspection item corresponding to the same sample. At the edge node, the project-level judgment results are reorganized into an executable task set. During the formation of the executable task set, the system can also perform action conflict checks, equipment occupancy checks, precondition checks, and duplicate task deduplication for multiple target inspection items under the same sample. To avoid duplicate issuance of the same target inspection item or conflicting execution paths for multiple actions on the same sample, the task issuance and execution tracking unit further issues the executable task set to the corresponding pre-processing equipment, analyzer, or manual review station, and continuously tracks the execution status of each task until an execution result record corresponding to each target inspection item is formed. In this way, the output of S5 is no longer a suggestion at the judgment level, but a control task that can truly enter the laboratory execution chain, thus transforming the project-level inspectability judgment result generated by S4 into implementable equipment actions or manual station actions.

[0086] In S5, task distribution does not treat the same sample as a whole and send it to the same processing path. Instead, it splits and distributes tasks according to the target inspection items. That is, for multiple target inspection items corresponding to the same sample, the system can allow some items to enter the direct detection path, some items to enter the supplementary preprocessing path, and others to enter the analyzer switching path or manual review path. To achieve the above differentiated distribution, the system can establish a task execution record unit for each target inspection item in the edge node. The task execution record unit can include at least the following: unique sample identifier, target inspection item number, item-level judgment result label, priority collaborative processing action, alternative collaborative processing action, target execution node, action trigger time, precondition status, execution status, and result feedback identifier.

[0087] The target execution node can be one of the following: centrifuge equipment, mixing equipment, main analyzer, alternative analyzer, manual review station, or sample return station. The precondition status is used to identify whether the execution conditions are met before an action is issued. For example, whether the supplementary pretreatment action has available equipment, whether the analyzer switching action has locked the alternative analyzer, and whether the manual review action has generated a review work order. Through this recording method, the system can continuously track the execution progress of different items of the same sample at the edge, instead of losing project-level process information after the action is issued.

[0088] Furthermore, when the priority collaborative processing action corresponding to a certain target inspection item is direct detection, the task issuance and execution tracking unit can directly send the detection task corresponding to the target inspection item to the current target analyzer or the selected alternative analyzer. Before sending, the online status, item coverage status, sample barcode matching status, and queue receiving status of the target analyzer are verified. If the verification passes, the target inspection item is marked as issued and ready for execution. If the verification fails, its alternative collaborative processing action is read, and the analyzer switching path or manual review path is reselected according to the alternative action. The key point here is that even if S4 has generated the direct detection action, S5 does not issue it mechanically, but still needs to perform a final verification based on the real-time device status at the time of execution to ensure that the edge decision is consistent with the actual device execution conditions.

[0089] Furthermore, when the priority collaborative processing action corresponding to a certain target inspection item is to supplement preprocessing and then detect, the task issuance and execution tracking unit can first issue a preprocessing task to the corresponding preprocessing device, and then automatically trigger the issuance of the detection task after the preprocessing task is completed.

[0090] For example, when the main source of mismatch is insufficient centrifugation, the system can send a recentrifugation command to the recentrifugation device and, upon receiving a recentrifugation completion signal, remark the target inspection item as pending re-judgment or pending detection; when the main source of mismatch is insufficient sample mixing, the system can send a mixing command to the mixing device and, upon receiving feedback that mixing is complete, continue processing; when the main source of mismatch is partial label occlusion but remedial conditions are still available, the system can send a supplementary recognition task to the supplementary scanning station or image verification station.

[0091] The supplementary preprocessing and post-detection in S5 is not a single action, but includes three sub-processes: preprocessing action delivery, preprocessing completion feedback and retrieval, and automatic connection of subsequent detection actions. This serial delivery method ensures that the remedial path will not be broken in the execution chain.

[0092] Furthermore, when the priority collaborative processing action corresponding to a target inspection item is switching analyzer detection, the task issuance and execution tracking unit can first read the alternative analyzer information already determined in S4, and then check again whether the alternative analyzer still meets the project coverage relationship, sample type adaptation relationship, queuing acceptable condition, and online availability condition at the current moment. If the alternative analyzer meets the above conditions, the system issues the detection task corresponding to the target inspection item to the alternative analyzer and updates the execution status to switched and ready to execute. If the alternative analyzer no longer meets the conditions at the current moment, such as the device being offline, the queue suddenly increasing, or the project coverage status changing, the system can automatically call the alternative collaborative processing action for the target inspection item and transfer it to the manual review path or re-enter the edge judgment process. Through this processing method, S5 can ensure that the switching analyzer detection is not a static configuration result, but is consistent with the real-time execution status, thereby reducing the risk of task mismatch caused by dynamic changes in device status.

[0093] Furthermore, when the priority collaborative processing action corresponding to a certain target inspection item is to transfer to manual review, the task issuance and execution tracking unit can automatically generate a manual review work order corresponding to the target inspection item and push it to the manual review workstation. The manual review work order can include at least the unique sample identifier, the target inspection item number, the item-level judgment result label, the main source of mismatch, the key status features extracted from the edge side, the priority suggested action, and the alternative suggested action.

[0094] The key status characteristics may include one or more of the following: loading status, timeliness status, transportation temperature control status, centrifugation status, interference status, and candidate analyzer status. After receiving the work order, the manual reviewer can make a final confirmation to continue testing, supplement pre-processing and post-testing, switch analyzers for testing, or return the sample for re-sampling. In this embodiment, manual review is not an offline operation outside the system, but the edge node still uniformly records the review triggering reason, review processing process, and review conclusion, thereby ensuring that the manual participation link is still included in the subsequent closed-loop update scope.

[0095] Furthermore, when the priority collaborative processing action corresponding to a certain target inspection item is sample return and resampling, the task issuance and execution tracking unit can automatically generate a sample return and resampling instruction or a sample return and resampling suggestion form, and record the main basis for the target inspection item entering the sample return path. The main basis may include sample type mismatch, identity recognition failure, obviously insufficient loading, serious exceedance of transportation conditions, no available analyzer to cover the target item, or manual review rejection, etc. Even if a target inspection item enters the sample return and resampling path, the system does not require all target inspection items under the same sample to terminate at the same time, but allows other items that still meet the conditions to continue to be executed. Thus, S5 further strengthens the core processing logic of the same sample, different items, and different treatments of the present invention, and avoids the entire sample being intercepted as a whole due to individual items not meeting the conditions.

[0096] After the task assignment and execution tracking unit completes the assignment of actions, it can also continuously collect the execution results corresponding to each target inspection item. The execution results include at least one or more of the following: inspection completion status, manual review conclusion, re-inspection status, sample return status, and abnormality reason label.

[0097] Furthermore, the detection completion status can include completed, execution failed, execution suspended, and waiting for execution; the manual review conclusion can include allowing continued detection, requiring supplementary pretreatment, requiring switching the analyzer, requiring sample return and resampling, or maintaining the original action; the re-inspection status can include whether re-inspection was triggered, the reason for triggering re-inspection, and the status of the re-inspection result; the sample return status can include sample returned, sample awaiting return, and sample return cancelled; the abnormality reason label can include one or more of the following: insufficient filling volume, exceeding the time limit, transportation outside the boundary, insufficient centrifugation, high interference, main instrument congestion, alternative instrument unavailable, and abnormal identification.

[0098] By continuously collecting the execution results, the system can form a closed-loop record of execution for each target inspection item at the edge, providing a direct basis for parameter updates and rule corrections in subsequent S6. To prevent execution link interruption or state loss, S5 can also perform state machine management on the task execution process. Specifically, the task status corresponding to each target inspection item can include at least one or more of the following: pending issuance, issued, executing, completed, pending review, pending retry, returned sample, and closed.

[0099] When the device returns a successful reception signal, the status changes from pending to transmitted; When the device starts executing, the status changes from "issued" to "executing"; When the execution is complete and the result is successfully returned, the status changes to "Completed". When the device fails to execute, communication is interrupted, or the result is returned abnormally, the status can be switched to pending retry or pending review. When manual review clearly rejects the continued execution, the status switches to either "sample returned" or "closed".

[0100] Although the state machine transitions described above are relatively conventional task management logic, placing them in the execution scenario of sample-project splitting and flow can effectively ensure that the execution links of different target inspection projects will not be confused due to unified sample-level management.

[0101] For example, for a blood sample corresponding to liver function, electrolyte, and immune tests, the S4 output results are as follows: electrolyte tests are performed after switching analyzers, liver function tests are performed after supplementary pre-processing, and immune tests are performed after manual review.

[0102] In S5, the task assignment and execution tracking unit first generates alternative analyzer testing tasks for electrolyte items and assigns them to the backup biochemical analyzer; then it generates recentrifugation tasks for liver function items, and assigns testing tasks after receiving feedback that the recentrifugation is completed; at the same time, it generates manual review work orders for immunology items and pushes them to the manual review workstation.

[0103] During the tracking process, the backup biochemical analyzer returned a status indicating that the electrolyte test was completed, the recentrifugation equipment returned a status indicating that the liver function test pretreatment was completed and triggered subsequent tests, and the manual review station returned a conclusion suggesting that the immunoassay sample be returned and re-sampling be performed.

[0104] Ultimately, the three target tests for this sample produced different results: the electrolyte test was completed, the liver function test was completed after remedial testing, and the immune test entered the sample return and re-collection path. As can be seen from this example, in S5, this invention does not uniformly distribute and output conclusions around the whole sample, but rather distributes, tracks, and records each target test independently.

[0105] Through the above methods, in S5, the system, on the one hand, realizes the executable transformation of the project-level inspectability judgment results generated in S4 into specific equipment actions and manual workstation actions, enabling actions such as direct detection, supplementary pretreatment, switching analyzers, manual review, and sample return and resampling to truly enter the laboratory execution chain; on the other hand, through execution status recovery, abnormal cause recording, and project-level status tracking, the processing of different items for the same sample remains traceable, interpretable, and backtrackable. Thus, this invention not only realizes project-level judgment and action mapping at the edge, but also further establishes a project-level task execution closed loop oriented towards the experimental medical testing process, providing a reliable data foundation for parameter updates, rule corrections, and system self-calibration in the subsequent S6.

[0106] It is important to further emphasize that in this invention, task assignment and execution tracking do not simply output a unified conclusion for the entire sample. Instead, for different target test items corresponding to the same sample, the system reads the testability judgment results and corresponding collaborative processing actions for each item, and then assigns tasks and retrieves execution results separately. In other words, the system does not first form a single overall judgment result for the same sample and then provide several item suggestions; instead, each target test item corresponds to its own handling action and execution status. Therefore, the item-level processing logic in this invention does not merely remain at the result display level, but is implemented at the task execution and result retrieval level. It is precisely because of this mechanism that this invention avoids the coarse-grained processing method of traditional systems that only uniformly releases or intercepts based on the overall sample status, thereby achieving differentiated collaborative control for specific test items in the experimental medical testing process.

[0107] S6: Parameter updates and self-correction are performed based on the execution results. Specifically, after receiving the execution results collected in S5, the self-correction update unit uses the sample's unique identifier as the primary index and the target inspection item number as the sub-index to establish project-level feedback records for each target inspection item corresponding to the same sample. These project-level feedback records are then linked and bound to the corresponding project-level judgment results in S4, the corresponding project template version in S3, and the corresponding project-related feature set in S2, thus forming a closed-loop feedback dataset oriented towards sample-item-execution result object pairs. During the formation of the closed-loop feedback dataset, the system can also address missing fields, duplicate returned records, and conflict states in the execution results. The tags and abnormal termination records are filtered and cleaned. For example, projects that are not completed but have entered the manual review stage are marked separately, the results of multiple re-inspections of the same project are merged in chronological order, and records with obviously missing key fields are set as low-confidence feedback records, so as to ensure that the feedback data used for subsequent parameter updates is consistent and traceable. Subsequently, the self-calibration update unit updates the project requirement template parameters according to the detection completion status, manual review conclusion, re-inspection status, sample return status, and abnormality reason tags of each target inspection project. The project requirement template parameters include one or more of the following: inspectability judgment threshold, project rule parameters, abnormality judgment rule parameters, and instrument switching rule parameters.

[0108] In this way, S6 does not only use the execution results for archiving records, but further transforms them into feedback that can be used to correct template parameters and decision rules, thereby enabling the system to continuously adjust the edge-side project-level decision logic based on the actual laboratory operation results.

[0109] In a preferred embodiment, the update objects in S6 may include at least the following three categories: The first category is the update of the detectability determination threshold, which means adjusting the direct detection threshold, remedial release threshold, and manual review threshold corresponding to a certain target inspection item based on the success rate of release, the success rate of remediation, the reversal of manual review, and the confirmation of sample return in the historical execution of a certain target inspection item. The second category is project rule parameter updates, which adjust the sensitivity or priority of the corresponding target inspection items to various characteristic items based on the actual performance of characteristics such as loading volume, timeliness, transportation, centrifugation, interference and instrument compatibility. The third category is the updating of instrument switching rule parameters. That is, based on the completion efficiency, result consistency and manual review triggering of different candidate analyzers after actual switching, the priority of the alternative analyzer corresponding to the target test item or the switching permission conditions are adjusted. Thus, the self-calibration in S6 is not a general machine learning update, but a bounded closed-loop correction based on the template parameters, judgment thresholds and switching rules that have been clearly defined in the claims of this invention.

[0110] Furthermore, in some embodiments, the system can first classify the feedback records in the closed-loop feedback dataset into validity stratifications. For example, when the detection task of a target inspection item is completed normally and no subsequent re-inspection dispute is triggered, it can be recorded as highly effective feedback. When a target inspection item is completed after supplementary preprocessing but there is a manual confirmation process, it can be recorded as moderately effective feedback. When a target inspection item fails to form a clear final result due to equipment interruption, missing manual input, or status feedback conflict, it can be recorded as low-effective feedback. The self-correction update unit prioritizes using highly effective feedback records for parameter updates, followed by moderately effective feedback records. Low-effective feedback records are only used for anomaly statistics or manual review references and are not directly entered into the automatic update process. The purpose of this is to avoid the system directly modifying template parameters based on incomplete, conflicting, or unreliable execution results, thereby improving the stability of the self-correction process.

[0111] Furthermore, for the first The first of the target inspection items Template parameters can be used to construct updated parameter values. , Indicates the first The first target inspection item The parameter values ​​of the class template parameters before the update. This represents the nth objective test item calculated based on valid feedback records within a recent period. The target correction value for the class template parameter, Indicates the first The update step size coefficient corresponding to the nth type template parameter in the target test items; where the nth type template parameter is... Template parameters can be direct detection thresholds, remedial release thresholds, manual review thresholds, matching weights for a certain type of feature, trigger boundaries for a certain type of anomaly, or instrument switching permission conditions, and target correction values. The step size coefficient can be determined based on information such as execution success rate, manual review overturning rate, post-remediation completion rate, sample return confirmation rate, and re-inspection consistency in the effective feedback records; According to the first The historical sample size, feedback validity level, and parameter stability requirements for each target test item are preset. This method prevents drastic parameter fluctuations caused by a single abnormal sample, instead allowing for a smooth, gradual update of the template parameters corresponding to the target test item. In a preferred embodiment, for updating the detectability determination threshold, the first... The template parameters can specifically correspond to the direct detection threshold, the remedial release threshold, and the manual review threshold.

[0112] For example, if a large number of samples for a certain target test item fall within the recoverable abnormal range over a period of time, and can be reliably tested after supplementary preprocessing, and manual review rarely overturns the system's original judgment, then the remedial release threshold corresponding to that target test item can be appropriately lowered, or the tolerance boundary for a certain type of recoverable abnormality can be appropriately increased. Conversely, if a target test item is determined by the system to be directly detectable, but subsequent retesting failures, manual rejections, or sample rejections occur frequently, then the direct detection threshold corresponding to that target test item can be appropriately increased, or the corresponding abnormality trigger boundary can be tightened. Here, we will not write a separate conventional statistical formula for threshold updates, because its essence still belongs to the internal calculation process of determining the target correction value based on feedback results, and the above unified update formula can be used.

[0113] Furthermore, regarding the updating of project rule parameters, the system can adjust the matching weight or rule priority of features such as loading volume, timeliness, transportation, centrifugation, interference, and instrument compatibility based on the actual performance of different features in execution. For example, if a target test item shows in historical feedback that it is more sensitive to mild hemolysis but less sensitive to minor transportation deviations, the system can increase the interference-related rule parameters and decrease the transportation deviation-related rule parameters for that item. If a target test item is repeatedly remedied and successfully tested due to insufficient centrifugation during actual operation, the system can increase the priority of the rule that insufficient centrifugation can be recovered. If a target test item is frequently rejected in manual review due to identity recognition issues, the system can increase the strength of the identity recognition rigidity rule for that item. Thus, S6 not only updates the threshold boundaries but also corrects the sensitivity logic of different target test items to various abnormal features, making the project template more consistent with the actual usage characteristics of the laboratory.

[0114] Furthermore, regarding the updating of instrument switching rule parameters, the system can update the priority of the alternative analyzer corresponding to the target test item based on the actual performance of different candidate analyzers after the target test item switching execution. Therefore, it can be configured to update the priority of the alternative analyzer for the first test item. Target testing items in candidate analyzer Build the updated switching priority value ,in Indicates the first Each target test item in the candidate analyzer Priority value before update Indicates the first Each target test item in the candidate analyzer The priority value is used to update the step size coefficient. Indicates according to the first The target test items were switched to the candidate analyzer. The execution performance evaluation value calculated after the switch can comprehensively reflect the task completion status, waiting time performance, manual review trigger status, result consistency performance, and desample trigger status.

[0115] For example, if a candidate analyzer, when used as a replacement analyzer, repeatedly demonstrates short waiting times, high test completion rates, and low manual review rates, then the corresponding performance evaluation value... The priority of a candidate analyzer can be higher, which will increase its switching priority in subsequent similar projects. Conversely, if switching a candidate analyzer frequently causes delays in results or increases the need for manual review, its switching priority can be gradually reduced. In this way, when the system performs the switching analyzer detection action in the future, it will no longer rely solely on the static configuration, but will be able to dynamically adjust the priority of the alternative analyzer based on the actual historical execution effect.

[0116] S6 can also update the anomaly judgment rule parameters. For example, if a target inspection item has repeatedly been judged by the system as a recoverable anomaly in historical execution, but after manual review it is confirmed that the sample should be directly rejected, the rigid judgment level of the target inspection item for the corresponding anomaly combination can be increased. If a target inspection item has repeatedly been judged by the system as requiring manual review in historical execution, but the manual review conclusion has long maintained that direct detection is allowed, the triggering condition for the item to enter the manual review branch can be appropriately reduced. Here, the focus of updating the anomaly judgment rule parameters is not on complex calculations, but on correcting the anomaly judgment logic in the project template based on the deviation relationship between the original system judgment, the manual conclusion and the final result in the execution closed loop. Therefore, in this embodiment, textual description is sufficient, and formulas are not introduced separately.

[0117] Furthermore, after completing the parameter update, the self-correcting update unit can also write the updated parameters and their corresponding template version number back to the project requirement template management unit and generate a parameter update log. The parameter update log can include at least the target inspection project number, the updated parameter category, the parameter value before the update, the parameter value after the update, the main feedback source that triggered the update, the update time, and the template version number. By retaining the update log, the system can track which execution results a certain project template parameter changed based on during subsequent manual audits, rule rollbacks, or model reviews, thereby improving the interpretability and manageability of the edge-side self-correction mechanism.

[0118] To prevent excessive parameter shifts caused by a concentrated occurrence of abnormal samples at a certain stage, S6 can also set parameter update protection conditions. For example, when the effective feedback sample size for a target test item is lower than the preset minimum sample size, the system only records the update suggestion and does not immediately perform automatic updates. When the single update range of a parameter exceeds the preset maximum adjustment range, the system can truncate it or transfer it to manual review. When an abnormal cause label emerges in a short period of time and is suspected to be related to equipment failure, reagent batch problems, or external transportation abnormalities, the system can temporarily freeze the updating effect of such feedback on template parameters. Through these protective measures, it can be ensured that the self-correction update in S6 will not damage the overall stability of the project template due to short-term incidental factors.

[0119] In some preferred embodiments, the self-correcting update in this invention does not automatically modify all rules without constraints based on the execution results, but rather employs a controlled update mechanism. Specifically, the system only updates a pre-set set of parameters that are allowed to be updated. This set may include direct detection thresholds, remedial release thresholds, manual review thresholds, some item rule parameters, and priority values ​​for switching alternative analyzers. For fundamental, strongly constrained parameters such as sample type rules and rigid identity recognition rules, updates may be set to allow only manual review. Furthermore, when the effective feedback sample size for a target test item in the current statistical period is lower than the preset minimum sample size, the system only generates an update suggestion and does not directly execute an automatic update. When the magnitude of a single update of a parameter exceeds the preset maximum adjustment magnitude, the system may truncate it or transfer it to a manual approval process. When a certain type of abnormal label is detected to appear in a concentrated manner within a short period of time, and it is suspected to be related to external events such as equipment malfunction, reagent batch malfunction, or transportation malfunction, the system may temporarily freeze the impact of this type of feedback on parameter updates. At the same time, the system can also generate corresponding parameter update logs and template version numbers for each parameter update for subsequent manual auditing, rule verification, and parameter tracking.

[0120] For example, in a preferred embodiment, a laboratory accumulates multiple batches of closed-loop feedback records for a certain immunization project over a period of time. The system finds that: under the condition of slight temperature deviation during transport, if the sample collection time is still within the normal range, most samples can still be tested normally after manual verification; at the same time, the completion rate of switching to the backup analyzer is high and the manual verification rate is low when the main analyzer is congested. In S6, the system can appropriately relax the remedial release boundary for slight temperature control deviation of the immunization project and increase the switching priority of the backup analyzer in the immunization project. On the other hand, if the system also finds that the project is frequently rejected by manual verification under moderate interference conditions, the system can simultaneously increase the judgment strength of the project for interference-related anomalies. In this way, the template parameters, anomaly judgment logic and instrument switching priority relationship of the same target test project can be continuously corrected in the actual execution of the closed loop.

[0121] Through the above methods, in S6, the system organizes the execution results collected in S5 into a closed-loop feedback dataset oriented towards sample-item-execution result object pairs, enabling the execution effects of different target test items to be tracked individually and enter the parameter update process. On the other hand, it performs boundary-based, traceable, and interpretable self-correction updates on the item requirement template around the detectability judgment threshold, item rule parameters, anomaly judgment rule parameters, and instrument switching rule parameters. Thus, this invention can not only complete sample state feature extraction, item template matching, item-level judgment, and collaborative action issuance at the edge, but also continuously correct the item-level judgment logic based on the actual execution results, enabling the system to have adaptive optimization capabilities for specific items in experimental medical testing scenarios, thereby further improving the accuracy and stability of differentiated collaborative handling of different items for the same sample.

[0122] In summary, this invention does not merely perform front-end identification of sample anomalies in laboratory medical testing scenarios, nor does it simply compare rules using project templates. Instead, it unifies and couples sample status information, target testing requirements, and the feasibility of testing resources at the edge, forming a complete closed-loop chain from feature extraction, template matching, project-level detectability determination, action determination, task assignment, execution tracking, to parameter updates. Specifically, this invention generates project-level judgment results, determines corresponding collaborative processing actions, and generates execution feedback for different target testing projects corresponding to the same sample, thereby achieving project-level collaborative control for the laboratory medical testing process. Based on this, this invention can improve the targeting and traceability of project-level handling and provide a closed-loop basis for the continuous optimization of subsequent template parameters and handling rules.

[0123] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. An edge computing data collaborative processing system based on the Internet of Things in healthcare, characterized in that: include: The multi-source data acquisition unit is used to access sample processing-related equipment and information sources in experimental medical testing scenarios to acquire sample image information, sample volume information, label identification information, sample collection to testing time information, transportation temperature information, centrifugation record information, sample interference information, target test item information, and candidate analyzer operating status information of the sample to be tested. An edge feature extraction unit is deployed at the laboratory sample entry node, preprocessing node, or analyzer access node to perform edge-side parsing on the multi-source data and extract sample state features. The project requires a template management unit to store sample requirement templates for different testing items. The project-level detectability determination unit is used to match the sample state characteristics with the sample requirement template of the corresponding test item, and generate project-level detectability determination results for different target test items of the same sample. The collaborative processing decision unit is used to generate collaborative processing actions that correspond one-to-one with each target test item based on the test item-level testability determination results, so that different test items corresponding to the same sample can enter different subsequent processing paths. The task assignment and execution tracking unit is used to assign the collaborative processing actions to the corresponding pre-processing equipment, analyzer, or manual review station, and to collect the execution results.

2. The edge computing data collaborative processing system based on the medical Internet of Things according to claim 1, characterized in that: The sample image information acquired by the multi-source data acquisition unit includes at least one or more of the following: test tube image, liquid level image, label image, and tube cap status image. The acquired analyzer operating status information includes at least one or more of the following: analyzer load, queuing status, project coverage relationship, and standby instrument availability status.

3. The edge computing data collaborative processing system based on the medical Internet of Things according to claim 1, characterized in that: The sample state features extracted by the edge feature extraction unit include at least one or more of the following: liquid level height feature, sample volume distribution feature, label occlusion rate feature, label contamination rate feature, sample collection to detection time offset feature, transportation temperature deviation feature, centrifugation adequacy feature, sample interference intensity feature, and instrument waiting congestion feature.

4. The edge computing data collaborative processing system based on the medical Internet of Things according to claim 1, characterized in that: The project requires the template management unit to establish sample requirement templates for different testing items. The sample requirement templates include at least sample type requirements, minimum filling quantity requirements, label identification reliability requirements, maximum acceptable duration requirements, transportation conditions requirements, centrifugation conditions requirements, acceptable interference range requirements, and instrument usage requirements. Furthermore, the sample requirement templates corresponding to different testing items differ in at least one of the minimum filling quantity requirements, maximum acceptable duration requirements, acceptable interference range requirements, and instrument usage requirements.

5. The edge computing data collaborative processing system based on the medical Internet of Things according to claim 1, characterized in that: The project-level detectability determination unit is configured to output the detectability score or detectability level of the corresponding target test item based on the matching result of the sample state characteristics and the sample requirement template, and to output different detectability scores or detectability levels for different target test items of the same sample.

6. The edge computing data collaborative processing system based on the medical Internet of Things according to claim 1, characterized in that: The collaborative processing decision unit is configured to determine whether the current abnormal state is a recoverable abnormality or a rigid rejection abnormality based on the detectability score or detectability level corresponding to the target inspection item, and generate supplementary pre-processing and post-detection actions when the abnormality is a recoverable abnormality, and generate sample withdrawal and resampling actions when the abnormality is a rigid rejection abnormality.

7. The edge computing data collaborative processing system based on the medical Internet of Things according to claim 1, characterized in that: The collaborative processing decision unit is also configured to split and transfer the multiple target test items according to the detectability judgment results corresponding to each target test item when the same sample corresponds to multiple target test items, so that some target test items enter the direct detection path, and other target test items enter the supplementary preprocessing, analyzer switching, manual review or sample return and re-sampling path.

8. The edge computing data collaborative processing system based on the medical Internet of Things according to claim 1, characterized in that: The collaborative processing actions include at least one or more of the following: direct detection, supplementary pre-processing and post-detection, switching analyzer detection, transferring to manual review, and sample return and re-sampling. When generating the switching analyzer detection action, the collaborative processing decision unit is also used to combine the candidate analyzer operating status information and the instrument usage requirements of the corresponding test item to determine the alternative analyzer corresponding to the target test item.

9. The edge computing data collaborative processing system based on the medical Internet of Things according to claim 1, characterized in that: The execution results collected by the task issuance and execution tracking unit include at least one or more of the following: detection completion status, manual review conclusion, re-inspection status, sample return status, and abnormal reason label.

10. The edge computing data collaborative processing system based on the medical Internet of Things according to claim 1, characterized in that: The self-calibration update unit is used to update the project requirement template parameters according to the execution result. The project requirement template parameters include the detectability judgment threshold, project rule parameters, anomaly judgment rule parameters, or instrument switching rule parameters.

Images