AI-driven LIMS full-process sample traceability and blockchain credible storage method for third-party detection agencies

Abstract

The application discloses an AI-driven LIMS full-process sample tracing and blockchain credible storage method for third-party detection agencies, relates to the technical field of regional chains, and combines technical means such as artificial intelligence risk assessment, three-dimensional synchronous collection of multi-source evidence, cross-agency three-party hardware signature collaborative storage, hierarchical redundant storage of erasure coding, and independent verification of hash components in each dimension, to build a full-process sample tracing and storage system that is land-based, auditable and highly credible for third-party detection agencies, and realize a risk pre-control mechanism combining AI dynamic identification and manual pre-intervention of key storage nodes, effectively avoiding the key node omission problem caused by traditional static configuration.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and in particular to an AI-driven LIMS full-process sample traceability and blockchain trusted evidence storage method for third-party testing institutions. Background Technology

[0002] Laboratory Information Management Systems (LIMS), as the core infrastructure for information management in testing institutions, have evolved over decades from early data recording tools into comprehensive management platforms covering the entire chain of sample management, process control, data analysis, and quality compliance. In recent years, with the continuous improvement of the testing industry's requirements for data authenticity, process traceability, and regulatory compliance, LIMS systems have increasingly strengthened their capabilities in managing the entire sample lifecycle. Simultaneously, the deep integration of artificial intelligence technology with LIMS is driving the evolution of testing processes towards automation and intelligent decision-making, demonstrating significant application potential in scenarios such as image recognition, anomaly detection, and process optimization. Blockchain technology, with its decentralized, tamper-proof, and traceable characteristics, is also being gradually introduced into fields such as food and drug testing, sample traceability, and electronic data storage.

[0003] Existing blockchain-based LIMS (Limited Information Management System) evidence storage and traceability solutions still have several unresolved technical shortcomings. Firstly, at the evidence collection level, existing solutions typically only hash-store structured data such as operation logs or test results, lacking a mechanism for the simultaneous collection and correlation of unstructured multi-source evidence such as operational site images, sample physical identity, and flow environment parameters. This results in a single dimension of stored data, making it difficult to form a complete evidence loop. When a sample undergoes physical replacement or environmental anomalies during flow, log hashes alone cannot effectively reconstruct the actual situation, leading to an inherent weakness in the probative value of the evidence chain. Secondly, in cross-institutional collaborative scenarios, the flow of samples between the consignor, logistics carrier, and recipient involves multiple independent responsible parties. Existing solutions typically require each party to separately store their collected data on the blockchain. These records are stored independently and dispersedly, requiring manual retrieval and time-series splicing for auditing to establish correlations. This evidence preservation model is not only inefficient but also poses serious security risks. Because the evidence preservation transactions between parties are spaced out, any party has a window of time to replace or modify the data before the other party uploads it to the blockchain, making it impossible to simultaneously lock up evidence from multiple parties. The trust risks in cross-institutional transfer processes remain unresolved. Thirdly, at the storage and verification level, existing solutions mostly use the method of uploading original files such as images and environmental parameters to the blockchain as a whole or calculating their hashes before storage. This results in high storage costs and coarse verification granularity. When hash verification fails, auditors cannot pinpoint the specific dimension of the anomaly, leading to extremely low tracing efficiency. Fourthly, existing solutions generally lack differentiated redundant storage strategies for nodes with different risk levels. Using a uniform storage redundancy level for all original evidence results in a significant waste of storage resources. Summary of the Invention

[0004] The purpose of this section is to outline some aspects of the embodiments of the present invention and to briefly introduce some preferred embodiments. Some simplifications or omissions may be made in this section, as well as in the specification abstract and the title of the invention, to avoid obscuring the purpose of this section, the specification abstract, and the title of the invention. Such simplifications or omissions shall not be used to limit the scope of the invention.

[0005] In view of the aforementioned existing problems, the present invention is proposed.

[0006] To address the aforementioned technical problems, this invention provides the following technical solution: an AI-driven LIMS full-process sample traceability and blockchain trusted evidence storage method for third-party testing institutions, comprising: dynamically identifying key evidence storage nodes in the process through a risk scoring model based on testing standards and historical risk characteristics; and performing type changes on unmarked nodes in response to management instructions. In response to the triggering of key evidence storage nodes, evidence information from three dimensions—physical identity of the sample, on-site operation images, and circulation environment—is collected. A unique anchor summary covering these three dimensions is generated, and the experimental process is then initiated. This anchor summary is asynchronously submitted to the blockchain. When the sample is transferred across institutions, evidence information and digital signatures collected by the transferring party, logistics carrier, and receiving party are obtained. Multiple pieces of evidence are associated with signatures and packaged into a single evidence storage record, which is then written to the blockchain. The collected original evidence is fragmented and stored across multiple cross-domain nodes. During auditing, the original evidence is reconstructed and restored. Verification information for each evidence dimension is calculated and compared one by one with the corresponding dimension of the anchor summary in the blockchain. Based on the sample identifier, all associated anchor summaries are retrieved from the blockchain, and a traceability timeline is constructed in chronological order. In response to the selection of timeline nodes, the corresponding original evidence content is reconstructed and displayed, and a visual report containing the verification status of each node is output.

[0007] The beneficial effects of this invention are as follows: This invention organically combines artificial intelligence risk assessment, multi-source evidence three-dimensional synchronous acquisition, cross-institutional three-party hardware signature collaborative evidence storage, erasure coding hierarchical redundant storage, and hash component dimension-by-dimensional independent verification, etc., to construct a feasible, auditable, and highly reliable end-to-end sample traceability and evidence storage system for third-party testing institutions. It realizes a risk pre-control mechanism that combines AI dynamic identification of key evidence storage nodes with human pre-intervention, effectively avoiding the problem of missing key nodes caused by traditional static configuration. Attached Figure Description

[0008] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. Wherein: Figure 1 This is a flowchart illustrating the risk identification and node type determination process of the AI-driven LIMS full-process sample traceability and blockchain trusted evidence storage method for third-party testing institutions.

[0009] Figure 2 This is a flowchart illustrating the key nodes of the AI-driven LIMS full-process sample traceability and blockchain trusted evidence storage method for third-party testing institutions in this invention: evidence collection and asynchronous evidence storage. Detailed Implementation

[0010] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0011] Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without inventive effort should fall within the scope of protection of this invention.

[0012] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0013] According to an embodiment of the present invention, in combination Figures 1-2 The flowchart shown illustrates an AI-driven LIMS (Liquidity-Insulated Management System) end-to-end sample traceability and blockchain-based trusted evidence storage method for third-party testing institutions, including: S1: Based on detection standards and historical risk characteristics, key evidence storage nodes in the process are dynamically identified through a risk scoring model; in response to management instructions, type changes are performed on unmarked nodes.

[0014] In some embodiments, key evidence storage nodes in the process are dynamically identified through a risk scoring model based on detection standards and historical risk characteristics. First, S110 is executed to construct a risk characteristic baseline.

[0015] S110, Establish a risk characteristic baseline table in the LIMS database. The risk characteristic baseline table shall include at least three numerical indicators: the number of operational errors made by the current operator within a preset historical period, the historical rectification rate of the current testing standard within the preset historical period, and the repeat testing rate of the batch to which the current sample belongs. The preset historical period is preferably the past three months, but the present invention is not limited to this and can be dynamically configured according to the actual management needs of the laboratory.

[0016] The number of operational errors is statistically obtained from the LIMS operation audit logs, including but not limited to quantifiable operational anomalies such as sample identifier reading failures, process node jump errors, and deviations in test parameter input. The historical rectification rate is obtained from the corrective and preventive action records stored by the quality management department, calculated as the number of rectification reports associated with the current testing standard divided by the total number of times that standard was executed within the same time period. The duplicate testing rate is statistically obtained from the LIMS test result database, calculated as the number of duplicate test samples in the current sample batch divided by the total number of samples in that batch.

[0017] All three metrics are stored numerically in LIMS's local cache for use in subsequent risk scoring steps. By using local caching instead of real-time database queries, the input / output latency of the risk scoring process can be reduced, avoiding any noticeable delay impact on the experimental workflow.

[0018] In some embodiments, in S1 above, based on the risk characteristic baseline constructed in S110, S120 is further executed to perform AI risk scoring inference.

[0019] In S120, in response to the current process node being triggered, the LIMS process engine automatically invokes the pre-trained risk scoring model. The risk scoring model employs a logistic regression algorithm architecture, and its input vector is a three-dimensional numerical vector composed of the number of operational errors, historical rectification rate, and duplicate detection rate constructed in S110. The model is pre-trained, and the training dataset comes from historical audit records and quality incident reports from similar third-party testing agencies.

[0020] After performing a linear weighted summation on the input vector, the model maps the output value to a continuous interval from 0 to 100 through a logistic function. The output value is the risk score. The numerical meaning of the risk score is: the higher the score, the greater the probability that the current process node needs to be highlighted for quality compliance verification.

[0021] In this invention, the logistic regression model is used as a specific means of risk scoring inference. Its model parameters (i.e., the weight coefficients and bias terms corresponding to each input feature) have been trained before deployment and are stored in the LIMS server in the form of static parameter files after deployment. The inference process does not involve online updates or adaptive adjustments of the model parameters, thereby ensuring the determinism and reproducibility of the scoring output under the same input conditions.

[0022] Subsequently, the risk score is compared with a preset escalation threshold. This preset escalation threshold is pre-set by the laboratory's quality manager based on the institution's internal quality control strategy and stored in the LIMS system configuration table, with a preferred value of 75. This threshold can be manually adjusted by the quality manager based on the institution's annual quality review results, and the adjustment record should be entered into the system audit log.

[0023] In some embodiments, in S1 above, based on the risk score value output in S120, S130 is further executed to determine the node type and bind the risk label.

[0024] S130: If the risk score is greater than or equal to the preset dimensionality upgrade threshold, the LIMS workflow engine will automatically mark the current workflow node as a critical state mutation node. If the risk score is less than the preset dimensionality upgrade threshold, it will be marked as a normal workflow node. The significance of distinguishing between critical state mutation nodes and normal workflow nodes is that for workflow steps marked as critical state mutation nodes, subsequent enhanced evidence collection processes will be triggered, including but not limited to mandatory scanning of sample physical identity, mandatory capture of operation site images, and encrypted reading of workflow environment parameters, among other multi-dimensional evidence collection.

[0025] Meanwhile, regardless of whether a node is marked as a critical state mutation node or a normal flow node, the LIMS process engine appends the risk score value output by S120 as a risk label to the local metadata of the current node. The risk label is stored in key-value pairs, with the key being RiskScore and the value being a value between 0 and 100. This label is persistently stored in the LIMS database along with the current node's operation records.

[0026] In some embodiments, in S1 above, in response to management instructions, a type change is performed on unmarked nodes, specifically implemented through S140.

[0027] For target nodes marked as ordinary transfer nodes via S130, the quality manager can manually perform a dimensional upgrade operation through the QA management interface (S140). The QA management interface is a dedicated management interface for the quality management department within the LIMS system, featuring independent login authentication and access control.

[0028] Specifically, after the quality manager selects the target node on the QA management interface, they trigger a manual upgrade command. LIMS responds to this command by changing the target node's type from a regular flow node to a critical state mutation node. After the type change, this node will trigger a multi-dimensional evidence collection process in subsequent execution stages, following the standards for critical state mutation nodes.

[0029] It is important to note that manual dimensionality upgrade commands are only allowed to be triggered before the target node is actually executed. If the target node has already completed the experimental operation process (i.e., the node's state has transitioned to "completed"), LIMS will refuse to execute the manual dimensionality upgrade command and return a message indicating that the operation is not permitted. This constraint is designed to prevent retroactive management intervention, ensuring that the quality manager's dimensionality upgrade decision takes effect before the experimental operation occurs, thereby guaranteeing the integrity of the enhanced evidence collection process.

[0030] Simultaneously, in response to the execution of the manual upgrade command, LIMS automatically generates a manual intervention log. The manual intervention log includes at least the identity of the person making the change, the change timestamp, the node type before the change, and the node type after the change. LIMS performs a hash operation on the manual intervention log to generate a hash value, and independently submits this hash value to the blockchain for evidence storage.

[0031] It should be noted that the triggering time limit for manual dimensionality upgrade operations (which can only be triggered before the node is executed) ensures the pre-emptiveness and completeness of the enhanced evidence collection strategy, and avoids the logical loophole that key evidence will not be collected if dimensionality upgrade is performed after the operation is completed.

[0032] S2: In response to the triggering of key evidence storage nodes, it collects evidence information from three dimensions: physical identity of the sample, operation site images, and circulation environment. After generating a unique anchor digest covering the three-dimensional evidence information, it releases the experimental process and asynchronously submits the anchor digest to the blockchain.

[0033] S210, in some embodiments, acquiring the physical identity of the sample specifically includes scanning the tamper-evident RFID tag affixed to the bottom of the sample container using an RFID reader to obtain the physically unique identifier stored inside the RFID tag. The LIMS performs a SHA-256 hash operation on the physically unique identifier and outputs a first physical hash value.

[0034] Among them, the tamper-evident RFID tag has the characteristic of physical irreversible damage. Once it is peeled off from the surface of the sample container, its internal antenna structure breaks, making the tag unreadable again. By incorporating the hash value of the physical unique identifier into the subsequent anchor digest, the sample container itself becomes the physical anchor point of the evidence chain. If the sample is transferred to another container during circulation, the physical unique identifier reread by the receiving end will inevitably be inconsistent with the first physical hash value stored in the evidence, thereby achieving the binding of the sample itself and the digital identifier.

[0035] S220, in some embodiments, acquiring on-site images specifically includes: LIMS triggering a camera fixedly installed above the experimental workstation to capture real-time images of the sample, including the sample container and the operator's hand movements.

[0036] Upon triggering the snapshot, LIMS calls the trusted timestamp service interface of the National Time Service Center to obtain a trusted timestamp certificate containing the current precise time. The trusted timestamp certificate is protected for integrity by a digital signature issued by the National Time Service Center; any tampering with the certificate content will result in signature verification failure.

[0037] LIMS writes the acquired trusted timestamp certificate into the exchangeable image file format metadata area of ​​the sample live image, generating a first timestamp-embedded image. The trusted timestamp certificate is written into a specific reserved field in the Exif metadata; this field does not participate in the visual content display of the image, but is included as an integral part of the image file in subsequent hash calculations. Subsequently, LIMS performs a SHA-256 hash operation on the entire file of the first timestamp-embedded image, outputting a second image hash value.

[0038] In some embodiments, before writing the trusted timestamp certificate to the Exif metadata area, LIMS also performs an image validity pre-check: converting the sample live image into a grayscale image, calculating the luminance variance of all pixels in the grayscale image, and writing the luminance variance as an image validity score into the user annotation field of the Exif metadata area. By storing the image validity score along with the image, subsequent audits can use this score to determine whether the acquired image has acquisition quality defects such as being too dark, overexposed, or having the lens obstructed, serving as a reference for the credibility of the evidence. Simultaneously, LIMS also records the original byte length of the first timestamp embedded in the image, storing it in the local database as the first original file size.

[0039] S230, in some embodiments, the data acquisition process specifically includes: the LIMS sending a dynamic challenge random number to a low-power temperature-sensitive tag attached to the sample tube rack via a Bluetooth reader. The dynamic challenge random number is a value randomly generated by the LIMS each time data is acquired, used to prevent replay attacks.

[0040] The temperature-sensing tag responds to a dynamically challenged random number and uses an internally pre-set symmetric key to encrypt the current instantaneous temperature value and the extreme temperature fluctuations since the previous key evidence node, generating ciphertext of the ambient temperature, which is then transmitted back to the Bluetooth reader. The extreme temperature fluctuations include at least the highest and lowest temperature values ​​since the previous node.

[0041] After receiving the encrypted ambient temperature data, LIMS uses the same symmetric key stored locally as that in the temperature sensor tag to decrypt the encrypted data, obtaining the plaintext ambient temperature parameters. These plaintext parameters include at least the current instantaneous temperature value, the highest temperature since the previous node, and the lowest temperature since the previous node. LIMS then performs a SHA-256 hash operation on the plaintext ambient temperature parameters, outputting a third ambient hash value.

[0042] By combining dynamic challenge random numbers with symmetric key encryption, the risk of Bluetooth communication links being eavesdropped on or environmental data being forged can be effectively resisted. Because the challenge random number collected each time is different, even if an attacker intercepts the ciphertext of a certain transmission, they will not be able to replay the ciphertext in subsequent collection processes to pass verification.

[0043] S240, in some embodiments, after generating a unique anchor digest covering the three-dimensional evidence information, the experimental process is allowed to proceed. Specifically, this includes: the LIMS concatenates the first physical hash value output in S210, the second image hash value output in S220, and the third environmental hash value output in S230 according to a preset field arrangement order, and then performs a SHA-256 hash operation on the concatenated string again to generate a first three-dimensional anchor hash value. The first three-dimensional anchor hash value is the unique anchor digest, and this value will be submitted to the blockchain as the core evidence storage object of the key evidence storage node.

[0044] After generating the first 3D anchor hash value, LIMS assigns a strictly auto-incrementing queue number to it. This queue number allocation is completed within a database transaction and is bound to the current node's operation log record to ensure that the order of multiple anchor digests can be accurately restored during subsequent asynchronous commits.

[0045] LIMS associates and stores the first 3D anchor hash value, queue number, and current node's operation context information in its local temporary storage area. LIMS serializes the first AI risk label, the first AI image, the attached metadata, and the first original file size to generate an additional feature string, and associates this additional feature string with the queue number in the local temporary storage area. After completing local temporary storage, LIMS immediately returns a completion signal for the current node's operation to the workflow engine to allow subsequent physical experiment processes corresponding to the key evidence storage node to proceed.

[0046] The release in this embodiment includes: LIMS allows the experimenter to continue executing the operation of the next node without waiting for the first three-dimensional anchor hash value to be confirmed and written by the blockchain network. In the prior art, LIMS usually adopts a synchronous on-chain method, that is, after submitting data to the blockchain, it blocks and waits for the return result before releasing. When the blockchain network is congested, the confirmation time for a single evidence storage can be several minutes or even longer, which seriously affects the efficiency of the detection operation. This invention removes the confirmation delay of the blockchain network from the critical path of the experimental process through the decoupling design of local temporary storage and immediate release, so that the experimenter is completely unaware of the blockchain evidence storage process.

[0047] S250, in some embodiments, the anchor digest is asynchronously submitted to the blockchain, specifically including: the LIMS background daemon periodically scanning the local temporary storage area according to a preset time period. The background daemon is an independently running background thread or service process in the LIMS server, and its operation is isolated from the main experimental process. The evidence storage operation of the main process only involves writing to the local temporary storage area and does not call any remote interface of the blockchain network.

[0048] During each scan, the background daemon reads the first three-dimensional anchor hash value and its corresponding queue number from the local temporary storage area that has not yet been committed to the blockchain, in ascending order of queue number. The background daemon encapsulates the read first three-dimensional anchor hash value into a blockchain notarized transaction and broadcasts it to the nodes of the blockchain network through the blockchain client interface.

[0049] If the background daemon process submits a notarized transaction to the blockchain network and fails to receive a confirmation receipt from the blockchain network within a preset time threshold since the queue number was generated, the background daemon process will mark the node status corresponding to the queue number as pending verification. The preset time threshold is pre-configured by the system administrator based on the average block time of the blockchain network, for example, 24 hours.

[0050] The "Pending Verification" status is used to notify auditors during subsequent visual verification that the node's evidence data has been submitted but has not yet received final consistency confirmation from the blockchain network. Once the blockchain network confirms, the background daemon receives the receipt and updates the "Pending Verification" status to "Verified." By handling unconfirmed cases through status marking rather than repeated retries, the background daemon avoids getting stuck in an infinite retry loop due to blockchain network anomalies, thus ensuring the overall stability of the system.

[0051] S3: When samples are transferred between institutions, obtain the evidence information and digital signatures collected by the transferring party, the logistics carrier and the receiving party respectively, and package the evidence and signatures of multiple parties into a single evidence record and write it into the blockchain.

[0052] S310, in some embodiments, when a sample is transferred from the first institution to the second institution, the first institution acts as the transferor. The LIMS of the first institution sends the first three-dimensional anchor hash value generated in S240 and the additional feature string corresponding to the current node to the first hardware encryption device. The first hardware encryption device is a USB interface hardware encryption machine independent of the LIMS server, which internally stores a first private key. The first private key is held by the legal entity of the first institution and cannot be exported from the hardware encryption device.

[0053] The first hardware encryption device uses the first private key to perform a digital signature operation on the concatenation of the first three-dimensional anchor hash value and the additional feature string, outputting the first hardware signature data. The first institution's LIMS packages the first three-dimensional anchor hash value, the additional feature string, and the first hardware signature data together into an initiation stitching packet.

[0054] The additional feature string includes the risk score output in S120, the image validity score calculated in S220, and the size of the first original file recorded in S220. Including the additional feature string in the signature scope ensures that the risk assessment basis and image quality information used in the handover process are both solidified and stored as evidence. Subsequent audits can verify the original state of the above additional information at the time of handover by verifying the signature.

[0055] S320, in some embodiments, the logistics carrier triggers an activation command on the smart logistics lock placed inside the packaging box when the sample is packed and shipped. The smart logistics lock is an electronic lock with temperature sensing, timing, and data storage functions, and integrates a temperature sensor, a real-time clock, and non-volatile memory.

[0056] The smart logistics lock continuously records ambient temperature values ​​at preset fixed sampling intervals during transportation, forming an ambient temperature time series for the entire transportation process. At the end of transportation, the smart logistics lock outputs the highest and lowest ambient temperature values ​​for the entire transportation process, as well as an opening event timestamp. The opening event timestamp is the moment the smart logistics lock detects that the lock has been unlocked.

[0057] The smart logistics lock executes the opening event determination logic at the end of the transportation: if at least one opening event has occurred during the transportation period, the timestamp of the last opening event is taken as the valid value of the opening event timestamp; if no opening event has occurred during the transportation period, the opening event timestamp is assigned a predefined null identifier, preferably a placeholder with all fields set to 0x00.

[0058] Based on the above-mentioned unpacking event determination logic, regardless of whether an unpacking operation occurs during transportation, the smart logistics lock can output a complete set of transportation environment parameters, avoiding interruption of subsequent hash calculations and signature processes due to missing fields.

[0059] The logistics carrier's edge computing terminal receives the highest and lowest ambient temperature values ​​and the timestamp of the unpacking event from the smart logistics lock, and calculates an environmental fluctuation severity score. The calculation method for the environmental fluctuation severity score is as follows: the difference between the highest and lowest ambient temperature values ​​is calculated as the absolute range of temperature fluctuation; this absolute range is then divided by a preset physical allowable range, and the minimum value is taken. This minimum value operation constrains the calculation result to a closed interval between 0 and 1. The preset physical allowable range is pre-set by the logistics carrier based on the temperature sensitivity requirements of the transported samples, with a preferred value of 10 degrees Celsius.

[0060] The edge computing terminal combines the highest ambient temperature value, the lowest ambient temperature value, the timestamp of the unpacking event, and the environmental fluctuation severity score into a transportation environment parameter set, performs a SHA-256 hash operation on the transportation environment parameter set, and outputs the transportation environment hash value.

[0061] Subsequently, the edge computing terminal sends the transportation environment hash value to the second hardware encryption device. The second hardware encryption device is the same type of USB interface hardware encryption device as the first hardware encryption device, and it internally stores a second private key. This second private key is held by the logistics carrier and cannot be exported. The second hardware encryption device uses the second private key to perform a digital signature operation on the transportation environment hash value, outputting second hardware signature data.

[0062] In some embodiments, S330, the second institution, acting as the receiver, re-executes the physical identity acquisition, operational site image acquisition, and transfer environment acquisition methods in the same manner as in S210 to S240 after the sample arrives, generating a second three-dimensional anchor hash value at the time of reception. Specifically, physical identity acquisition involves rereading the physical unique identifier of the tamper-evident RFID tag on the bottom of the sample container and performing a hash operation; operational site image acquisition involves capturing images of the second institution's personnel receiving the sample, writing a trusted timestamp, and then performing a hash operation; and transfer environment acquisition involves reading the environmental sensor tag on the sample tube rack of the second institution to obtain the ambient temperature parameter at the time of reception and performing a hash operation.

[0063] The second organization's LIMS sends the second three-dimensional anchor hash value and the second additional feature string to the third hardware encryption device. The third hardware encryption device is a USB interface hardware encryption machine of the same type, which internally stores a third private key. This third private key is held by the legal entity of the second organization and cannot be exported. The third hardware encryption device uses the third private key to perform a digital signature operation on the concatenated second three-dimensional anchor hash value and the second additional feature string, and outputs the third hardware signature data.

[0064] The first, second, and third hardware encryption devices are held and managed by different legal entities, and the private keys of each device are physically isolated and invisible to each other. No single entity can forge the signatures of other entities, thus ensuring the authenticity and independence of the signatures of each party in the cross-institutional chain of evidence.

[0065] S340, in some embodiments, the smart contract on the blockchain receives the initiation stitching package generated in S310, the transport environment hash value and second hardware signature data generated in S320, and the second three-dimensional anchor hash value and third hardware signature data generated in S330.

[0066] The smart contract first verifies the validity of the first, second, and third hardware signature data, respectively. Specifically, the validity verification involves the smart contract using the public keys corresponding to the first, second, and third private keys to perform signature verification operations on each signature, confirming whether each signature was signed by the corresponding private key and that the signed data content has not been tampered with during transmission.

[0067] After all signature verifications are successful, the smart contract packages the following nine elements into a single notarized transaction: a first three-dimensional anchor hash value, first hardware signature data, an additional feature string, a transportation environment hash value, second hardware signature data, a transportation environment parameter set, a second three-dimensional anchor hash value, third hardware signature data, and a second additional feature string. The smart contract then writes the notarized transaction into the blockchain ledger, completing the notarized association of evidence for cross-institutional transfer.

[0068] It should be noted that in existing technologies, the transferring party, logistics party, and receiving party typically store their respective collected data on the blockchain. These records are stored independently and in a decentralized manner, requiring manual or additional procedures to link them during auditing. When tracing complete evidence of a cross-institutional transfer is needed, auditors must retrieve multiple stored transactions separately and then manually piece them together based on timestamps or sample numbers. This is not only inefficient but also carries the risk of errors or omissions in the linking process. More importantly, there are often time gaps between the stored transactions, allowing any party a window to replace or modify data before the others upload it to the blockchain, making true simultaneous locking of all three parties impossible. This invention, however, uses smart contracts to package the nine-tuple into a single, stitched stored transaction. The transferring party's transfer evidence, the logistics party's transportation environment evidence, and the receiving party's receipt evidence are indivisibly bound to the same blockchain transaction. Once the transaction is recorded on the blockchain, the evidence from all three parties is simultaneously solidified. No party can unilaterally modify or withdraw their evidence without being detected, thus eliminating the trust risk caused by the time difference in evidence submission between the parties during cross-institutional transfers.

[0069] S4: The collected original evidence is fragmented and stored in multiple remote nodes; during auditing, the original evidence is reassembled and restored, the verification information of each evidence dimension is calculated, and it is compared with the corresponding dimension of the anchor digest in the blockchain one by one.

[0070] S410, in some embodiments, before storing the collected raw evidence files in fragments, LIMS first reads the risk label of the current node. The risk label is the risk score value stored in the local metadata of the current node in S130.

[0071] LIMS compares the risk score with preset high-level thresholds and preset low-level thresholds. If the risk score is greater than or equal to the preset high-level threshold, LIMS selects the first erasure coding parameter group, which corresponds to the first total fragment count and the first recovery threshold, where the first recovery threshold is less than the first total fragment count. If the risk score is less than the preset high-level threshold but greater than or equal to the preset low-level threshold, LIMS selects the second erasure coding parameter group, which corresponds to the second total fragment count and the second recovery threshold, where the second recovery threshold is less than the second total fragment count, and the second total fragment count is less than the first total fragment count. If the risk score is less than the preset low-level threshold, LIMS selects the third erasure coding parameter group, which corresponds to the third total fragment count and the third recovery threshold, where the third recovery threshold is less than the third total fragment count, and the third total fragment count is less than the second total fragment count.

[0072] The preset high-level threshold is consistent with the preset dimensionality upgrade threshold in S120, while the preset low-level threshold is configured separately by the system administrator according to the storage resource policy, with a preferred value of 50. The total number of fragments represents the total number of data fragments generated after the original file is encoded with erasure coding, and the recovery threshold represents the minimum number of fragments required to recover the complete original file from the total number of fragments.

[0073] It's important to note that a higher risk score indicates a higher quality and compliance risk for the current node's sample or operational process. The corresponding original evidence files require a higher level of storage redundancy to ensure long-term data availability and resilience. By combining a higher total fragment count with a higher recovery threshold, even if multiple storage nodes fail or data is corrupted, the original evidence files can be fully recovered as long as the number of surviving fragments still reaches the recovery threshold. Conversely, evidence files from low-risk nodes use a lower total fragment count and recovery threshold, meeting basic redundancy requirements while reducing storage resource overhead.

[0074] S420, in some embodiments, the LIMS uses the first timestamp embedded image file generated in S220 and the environmental temperature encrypted file received in S230 together as a group of original evidence files to be stored.

[0075] LIMS invokes the erasure coding encoder to perform erasure coding operations on the original evidence file set based on the total number of fragments and the recovery threshold selected in S410. The erasure coding encoder divides the original evidence file set into a total number of data fragments, and any subset of fragments that reaches the recovery threshold can be completely reconstructed from the original evidence file set through erasure coding decoding operations.

[0076] It should be noted that erasure coding works by mapping the original data to redundant coded data through a linear transformation. This allows the original data to be fully recovered from the remaining coded data even if some coded data is lost, through an inverse transformation. This invention uses erasure coding instead of the traditional multi-copy replication method for redundant storage. At the same level of storage redundancy, erasure coding significantly outperforms multi-copy replication in terms of storage efficiency. For example, three-copy replication means three times the storage overhead of the original data, while erasure coding can reduce the storage overhead to approximately 1.5 to 2 times under the same fault tolerance, significantly reducing storage resource consumption.

[0077] S43, in some embodiments, the LIMS sends the total number of data fragments generated in S420 to multiple heterogeneous storage nodes according to a preset allocation strategy. These multiple heterogeneous storage nodes include at least the first institution's internal audit server, the first institution's off-site disaster recovery server, regulatory agency edge nodes, and judicial appraisal center nodes.

[0078] The preset allocation strategy ensures that the number of fragments stored on any single storage node is less than the recovery threshold. For example, when using the first erasure coding parameter set and the recovery threshold is 6, the number of fragments stored on any single storage node will not exceed 5. The significance of this constraint is that even if data on any single storage node is maliciously tampered with or completely destroyed by internal personnel, the number of fragments it holds alone is still insufficient to constitute the complete original data, thus making it impossible to recover the complete original evidence file independently. Any recovery operation requires collaborative fragment acquisition across multiple storage nodes, ensuring that data leakage or tampering on a single node will not directly compromise the integrity and confidentiality of the evidence.

[0079] S440, in some embodiments, in response to an audit instruction initiated by an auditor, the LIMS sends fragment retrieval requests to multiple heterogeneous storage nodes based on the queue number corresponding to the node to be audited. Each storage node responds to the request by returning the data fragments stored thereto belonging to that queue number to the LIMS.

[0080] LIMS counts the total number of data fragments collected. If the number of collected data fragments is less than the recovery threshold, LIMS directly outputs a storage node missing alarm signal and stops the subsequent verification process. The storage node missing alarm signal indicates that the original evidence files of the current audit node cannot be recovered due to storage node failure or data corruption, and there is a significant flaw in the integrity of the evidence chain of that node.

[0081] If the number of collected data fragments reaches or exceeds the recovery threshold, LIMS inputs the collected data fragments into the erasure coding decoder, performs erasure coding decoding operations, and reassembles and recovers the original evidence file group corresponding to the target node. The original evidence file group includes the first timestamp embedded image file and the environmental temperature encrypted file.

[0082] LIMS extracts the trusted timestamp certificate from the Exif metadata of the recovered first-timestamp embedded image file, and performs a SHA-256 hash operation on all byte data of the first-timestamp embedded image file, outputting the hash value of the image to be verified. LIMS uses the same symmetric key used in S230 to decrypt the recovered ciphertext environmental temperature file, obtaining the plaintext parameters of the environment to be verified, and performs a SHA-256 hash operation on the plaintext parameters of the environment to be verified, outputting the hash value of the environment to be verified.

[0083] It is important to note that this step does not perform a one-time hash operation on the first-timestamp embedded image file and the encrypted environmental temperature file. Instead, it calculates hash values ​​for the original files of both dimensions independently, outputting the image hash value and the environment hash value to be verified, respectively. These two hash values ​​together constitute the hash component group to be verified in this audit, which will be compared dimension by dimension with the corresponding component in the blockchain evidence in subsequent steps.

[0084] S450, in some embodiments, LIMS extracts the first three-dimensional anchor hash value corresponding to the target node from the blockchain and decomposes it into an on-chain physical component, an on-chain image component, and an on-chain environment component according to the preset field arrangement order in S240. The on-chain image component corresponds to the portion of the image file whose first timestamp is embedded and hashed during generation, then concatenated into the first three-dimensional anchor hash value. The on-chain environment component corresponds to the portion of the plaintext environmental parameters that are hashed and concatenated into the first three-dimensional anchor hash value.

[0085] LIMS compares the image hash value output from S440 with the on-chain image component bit by bit, and compares the environment hash value output from S440 with the on-chain environment component bit by bit.

[0086] If the hash value of the image to be verified is consistent with the on-chain image component and the hash value of the environment to be verified is consistent with the on-chain environment component, then it is determined that the original evidence file of the node is completely matched with the anchor digest of the blockchain evidence storage, and the original evidence has not been tampered with and is stored completely.

[0087] If the hash value of the image to be verified is inconsistent with the on-chain image component, or the hash value of the environment to be verified is inconsistent with the on-chain environment component, then it is determined that there is a difference between the original evidence file of the node and the anchor digest of the blockchain evidence, and a tampering alarm signal is output. The tampering alarm signal must at least include the specific dimension in which the inconsistency occurred, that is, the image dimension is inconsistent, the environment dimension is inconsistent, or both are inconsistent.

[0088] It should be noted that this step uses a dimension-by-dimensional comparison rather than a one-time comparison after calculating the hash of the entire recovered original evidence file group. The difference is that when using a one-time comparison, if any data in the image or environment dimension changes, the overall hash value will inevitably mismatch. However, auditors cannot determine from the overall hash mismatch whether the image file, the environment encrypted text, or both were tampered with, making it difficult to pinpoint the specific dimension where the anomaly occurred. By using a dimension-by-dimensional comparison, if the image hash matches but the environment hash does not, auditors can directly locate the anomaly in the environmental evidence collection stage, thereby narrowing the scope of tracing and specifically verifying the operation records and environmental equipment status at that stage. In addition, the on-chain physical component in the first three-dimensional anchor hash value stored on the blockchain is not included in this step. The on-chain physical component is used for comparison at the audit site by re-scanning the sample RFID tag and calculating the hash, to verify whether the physical sample has been replaced during the transfer process.

[0089] S5: Obtain all associated anchor summaries from the blockchain based on the sample identifier, construct a traceability timeline in chronological order; respond to the selection operation of timeline nodes, reorganize and display the corresponding original evidence content, and output a visual report containing the verification status of each node.

[0090] S510, in some embodiments, auditors input the sample number of the sample to be traced through an audit dashboard. The audit dashboard is a visual traceability interface provided by the LIMS system for auditors and quality management personnel, and a communication connection is established between the audit dashboard and the blockchain node.

[0091] In response to the input of a sample order number, the audit dashboard initiates a query request to the blockchain network, with the sample order number as the search keyword. Based on the sample order number, the blockchain network retrieves all evidence-based transactions associated with that sample order number and extracts all three-dimensional anchor hash values, additional feature strings, transportation environment parameter sets, and operation timestamps corresponding to each record from the evidence-based transactions.

[0092] After receiving the query results from the blockchain network, the audit dashboard sorts them according to the chronological order of the operation timestamps corresponding to each evidence record, generating an evidence timeline. The evidence timeline is presented in the audit dashboard interface in the form of a timeline. Each node on the timeline corresponds to an evidence storage stage in the life cycle of the sample. Each node displays the node name, operation timestamp, and node type identifier associated with that stage. The node type identifier is used to distinguish whether the node is a critical state change node or a normal circulation node.

[0093] It should be noted that in existing technologies, all sample operation records are stored in a scattered LIMS database. When auditors perform full-process traceability, they need to query multiple data tables sequentially and manually piece together the records based on timestamps and sample identifiers in the operation logs. When a sample has undergone multiple transfers or involves multiple testing items, the piecing process is time-consuming and prone to errors. In contrast, this invention stores all anchored summaries of the sample's entire lifecycle in a blockchain ledger linked by a unified sample number. The audit dashboard can retrieve all evidence records of the sample with a single query and automatically complete chronological sorting and visualization, significantly improving the efficiency and accuracy of audit traceability.

[0094] S520, in some embodiments, in response to an auditor's click operation on a target node on the evidence timeline, the audit dashboard obtains the queue number corresponding to the target node.

[0095] The audit dashboard initiates fragment collection requests to multiple cross-domain storage nodes based on queue numbers. Each storage node responds to the request, returning the data fragments belonging to its queue number to the audit dashboard. The audit dashboard counts the total number of collected data fragments. If the number of collected data fragments is less than the recovery threshold, the audit dashboard displays a message indicating a missing storage node and stops the subsequent display process.

[0096] If the number of collected data fragments reaches or exceeds the recovery threshold, the audit dashboard invokes the erasure coding decoder to perform decoding operations on the collected data fragments using the same erasure coding parameters as in S420, reconstructing and recovering the original evidence file group corresponding to the target node. The original evidence file group contains the first timestamp embedded image file corresponding to the target node and the encrypted environmental temperature file.

[0097] The audit dashboard extracts thumbnails from the recovered first-timestamp embedded image file. The extraction method involves reading the image data from the first-timestamp embedded image file, generating preview thumbnails according to a preset scaling ratio, and displaying the thumbnails on the audit dashboard interface. Simultaneously, the audit dashboard uses the same symmetric key used in S230 to decrypt the recovered environmental temperature ciphertext file, obtaining the environmental plaintext parameters for that node. Based on the extreme temperature fluctuations in the environmental plaintext parameters, it plots a temperature extreme value curve, which is then displayed on the audit dashboard interface.

[0098] Using the above method, when auditors click on any node on the timeline, they can simultaneously view the thumbnail of the on-site operation video and the corresponding environmental temperature change trend of that node without having to manually search for related files, which greatly reduces the operational cost for auditors to access and correlate multi-source evidence.

[0099] S530, in some embodiments, the audit dashboard performs SHA-256 hash recalculation on the recovered first timestamp embedded image file to obtain a recalculated image hash value. The audit dashboard performs SHA-256 hash recalculation on the decrypted environment plaintext parameters to obtain a recalculated environment hash value.

[0100] The audit dashboard extracts the on-chain image component and the on-chain environment component from the 3D anchor hash value corresponding to the target node stored on the blockchain, according to a preset field order. The audit dashboard then compares the recalculated image hash value with the on-chain image component bit by bit, and the recalculated environment hash value with the on-chain environment component bit by bit.

[0101] Based on the comparison results, the audit dashboard generates the status flags for the target nodes according to the following rules: If the recalculated image hash value matches the on-chain image component, and the recalculated environment hash value matches the on-chain environment component, it is marked as a hash matching state. A hash matching state indicates that the node's original evidence file is completely consistent with the blockchain's stored evidence content, the evidence has not been tampered with, and the storage is complete.

[0102] If the recalculated image hash value is inconsistent with the on-chain image component, or if the recalculated environment hash value is inconsistent with the on-chain environment component, it is marked as a hash mismatch state. A hash mismatch state indicates that there is a difference between the node's original evidence file and the blockchain-stored evidence content, and the credibility of the node's evidence is questionable, requiring further verification by auditors.

[0103] If the queue number corresponding to a node is marked as pending verification in S250 and no confirmation receipt has been received from the blockchain network to date, then it is marked as pending verification. The pending verification status indicates that the node's evidence storage data has been submitted to the blockchain network but has not yet received final confirmation, and its evidence storage result has not yet been finalized.

[0104] If no fewer than the recovery threshold number of data fragments can be collected from multiple cross-domain storage nodes, the node is marked as missing. A missing storage node status indicates that the original evidence files for that node cannot be recovered due to storage node failure or data corruption, and there is a significant flaw in the integrity of the chain of evidence.

[0105] S540, in some embodiments, after the audit dashboard completes the status determination of each node on the evidence timeline according to the above status marking rules, it generates a visual verification report containing the status markings of all nodes.

[0106] A visual verification report should include at least a sample basic information area, an evidence timeline area, and a detailed verification result area for each node. The sample basic information area displays basic information such as sample number, sample name, testing standard, and batch number. The evidence timeline area graphically displays the timeline distribution of all evidence nodes, with each node indicated by a different color or icon to indicate its verification status: nodes with hash matching are indicated by the first color, nodes with hash mismatch are indicated by the second color, nodes in the pending verification state are indicated by the third color, and nodes with missing storage nodes are indicated by the fourth color.

[0107] The detailed verification result area for each node responds to the auditor's click or hover operation on a specific node in the evidence timeline area, displaying detailed comparison information for that node, including at least: node name and operation timestamp, comparison result of recalculated image hash value and on-chain image component, comparison result of recalculated environment hash value and on-chain environment component, and the final status marker of that node.

[0108] Furthermore, if the target node's status is marked as a hash mismatch, the audit dashboard also executes anomaly attribution diagnosis logic. Specifically, the audit dashboard does not perform attribution analysis on the hash difference bits; instead, it performs a diagnosis based on the file's physical attributes. The audit dashboard checks whether the recovered original evidence file can be recognized as a valid image format by the standard image decoding library. If it cannot be recognized, it outputs a message indicating that the original image file is corrupted or has an abnormal format. If it can be recognized as a valid image format, the audit dashboard reads the current byte length of the recovered original evidence file and extracts the original byte length recorded when the node was generated from the additional feature string, calculating the absolute value of the relative deviation between the current byte length and the original byte length. If the absolute value of the relative deviation exceeds a preset deviation threshold, it outputs a message indicating that the image file size is abnormal and it is suspected of being completely replaced. If the absolute value of the relative deviation is within the preset deviation threshold, it outputs a message indicating that the image content has undergone unknown changes and recommends manual review of the original image. Meanwhile, if the environmental hash component of the target node also does not match, the audit dashboard will further read the environmental fluctuation severity score from the transportation environment parameter set. If the environmental fluctuation severity score exceeds the preset fluctuation alarm threshold, an auxiliary explanation that severe environmental fluctuations may cause data failure will be added after the prompt message.

[0109] The method also includes one or more processors and memory.

[0110] The memory is used to store operable instructions that, when executed by the one or more processors, cause the one or more processors to perform operations, including the process of the AI-driven LIMS end-to-end sample traceability and blockchain trusted evidence storage method for third-party testing institutions as described in the foregoing embodiments, especially... Figure 1The flowchart of the method is shown.

[0111] Other aspects disclosed in the embodiments of the present invention also propose a computer-readable medium for storing software including instructions executable by one or more computers, which, upon execution, cause the one or more computers to perform operations, including the process of the AI-driven LIMS end-to-end sample traceability and blockchain trusted evidence storage method for third-party testing institutions as described in the foregoing embodiments, particularly... Figure 1 The flowchart of the method is shown.

[0112] It should be recognized that embodiments of the present invention may be implemented or carried out by computer hardware, a combination of hardware and software, or by computer instructions stored in a non-transitory computer-readable storage medium.

[0113] The method can be implemented using standard programming techniques, including a non-transitory computer-readable storage medium configured with a computer program in the computer program, wherein the storage medium is configured such that the computer operates in a specific and predefined manner.

[0114] Each program can be implemented in a high-level procedural or object-oriented programming language to communicate with the computer system; however, if required, the program can be implemented in assembly or machine language.

[0115] In any case, the language can be either compiled or interpreted.

[0116] Furthermore, for this purpose, the program can run on programmed application-specific integrated circuits.

[0117] The processes described herein (or variations and / or combinations thereof) can be executed under the control of one or more computer systems configured with executable instructions, and can be implemented by hardware or a combination thereof as code (e.g., executable instructions, one or more computer programs, or one or more applications) that commonly executes on one or more processors. The computer program includes a plurality of instructions executable by one or more processors.

[0118] Furthermore, the method can be implemented in any suitable computing platform, including but not limited to personal computers, minicomputers, mainframes, workstations, networked or distributed computing environments, standalone or integrated computer platforms, or in communication with charged particle tools or other imaging devices.

[0119] Various aspects of the present invention can be implemented in machine-readable code stored on a non-transitory storage medium or device, whether portable or integrated into a computing platform, such as a hard disk, optical read and / or write storage medium, RAM, ROM, etc., such that it can be read by a programmable computer, and when the storage medium or device is read by the computer, it can be used to configure and operate the computer to perform the processes described herein.

[0120] Furthermore, machine-readable code, or parts thereof, can be transmitted via wired or wireless networks.

[0121] When such media includes instructions or programs that combine with a microprocessor or other data processor to implement the steps described above, the invention described herein includes these and other different types of non-transitory computer-readable storage media.

[0122] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. An AI-driven LIMS full-process sample traceability and blockchain trusted evidence storage method for third-party testing institutions, characterized by: include: Based on detection standards and historical risk characteristics, key evidence storage nodes in the process are dynamically identified through a risk scoring model. In response to management commands, perform type changes on unmarked nodes; In response to the triggering of key evidence storage nodes, evidence information in three dimensions—physical identity of the sample, on-site operation images, and circulation environment—is collected. After generating a unique anchor summary covering the three-dimensional evidence information, the experimental process is allowed to proceed, and the anchor summary is asynchronously submitted to the blockchain. When samples are transferred across institutions, evidence information and digital signatures collected by the transferring party, logistics carrier and receiving party are obtained respectively, and the evidence and signatures of multiple parties are packaged into a single evidence record and written into the blockchain. The collected original evidence is fragmented and stored in multiple remote nodes; during auditing, the original evidence is reassembled and restored, the verification information of each evidence dimension is calculated, and it is compared with the corresponding dimension of the anchor digest in the blockchain one by one. Based on the sample identifier, all associated anchor summaries are obtained from the blockchain and a traceability timeline is constructed in chronological order. In response to the selection of timeline nodes, the corresponding original evidence content is reorganized and displayed, and a visual report containing the verification status of each node is output.

2. The AI-driven LIMS full-process sample traceability and blockchain trusted evidence storage method for third-party testing institutions as described in claim 1, characterized in that: The key evidence storage nodes in the dynamic identification process include: Construct a risk characteristic baseline, which includes the number of historical operational errors of the current operator, the historical rectification rate of the current testing standard, and the repeat testing rate of the current sample batch; In response to the current process node being triggered, the number of operational errors, the historical rectification rate, and the duplicate detection rate are input into the risk scoring model, and a risk score value is output. The risk score is compared with a preset dimensionality threshold. If the risk score reaches or exceeds the preset dimensionality threshold, the current process node is marked as a critical state mutation node; otherwise, it is marked as a normal flow node. The risk score is then stored as a risk label in the local metadata of the current node.

3. The AI-driven LIMS full-process sample traceability and blockchain trusted evidence storage method for third-party testing institutions as described in claim 1, characterized in that: The evidence information in the three dimensions of the collected samples—physical identity, on-site images of the operation, and the circulation environment—includes: The physical unique identifier of the sample container is read by an RFID reader, and a hash operation is performed on the physical unique identifier to generate a physical identity hash value; The camera is triggered to capture a real-time image of the sample, and a reliable timestamp is obtained and written into the metadata area of ​​the real-time image of the sample to generate a timestamp-embedded image. A hash operation is then performed on the timestamp-embedded image to generate an image hash value. By sending a reading command to the environmental sensing tag attached to the periphery of the sample container through a Bluetooth reader, the environmental temperature parameter is obtained, and a hash operation is performed on the environmental temperature parameter to generate an environmental hash value.

4. The AI-driven LIMS full-process sample traceability and blockchain trusted evidence storage method for third-party testing institutions as described in claim 3, characterized in that: Before capturing the current sample image and obtaining a reliable timestamp to write into the metadata area of ​​the sample image, an image validity check is also performed: The captured real-time image of the sample is converted into a grayscale image, and the pixel brightness variance value of the grayscale image is calculated as the image validity score. The image validity score is compared with a preset validity threshold. If the image validity score is lower than the preset validity threshold, the image is determined to be invalid and a reshoot instruction is triggered. If the image validity score reaches or exceeds the preset validity threshold, the image is determined to be valid, subsequent hash operations are allowed, and the image validity score is stored as additional image information in the metadata area.

5. The AI-driven LIMS full-process sample traceability and blockchain trusted evidence storage method for third-party testing institutions as described in claim 3, characterized in that: The step of obtaining ambient temperature parameters by sending a reading command to an environmental sensing tag attached to the periphery of the sample container via a Bluetooth reader includes: The Bluetooth reader sends a dynamic challenge random number to the environmental sensing tag; the environmental sensing tag uses an internally preset symmetric key to encrypt the current instantaneous temperature value and the extreme value of temperature fluctuation since the previous node, generating ciphertext of the environmental temperature and sending it back to the Bluetooth reader; after receiving the ciphertext of the environmental temperature, the Bluetooth reader uses the symmetric key to decrypt it to obtain the plaintext environmental parameters, and performs a hash operation on the plaintext environmental parameters.

6. The AI-driven LIMS full-process sample traceability and blockchain trusted evidence storage method for third-party testing institutions as described in claim 1, characterized in that: The process of generating a unique anchor digest covering three-dimensional evidence information, allowing the experiment to proceed, and asynchronously submitting the anchor digest to the blockchain includes: The physical identity hash value, the image hash value, and the environment hash value are concatenated in a preset order to generate a three-dimensional anchoring hash value. Assign a queue number to the three-dimensional anchor hash value, associate the three-dimensional anchor hash value with the queue number and store it in the local temporary storage area, and then immediately allow the physical experiment process of the current node to proceed. The background daemon process reads the three-dimensional anchor hash value from the local temporary storage area and submits the evidence storage transaction to the blockchain network in the order of the queue number. If no confirmation receipt is received from the blockchain network within a preset time period since the queue number was generated, the node status corresponding to the queue number will be marked as pending verification.

7. The AI-driven LIMS full-process sample traceability and blockchain trusted evidence storage method for third-party testing institutions as described in claim 1, characterized in that: The acquisition of evidence information and digital signatures collected by the logistics carrier includes: The logistics provider activates the smart logistics lock when the sample is packed. The smart logistics lock records the ambient temperature sequence at fixed sampling intervals during transportation and outputs the highest ambient temperature value, the lowest ambient temperature value, and the timestamp of the opening event at the end of transportation. The difference between the highest and lowest ambient temperatures is calculated as the temperature fluctuation range. The minimum value of the temperature fluctuation range is then calculated by dividing the temperature fluctuation range by a preset physical allowable range and outputting the environmental fluctuation severity score. The highest ambient temperature value, the lowest ambient temperature value, the unpacking event timestamp, and the environmental fluctuation severity score are combined into a transportation environment parameter set. After performing a hash operation on the transportation environment parameter set, a digital signature from the logistics provider is appended.

8. The AI-driven LIMS full-process sample traceability and blockchain trusted evidence storage method for third-party testing institutions as described in claim 1, characterized in that: The step of associating multiple pieces of evidence with signatures and packaging them into a single evidence record for writing into the blockchain includes: The transferring party uses its first hardware encryption device to perform a digital signature on the three-dimensional anchor hash value and additional features collected by the transferring node, generating the first signature data. The logistics provider uses its second hardware encryption device to perform a digital signature on the transportation environment parameter set and the transportation environment hash value to generate second signature data. The recipient uses its third hardware encryption device to perform a digital signature on the three-dimensional anchor hash value and additional features collected by the receiving node, generating third signature data; The smart contract on the blockchain receives the first signature data, the second signature data, and the third signature data. After verifying the validity of each signature, it packages the evidence information collected by the transfer node with the signature, the transportation environment evidence information with the signature, and the evidence information collected by the receiving node with the signature into a single stitched evidence storage transaction and stores it in the blockchain ledger.

9. The AI-driven LIMS full-process sample traceability and blockchain trusted evidence storage method for third-party testing institutions as described in claim 1, characterized in that: Before the collected raw evidence is fragmented and stored across multiple cross-domain nodes, a hierarchical redundancy parameter selection process is also performed: Extract the risk score value from the risk tags bound to the current node; If the risk score reaches or exceeds the preset high-level threshold, then the first erasure coding parameter group is selected. The first erasure coding parameter group corresponds to the first total number of fragments and the first recovery threshold. The first recovery threshold is less than the first total number of fragments. If the risk score is between the preset low-level threshold and the preset high-level threshold, then the second erasure coding parameter group is selected. The second erasure coding parameter group corresponds to the second total fragment number and the second recovery threshold. The second recovery threshold is less than the second total fragment number, and the second total fragment number is less than the first total fragment number. If the risk score is lower than the preset low-level threshold, then the third erasure coding parameter group is selected. The third erasure coding parameter group corresponds to the third total fragment count and the third recovery threshold. The third recovery threshold is less than the third total fragment count, and the third total fragment count is less than the second total fragment count.

10. The AI-driven LIMS full-process sample traceability and blockchain trusted evidence storage method for third-party testing institutions as described in claim 1, characterized in that: After the reconstructed data displays the corresponding original evidence and outputs a visual report including the verification status of each node, anomaly attribution diagnosis is also performed: When the recalculated image hash value is inconsistent with the image component stored in the blockchain, no attribution analysis is performed on the hash difference bits; instead, the following diagnostic logic is executed: Check whether the recovered original image file can be recognized as a valid image format by the standard image decoding library; if it cannot be recognized, output a prompt message indicating that the original image file is corrupted or has an abnormal format; If the image can be identified as a valid image format, the current byte length of the recovered original image file is read and compared with the original byte length recorded when the image file was acquired. If the relative deviation between the current byte length and the original byte length exceeds a preset deviation threshold, a prompt message indicating that the image file size is abnormal and it is suspected of being completely replaced is output. If the image can be identified as a valid image format and the relative deviation between the current byte length and the original byte length is within the preset deviation threshold, then output a prompt message indicating that the image content has undergone unknown changes and suggesting manual review of the original image. If the environmental hash values ​​are also inconsistent, the environmental fluctuation severity score in the transportation environment parameter set is further read; if the environmental fluctuation severity score exceeds the preset fluctuation alarm threshold, an auxiliary explanation that severe environmental fluctuations may cause data failure is added after the prompt information.

Images