Storage verification method, storage verification device, and storage medium for detection report

Abstract

The application provides a storage verification method and device of a detection report and a storage medium. The method comprises the following steps: obtaining core information of a detection report; generating a digital digest of the detection report according to the core information; signing the digital digest to generate a digital signature, and controlling a plurality of report detection platforms to perform target verification on the detection report based on the core information, the digital digest and the digital signature of the detection report, and write the digital digest into a blockchain ledger after the verification is passed; and in the case that a verification request of a report detection platform on a to-be-verified report is obtained, verifying the to-be-verified report in the blockchain ledger according to the identification and the core information of the to-be-verified report to obtain a verification result. The application solves the problem of difficulty in verifying the authenticity of information in the process of circulation of the detection report in multiple institutions.

Description

Technical Field

[0001] This application relates to the field of data security technology, and more specifically, to a method for storing and verifying test reports, a device for storing and verifying test reports, and a computer-readable storage medium. Background Technology

[0002] With the widespread application of next-generation sequencing (NGS) technology in fields such as precision oncology diagnosis and treatment and genetic disease screening, testing institutions generate test reports containing a large amount of variant site information and clinical annotation results. These reports typically need to be circulated and archived long-term between testing institutions, medical institutions, and regulatory agencies.

[0003] In existing technologies, NGS test reports are usually stored in electronic file form, and their authenticity mainly depends on the management measures of the testing organization itself, which has the following shortcomings: If the report is modified after it is generated due to reasons such as updates to the annotation database or manual review, it is difficult to effectively record the relationship between different versions; during the process of the report circulating among multiple parties, the recipient has difficulty in independently verifying whether the report content has been tampered with; directly storing the complete report content centrally or uploading it to the blockchain for evidence storage poses the risk of privacy leakage and high storage costs; and regulatory agencies have difficulty conducting unified audits and retrospectives of historical report versions.

[0004] Therefore, there is an urgent need for a technical solution that can achieve trusted verification and version control of NGS test reports while ensuring privacy and security. Summary of the Invention

[0005] The main objective of this application is to provide a method, apparatus, and computer-readable storage medium for storing and verifying test reports, so as to at least solve the problem of difficulty in verifying the authenticity of test reports during the circulation of test reports among multiple institutions in the prior art.

[0006] To achieve the above objectives, according to one aspect of this application, a method for storing and verifying a test report is provided, comprising: obtaining core information of the test report, the core information including at least: the identifier of the test report, testing platform information, the original hash value of the test report, key test result information, and report generation time information, wherein the identifier of the test report includes the first number of the test report and the salted hash of the sample identifier of the test report, the key test result information includes key mutation sites and multi-layer hash root, and the report generation time information includes a generation timestamp; generating a digital digest of the test report based on the core information; having the signing entity of the test report digitally sign the digital digest to generate a digital signature; and controlling multiple reports... The testing platform performs target verification on the testing report based on its core information, digital digest, and digital signature. Target verification includes: verifying the legitimacy of the signing entity and the validity of the digital signature; if multiple testing platforms indicate successful verification, the digital digest and its associated digital signature are written into the blockchain ledger; upon receiving a verification request from a testing platform for a report to be verified, the platform verifies the report in the blockchain ledger based on its identifier and core information, obtaining a verification result. If the report to be verified matches any testing report in the blockchain ledger, the verification result indicates successful verification.

[0007] Optionally, target verification is performed on the test report, including: verifying whether the signer of the test report is a legitimate entity based on the signer certificate hash corresponding to the test report and the filing record in the consortium blockchain's identity authentication system; if the signer of the test report is verified to be a legitimate entity, verifying whether the signer has valid qualifications based on the digital certificate of the test report; if the signer has valid qualifications, verifying whether the signer has consistent identity association based on the signer's public key and the filing public key of the signer certificate hash; if the identity association of the signer is consistent, determining that the signer is a legitimate entity; decrypting the original hash value based on the signer's public key to obtain the hash value of the original hash value; generating a target hash value by combining the digital digest, the original hash value, and the generation timestamp according to a first preset rule; determining whether the hash values ​​of the target hash value and the original hash value are consistent; if the hash values ​​of the target hash value and the original hash value are consistent, the original hash value is a valid signature.

[0008] Optionally, the storage verification method further includes: determining whether the core information meets the preset information requirements; if the core information does not meet the preset information requirements, the verification result indicates verification failure; if the core information meets the preset information requirements, determining whether the data format of the information in the core information meets the preset standard format; if the data format does not meet the preset standard format, correcting the data format of the information that does not meet the preset standard format.

[0009] Optionally, the storage verification method further includes: obtaining the second number of the previous version of the test report, the timestamp of the test report being written into the blockchain ledger, and the status information of the test report, the status information including valid, replaced, and revoked; and establishing a relationship between the test reports based on the second number, timestamp, first number, and status information, the relationship representing the relationship between the test report and the previous version of the test report.

[0010] Optionally, based on the second number, timestamp, first number, and status information, an association relationship is established between the test reports, including: determining whether there is a number in the blockchain ledger that is identical to the first number, and determining whether the naming of the first number meets the preset naming requirements; if there is no number in the blockchain ledger that is identical to the first number and the naming of the first number meets the preset naming requirements, determining whether the test report is an updated version; if the test report is an updated version, determining whether the status information of the previous version of the test report is revoked; if the status information of the previous version of the test report is not revoked, determining whether the previous version of the test report has been properly stored in the blockchain ledger; if the previous version of the test report has been properly stored in the blockchain ledger, establishing an association relationship between the test report and the previous version of the test report.

[0011] Optionally, upon receiving a verification request from the report detection platform for the report to be verified, the report to be verified is checked in the blockchain ledger based on its identifier and core information to obtain a verification result. This includes: obtaining the core information of the report to be verified and determining whether the core information meets preset information requirements; if the core information does not meet the preset information requirements, the verification result fails; if the core information meets the preset information requirements, determining whether the identifier information of the report to be verified has a corresponding digital digest in the blockchain ledger; if the identifier information of the report to be verified does not have a corresponding digital digest in the blockchain ledger, the verification result fails. The identifier information includes the identifier of the report to be verified, or the identifier information includes the report to be verified. The report sample identifier salted hash and version information are used. The version information includes the report identifier and status information of the previous version of the report to be verified. If it is determined that the identifier information of the report to be verified has a corresponding digital digest in the blockchain ledger, it is determined whether the first multi-level hash root of the report to be verified is consistent with the second multi-level hash root of the digital digest corresponding to the report to be verified in the blockchain ledger. If the first multi-level hash root is consistent with the second multi-level hash root, a target multi-level hash root is generated by taking some core information of the report to be verified according to the second preset rule. If the target multi-level hash root is consistent with the second multi-level hash root, the verification is successful.

[0012] Optionally, the storage verification method further includes: when the report detection platform verifies a specific information field of the report to be verified, obtaining the specific information field, parsing the specific information field to obtain the matching field type of the specific information field, and matching the matching field type with the information in the digital digest corresponding to the report to be verified in the blockchain ledger; if the match is successful, generating a matching path from the hash node of the specific information field in the digital digest to the multi-level hash root; and forming verification proof data for the specific information field based on the standardized hash value of the specific information field, wherein the standardized hash value is extracted from the digital digest of the specific information field.

[0013] Optionally, the storage verification method further includes: calculating the hash value of a specific information field based on the verification proof data to obtain a first preset hash value; determining whether the first preset hash value is consistent with the standardized hash value, and if they are consistent, the verification is successful; or, based on the matching path, performing aggregation calculations layer by layer from the multi-level hash root to the hash node to determine a second preset hash value, determining whether the second preset hash value is consistent with the standardized hash value, and if they are consistent, the verification is successful.

[0014] According to another aspect of this application, a storage and verification device for a test report is provided, comprising: an acquisition module for acquiring core information of the test report, the core information including at least: an identifier of the test report, test platform information, the original hash value of the test report, key test result information, and report generation time information, wherein the identifier of the test report includes the first number of the test report and the sample identifier salting hash of the test report, the key test result information includes key variant sites and multi-level hash root, and the report generation time information includes a generation timestamp; a generation module for generating a digital digest of the test report based on the core information; a signature module for digitally signing the digital digest by the signature subject of the test report to generate a digital signature; and a control module for controlling multiple... Each report testing platform performs target verification on the test report based on its core information, digital digest, and digital signature. Target verification includes: verifying the legitimacy of the signing entity and the validity of the digital signature; a writing module, used to write the digital digest and its associated digital signature into the blockchain ledger when multiple report testing platforms indicate successful verification; and a verification module, used to verify the report to be verified in the blockchain ledger based on the report's identifier and core information when a verification request is received from a report testing platform, obtaining a verification result. If the report to be verified matches any test report in the blockchain ledger, the verification result indicates successful verification.

[0015] According to another aspect of this application, a computer-readable storage medium is provided, the computer-readable storage medium including a stored program, wherein, when the program is running, a storage verification method for a test report is controlled to be executed by the device where the computer-readable storage medium is located.

[0016] By applying the technical solution of this application, the core information of the test report is obtained, and a digital digest of the test report is generated based on the core information. The digital digest is signed to generate a digital signature, and multiple report testing platforms are controlled to verify the digital digest simultaneously. After successful verification, the digital digest is written into the blockchain ledger. When a verification request for a report to be verified is received from a report testing platform, the report to be verified is verified in the blockchain ledger based on the identifier and core information of the report to be verified, and a verification result is obtained. If the report to be verified matches any test report in the blockchain ledger, the verification result indicates successful verification. The aforementioned method, during the report storage phase, generates a digital digest by acquiring core information from the test report. This allows only the digital digest, rather than the complete report content, to be uploaded to the blockchain, reducing the risk of sensitive data leakage and enhancing the system's privacy protection capabilities. It also controls multiple test report verification platforms to simultaneously verify the test report. Upon successful verification, the digital digest and its associated digital signature are uploaded to the blockchain, ensuring the test report is recognized by multiple institutions, guaranteeing its authenticity during inter-institutional circulation, and enhancing the credibility of the report's source. Furthermore, writing the digital digest and its associated digital signature into the blockchain ledger leverages the blockchain's immutability to achieve persistent recording of report versions, facilitating traceability and comparison between versions. When a verification request is received, the digital digest in the blockchain ledger can be quickly located and verified to confirm the authenticity of the report to be verified, thereby improving the auditing capabilities of regulatory agencies and the collaborative efficiency among multiple institutions. This method addresses the difficulty in verifying the authenticity of test reports during multi-institutional circulation in existing technologies. Attached Figure Description

[0017] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings:

[0018] Figure 1 A hardware structure block diagram of a mobile terminal for performing a storage verification method for a detection report according to an embodiment of this application is shown.

[0019] Figure 2 A flowchart illustrating a method for storing and verifying a test report according to an embodiment of this application is shown.

[0020] Figure 3 A structural block diagram of a test report storage and verification device provided according to an embodiment of this application is shown.

[0021] The above figures include the following reference numerals:

[0022] 102. Processor; 104. Memory; 106. Transmission device; 108. Input / output device. Detailed Implementation

[0023] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0024] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0025] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate for the embodiments of this application described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0026] As described in the background section, existing test reports are usually stored in electronic file form, and their authenticity mainly depends on the management measures of the testing institution itself, which has many shortcomings. In order to solve the problem of difficulty in verifying the authenticity of information in the process of test reports circulating among multiple institutions, the embodiments of this application provide a method for storing and verifying test reports, a device for storing and verifying test reports, and a computer-readable storage medium.

[0027] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention.

[0028] The methods and embodiments provided in this application can be executed on a mobile terminal, computer terminal, or similar computing device. Taking running on a mobile terminal as an example, Figure 1 This is a hardware structure block diagram of a mobile terminal for a method of storing and verifying a detection report according to an embodiment of the present invention. Figure 1 As shown, a mobile terminal may include one or more ( Figure 1Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. The mobile terminal may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the mobile terminal described above. For example, the mobile terminal may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0029] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the storage verification method of the detection report in this embodiment of the invention. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, thereby implementing the above-described method. The memory 104 may include high-speed random access memory and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the mobile terminal via a network. Examples of the above-described networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof. The transmission device 106 is used to receive or send data via a network. Specific examples of the above-described networks may include wireless networks provided by the mobile terminal's communication provider. In one example, the transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to communicate with the Internet. In one example, the transmission device 106 may be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0030] This embodiment provides a method for storing and verifying detection reports that runs on a mobile terminal, computer terminal, or similar computing device. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Also, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0031] Figure 2 This is a flowchart of a method for storing and verifying detection reports according to an embodiment of this application. Figure 2 As shown, the method includes the following steps:

[0032] Step S1: Obtain the core information of the test report. The core information includes at least the following: the identifier of the test report, the test platform information, the original hash value of the test report, the key test result information, and the report generation time information. The identifier of the test report includes the first number of the test report and the sample identifier salting hash of the test report. The key test result information includes the key variant sites and the multi-level hash root. The report generation time information includes the generation timestamp.

[0033] Specifically, the first number of the test report is the report's unique ID, generated using "institution code + timestamp + random string" (e.g., "LAB001_20251015_8f7d2e") to ensure global uniqueness; the sample identifier salting hash is generated and stored by the testing institution's NGS system to prevent plaintext leakage of the sample ID; the original hash value of the test report is the SHA-256 of the original report file, and the SHA-256 hash is directly calculated on the original report file (PDF / DOCX / JSON) as the core basis for file integrity verification; the multi-layer hash root contains multiple Merkle leaves such as sample, platform, annotation library, mutation site, and file hash, supporting zero-knowledge proofs for some information. Merkle (Merkle Trusted Tree) is a cryptographic term; in the test report, key mutation sites are usually the focus of analysis, as they provide important basis for clinical decision-making. For example, they can help doctors understand whether a patient has risk factors for hereditary diseases, whether they carry tumor driver gene mutations, or potential sensitivity to a certain drug. The normalized expression of key variant sites follows a specific format, such as: "EGFR:NM_005228.4:exon21:c.2573T>G:p.L858R". This indicates that in exon 21 of the EGFR gene, the T (thymine) at cDNA position 2573 is replaced by G (guanine), resulting in the amino acid leucine (L) at position 858 of the protein sequence being changed to arginine (R). The generated timestamp is based on the time reported by the testing agency, accurate to milliseconds, to avoid timestamp conflicts.

[0034] Specifically, the core information also includes the signer identifier (signature information) of the test report, the annotation database version information, and the ID of the previous version of the test report. The signer identifier is the hash value of the signer certificate of the test report, which is associated with the on-chain identity authentication information and supports the traceability of the signer's identity. The annotation database version information includes the annotation database version mapping to the Merkle root. The annotation database version can be regarded as a template for generating the test report. Different annotation database versions may contain different data parameters in the generated test reports.

[0035] Step S2: Generate a digital summary of the test report based on the core information;

[0036] Specifically, digital summaries are used to verify the completeness and consistency of a report without revealing its original content, thus serving as a core basis for verifying the report's credibility. The generation process of a digital summary includes at least key information related to changes in the report content. This may include standardized sample identifiers, sequencing platform and core parameters, key variant sites in normalized format, and the complete hash of the original report. Any change to core information (e.g., sample information correction, sequencing depth adjustment, addition or correction of variant sites, update of clinical annotations, etc.) will be sensitively transmitted to the digital summary through the hash algorithm, ensuring that different content or versions of the report will necessarily correspond to different digital summaries. For example, if the original report changes the EGFR classification of a certain site from level I to level II due to an annotation database update, its original report hash and final digital summary will be completely different from the original version. Similarly, after adding an ALK gene fusion variant site, changes in the Merkle subroot of the variant site will cause a synchronous change in the digital summary, thus ensuring the uniqueness of the report identifier.

[0037] Step S3: The signatory of the test report digitally signs the digital digest to generate a digital signature;

[0038] Specifically, after determining that the signing subject is an authenticated and legitimate entity, the signing private key bound to the signing subject is invoked to perform digital signature operations on the digital digest.

[0039] Step S4: Control multiple report detection platforms to perform target verification on the detection report based on the core information, digital digest, and digital signature of the detection report;

[0040] Specifically, each participating institution node will conduct parallel verification of the legality of the stored data according to the preset consensus rules, including verifying the validity of the signature information, the consistency between the digital digest and the core information of the report, and the legality of the signer's identity.

[0041] Step S5: If the target verification results from multiple report detection platforms indicate that the verification has passed, write the digital digest and its associated digital signature into the blockchain ledger.

[0042] Specifically, core evidence data such as the report's digital digest, signature information (signer identifier and digital signature), and version identifier must undergo independent verification and consensus confirmation by multiple authorized institutional nodes (such as testing institutions, regulatory agencies, and core medical institutions) within the consortium blockchain before being formally written into the blockchain ledger. Only when more than a preset proportion (e.g., more than 2 / 3) of the nodes report successful verification, and the verification results from all nodes are completely consistent, will the write operation be triggered, synchronously recording the data into the blockchain ledgers of all nodes. This multi-node confirmation mechanism avoids evidence invalidation caused by data tampering or misoperation by a single institutional node, ensuring the objectivity and credibility of on-chain evidence information. It also strengthens the foundation for multi-institutional collaborative supervision, enabling the evidence results to gain the common recognition of the entire consortium blockchain network.

[0043] Step S6: Upon receiving a verification request from the report testing platform for the report to be verified, the report to be verified is verified in the blockchain ledger based on the identifier and core information of the report to be verified, and a verification result is obtained. If the report to be verified matches any test report in the blockchain ledger, the verification result indicates successful verification.

[0044] Specifically, upon receiving a verification request, the verifier can either use the report's unique ID to precisely locate a specific version, or use the sample identifier's salted hash to query all historical versions of the sample and filter out the valid (ACTIVE) versions as the current authoritative version. Based on the digital digest, version association information, and signature information, the verifier then verifies the authenticity of the report to be verified and the current version status. Version association information refers to the relationships discussed later.

[0045] In this embodiment, the method generates a digital digest by acquiring the core information of the test report during the report storage stage. This allows only the digital digest, rather than the complete report content, to be uploaded to the blockchain, reducing the risk of sensitive data leakage and enhancing the system's privacy protection capabilities. Furthermore, it controls multiple test report platforms to simultaneously verify the test reports. Upon successful verification, the digital digest and its associated digital signature are uploaded to the blockchain, ensuring the test report is recognized by multiple institutions, guaranteeing its authenticity during circulation among them, and enhancing the credibility of the report's source. Writing the digital digest and its associated digital signature into the blockchain ledger leverages the blockchain's immutability to achieve persistent recording of report versions, facilitating traceability and comparison between versions. When a verification request is received, the digital digest in the blockchain ledger can be quickly located and verified to confirm the authenticity of the report to be verified, thereby improving the auditing capabilities of regulatory agencies and the collaborative efficiency among multiple institutions. This method solves the problem of difficulty in verifying the authenticity of test reports during multi-institutional circulation in existing technologies.

[0046] Digital signatures are used to characterize the source credibility of report digests, and their specific signature algorithms are not limited by this invention. Verification of a digital signature requires satisfying both "identity legitimacy verification" and "signature validity verification." The verification process uses "identifier location - multi-dimensional verification - status confirmation" as its core logic to ensure comprehensive and reliable verification results. In specific implementation, step S4 above performs target verification of the detection report, which can be achieved through the following steps:

[0047] Based on the signer certificate hash corresponding to the test report and the filing record in the consortium blockchain's identity authentication system, the signature entity of the test report is verified to be a legitimate entity. If a unique matching filing record is found in the consortium blockchain's identity authentication system through the signer certificate hash (signer_id) associated with the test report, it can be confirmed that the signer entity is a legitimate institution that has completed qualification registration (such as a testing institution with NGS testing qualifications or a compliant medical institution).

[0048] If the signatory of the test report is a legitimate entity, the validity of the signatory's qualifications is verified based on the digital certificate of the test report. If the filing record shows that the digital certificate of the signatory is valid (not expired or revoked), and the authorized testing scope covers the test type of the current report (such as tumor NGS testing, genetic disease screening testing, etc.), and there is no report generated beyond the scope of qualifications, the validity of the signatory's qualifications is verified.

[0049] If the signing entity has valid qualifications, the identity association consistency of the signing entity is verified based on the public key of the signing entity and the public key of the signed certificate hash. If the on-chain public key of the signing entity completely matches the public key of the signed identifier (signer_id), it can be determined that the public key has not been tampered with or replaced, and the identity association consistency of the signing entity can be confirmed, which can provide a legitimate basis for subsequent signature decryption.

[0050] If the identity association of the signing entities is consistent, the signing entity is determined to be a legitimate entity. The original hash value is decrypted using the signing entity's public key to obtain the hash value of the decrypted detection report. The digital digest, the original hash value, and the generation timestamp are combined according to a first preset rule to generate a target hash value. The hash values ​​of the target hash value and the original hash value are compared. If they match, the original hash value is considered a valid signature. The algorithm used for the original hash value (such as RSA-2048, ECDSA-secp256r1, etc.) is consistent with the algorithm registered by the signing entity and conforms to the pre-set algorithm compatibility standard of the consortium blockchain, avoiding decryption failure due to algorithm incompatibility. The original hash value is decrypted using the signing entity's on-chain public key to obtain the decrypted hash value. Simultaneously, the core information of the report is concatenated according to the fixed rule of "digital digest (merkle_root) || report original hash (file_hash) || generation timestamp (report_time)," and the hash value of the same algorithm is calculated. If the two are completely consistent, the signature content is determined to have not been tampered with. Only when both the identity verification and signature validity verification pass can the digital signature verification be deemed successful, thereby confirming that the source of the report summary is credible, the content has not been tampered with, and the original hash value is a valid signature.

[0051] To ensure the consistency of the report summary information structure and the completeness of fields in on-chain evidence storage, and to meet the compatibility requirements of cross-institutional verification, the storage verification method also includes the following steps before generating the digital signature in step S3:

[0052] The system determines whether the core information meets the preset requirements. If the core information does not meet the preset requirements, the verification result indicates verification failure. It also performs mandatory verification to ensure that the core fields are complete, including but not limited to the sample identifier salting hash (sample_id_hash), sequencing platform hash (platform_hash), variant site Merkle subroot (variant_sub_root), original hash value of the test report (file_hash), Merkle root (multi-layer hash root, merkle_root), report generation timestamp (report_time), and report unique ID (report_id). If any field is missing, the verification is directly deemed to have failed.

[0053] If the core information meets the preset requirements, the system checks whether the data format of the information within the core information meets the preset standard format. If the data format does not meet the preset standard format, the data format of the information that does not meet the preset standard format is corrected. The system verifies that the data format of each field is consistent with the preset standard. For example, the sample identifier salted hash (sample_id_hash) must be a 64-bit SHA-256 hash string; the report generation timestamp (report_time) must conform to the time format "YYYY-MM-DD H:MM:SS"; and the report unique ID (report_id) must follow the combination rule of "organization code + timestamp + random string". If the format does not conform, a field correction prompt is triggered.

[0054] Before writing the digital digest to the blockchain ledger in step S5 above, the detection report can also be linked, and the storage verification method also includes:

[0055] The system obtains the second ID of the previous version of the test report, the timestamp of the test report being written to the blockchain ledger, and the status information of the test report, including whether it is valid, replaced, or revoked. It records the change history and status of each version, ensuring the continuity and transparency of the report versions, which facilitates the auditing and quality control of the reports. By tracking the on-chain timestamp and status information of each report version, it is possible to accurately understand the change time and reasons between different versions, thereby constructing a clear report version evolution path.

[0056] Based on the second ID, timestamp, first ID, and status information, a relationship is established between the test reports. This relationship represents the connection between the test report and the previous version. After successful verification of the test report, the ID (second ID), the on-chain timestamp of the previous version, the ID (first ID), and the status information of the previous version are used as part of the version association information. After the current test report is uploaded to the blockchain, the status of the previous version is updated to "REPLACED," and the current version is identified as related to the previous version, thus forming a chain structure of report versions in the blockchain ledger.

[0057] In some optional implementations, the above steps establish the association between the test reports based on the second number, timestamp, first number, and status information, including:

[0058] Determine if there is a number in the blockchain ledger that is the same as the first number, and determine if the naming of the first number meets the preset naming requirements; verify whether the unique report ID of the current report is the same as the ID of the test report that has been stored on the chain to avoid version number conflicts; at the same time, verify whether the format of the unique report ID includes the organization code + timestamp + random string to ensure the uniqueness of version differentiation;

[0059] If there is no identical number in the blockchain ledger and the naming of the first number meets the preset naming requirements, determine whether the test report is an updated version. If the test report is an updated version, determine whether the status information of the previous version of the test report is revoked. If the current report is an updated version (not the initial version), it is necessary to verify whether the previous version corresponding to the ID of the report to be verified has been notarized on the chain, and whether the status of the previous version is "ACTIVE" or "REPLACED". If it does not exist or the status is abnormal (such as "REVOKED"), the inheritance relationship cannot be established.

[0060] If the status information of the previous version of the test report is not "revoked," then it is determined whether the previous version of the test report has been properly stored in the blockchain ledger. If the previous version of the test report has been properly stored in the blockchain ledger, a relationship is established between the test report and the previous version. After verifying that the previous version of the test report has been properly stored in the blockchain ledger, the relationship between the current version and the previous version is automatically established, and the status of the previous version is updated to "REPLACED," while the status of the current version is marked as "ACTIVE," forming an immutable version evolution chain.

[0061] When a test report for the same sample is updated, a version inheritance relationship is established based on the previous version of the test report, thus forming a traceable report version evolution structure. This version inheritance relationship clarifies the order and evolution path between different report versions, avoiding version confusion.

[0062] In the above optional implementation, the association relationship (inheritance relationship) refers to the fact that when a new version of the test report is generated for the same sample, the new version report establishes a clear parent-child relationship with the previous version report by recording its predecessor version identifier ID in the blockchain ledger. The report version evolution structure is a directed acyclic chain structure based on the inheritance relationship, starting from the initial test report and inheriting from multiple subsequent report versions in sequence, where each node corresponds to a specific report version.

[0063] When a report is generated, the on-chain information will have three identifiers:

[0064] 1. The ID of the previous version of the test report (perv_version_id). When each non-first version report is generated, the previous version identifier it inherits must be clearly recorded in its version identification information.

[0065] 2. On-chain timestamp (block_ts): When each version report summary is written into the blockchain ledger, it is bound to the timestamp information of the corresponding block, which is used to represent the time sequence in which the version is officially confirmed and registered.

[0066] 3. Report Status: Each report version has a corresponding version status field, including: ACTIVE (currently valid version), REPLACED (replaced by a subsequent version), and REVOKED (revoked version).

[0067] Report version evolution process:

[0068] 1. Initial report issued (V1).

[0069] report_id: RPT_20251015_A;

[0070] prev_version_id: empty;

[0071] version_status: ACTIVE.

[0072] Note: The first test report generated for sample S001 is the initial version of that sample.

[0073] 2. Update the annotation database (ClinVar) and generate a new version (V2).

[0074] report_id: RPT_20251102_B;

[0075] prev_version_id:RPT_20251015_A;

[0076] version_status: ACTIVE;

[0077] Previous version status: RPT_20251015_A→REPLACED.

[0078] Note: The ClinVar database update has changed the clinical significance of EGFR mutations in the epidermal growth factor receptor gene. A new version report will be generated without changing the original test data.

[0079] 3. Manually review and correct sample descriptions (V3).

[0080] report_id: RPT_20251110_C;

[0081] prev_version_id:RPT_20251102_B;

[0082] version_status: ACTIVE;

[0083] Previous version status: RPT_20251102_B→REPLACED.

[0084] Note: Correcting the error in the description of the sample source does not affect the test results, but it still results in a new report version.

[0085] The final report evolution structure is: RPT_20251015_A (REPLACED) → RPT_20251102_B (REPLACED) → RPT_20251110_C (ACTIVE).

[0086] In some embodiments, step S6 above, upon receiving a verification request from the report detection platform for the report to be verified, verifies the report to be verified in the blockchain ledger based on the identifier and core information of the report to be verified, and obtains the verification result. This can be achieved through the following steps:

[0087] The system retrieves the core information of the report to be verified and determines whether the core information meets the preset information requirements. If the core information does not meet the preset information requirements, the verification result fails. It also receives verification requests submitted by verification parties (such as medical institutions or regulatory agencies) and determines whether the core request parameters contained in the verification request meet the preset information requirements. If the core request parameters meet the preset information requirements, they will include: the report identifier (report_id) or sample identifier (sample_id_norm), the core metadata of the report to be verified, including the multi-level hash root (merkle_root), the SHA-256 of the original report file (the original hash value of the detection report mentioned above, file_hash), the report generation time (report_time), and the signer identifier (signer_id).

[0088] If the core information meets the preset information requirements, it is determined whether the identification information of the report to be verified has a corresponding digital digest in the blockchain ledger. If it is determined that the identification information of the report to be verified does not have a corresponding digital digest in the blockchain ledger, the verification result fails. The identification information includes the identifier of the report to be verified, or the identification information includes the salted hash of the sample identifier of the report to be verified and version information. The version information includes the report identifier of the previous version of the report to be verified and the status information of the previous version of the report to be verified. If it is determined that the identification information of the report to be verified has a corresponding digital digest in the blockchain ledger, it is determined whether the identification information of the report to be verified... The system checks whether the first multi-level hash root matches the second multi-level hash root of the digital digest corresponding to the report to be verified in the blockchain ledger. Using "the identifier of the report to be verified" or "the salted hash and version information of the sample identifier of the report to be verified" as the query conditions, it calls the consortium blockchain data interface to locate the corresponding on-chain evidence record—including the digital digest of the report (multi-level hash root, merkle_root), version association information (ID and report status of the previous version of the report to be verified), signature information (hash value of the signer's certificate and original hash value), etc. If no matching record is found, it directly determines that "the report is not evidenced and the verification fails."

[0089] If the first multi-level hash root is consistent with the second multi-level hash root, a target multi-level hash root is generated from a portion of the core information of the report to be verified according to the second preset rule. The target multi-level hash root is then compared with the second multi-level hash root. If they are consistent, the verification is successful. The multi-level hash root (first multi-level hash root) of the report to be verified is extracted and compared bit by bit with the multi-level hash root (first multi-level hash root) stored on the blockchain. If they match, the core content of the report is confirmed to have not been tampered with, and the verification is successful.

[0090] In the above optional implementation, after comparing the first and second multilevel hash roots, the multilevel hash roots of the core fields of the report to be verified (such as sample identifier, sequencing platform, key variant sites, etc.) can be recalculated according to preset rules for a second comparison. If the two comparisons are consistent, it is confirmed that the core content of the report has not been tampered with; if they are inconsistent, it is marked as "suspected content tampering", verification is suspended and a follow-up prompt is given.

[0091] In the above optional implementation, after confirming that the core content of the report has not been tampered with, the signature can be verified according to the preset dual standard of "identity legitimacy + signature consistency" to confirm whether the subject corresponding to the hash value of the signer's certificate is a legitimate filing institution and whether the original hash value is consistent with the concatenated hash of "digital digest (merkle_root) || report original hash (file_hash) || generation timestamp (report_time)". If the signature verification fails, it is determined that "the source of the report is not trustworthy" and the verification is terminated.

[0092] Verify version status and relationships: Query the on-chain report status field to confirm the current status of the report (e.g., "ACTIVE - valid" or "REPLACED - replaced"); if it is not the initial version, further verify whether the previous version corresponding to the ID of the report to be verified of the previous version exists, to ensure that the version evolution chain is complete and traceable; if the status is abnormal (e.g., "REVOKED - revoked") or the relationship is broken, push a risk warning to the verifier.

[0093] Summarize and provide feedback on the verification results: Based on the above verification results, generate a standardized verification report, clearly indicating "verification passed", "verification failed" or "further verification required", and attach detailed verification logs (such as consistent fields, specific locations of inconsistencies, signature verification results, etc.), and push them synchronously to the verification party's terminal.

[0094] In some alternative implementations, where the verifier does not need to fully verify all contents of the report but only needs to confirm the authenticity of specific fields, the storage verification method also includes:

[0095] When the report detection platform verifies specific information fields in the report to be verified, it obtains the specific information fields, parses them to obtain the matching field type, and matches the matching field type with the information in the digital digest corresponding to the report to be verified in the blockchain ledger. It also obtains the local fields that need to be verified as specified by the verification party when submitting the request (such as "verify only the key variant site EGFR:NM_005228.4:exon21:c.2573T>G:p.L858R" or "verify only the sequencing platform information"). It parses the local field type of the local field that needs to be verified and matches it with the sub-digest information in the corresponding on-chain digital digest (e.g., the key variant site corresponds to the on-chain sub-Merkle root, and the sequencing platform corresponds to the on-chain sequencing platform information digest).

[0096] If a match is successful, the module generates a matching path from the hash node of the specific information field in the digital digest to the root of the multi-level hash. Based on the position of the local field in the Merkle tree (digital digest), the module extracts the complete path node hash (i.e., verification path) from the sub-hash of the local field to the root of the multi-level hash. For example, when verifying a mutation site, the module extracts the sub-hash of the site, the sub-hash of sibling sites at the same level, the aggregate hash of the previous level, and so on, up to the root of the multi-level hash, to form path proof data.

[0097] Based on the standardized hash value of a specific information field, verification and proof data for that specific information field is generated. The standardized hash value is extracted from the digital digest of that specific information field. The standardized hash value corresponding to this local field (which can be a sub-hash of a sequencing platform or a single variant site) is directly extracted to form local proof data.

[0098] Following the steps described above for forming verification data for a specific information field, in some optional implementations, the storage verification method further includes:

[0099] The verification party calculates the hash value of a specific information field based on the verification proof data to obtain a first preset hash value. It then checks whether the first preset hash value matches the standardized hash value; if they match, the verification is successful. Alternatively, based on the matching path, it performs aggregation calculations layer by layer from the hash node to the multi-level hash root to determine a second preset hash value. It then checks whether the second preset hash value matches the standardized hash value; if they match, the verification is successful. The verification party first receives proof data from the report summary verification request. This proof data includes two types: one is the path proof of the aforementioned matching path, which contains the hash values ​​of all path nodes from the local field to the multi-level hash root; the other is the aforementioned verification proof data (local proof), in which case the hash value of the field is directly received. If the received verification is a path proof, it will aggregate hash values ​​layer by layer upwards according to the Merkle tree structure, starting from the received local field, until reaching the multi-level hash root layer to obtain the second preset hash value. If the received verification is a local proof, the verification party directly uses a preset hash algorithm (such as SHA-256) to perform hash operations on the requested local field to obtain the corresponding first preset hash value. If the received verification is a path proof, determine whether the second preset hash value (after layer-by-layer aggregation) is consistent with the corresponding data stored on the chain; if the received verification is a partial proof, ensure that the single field hash is consistent with the on-chain data; if the above comparison and judgment pass, it is confirmed that the partial field has not been tampered with.

[0100] After comparison and judgment, it is clear whether "the specified field has passed verification" or "the specified field has been tampered with", and it is also marked that "this result is only valid for the specified field and does not cover other content in the report"; if the verifier needs to expand the verification scope, the full verification process can be triggered.

[0101] During the verification process, the verifier can verify the consistency between the path proof or partial proof generated from the verified information and the digital digest stored on the chain, thereby completing the verification without obtaining the complete original report. Path proof or partial proof is only one optional verification method, and this application is not limited to a specific proof algorithm.

[0102] In the aforementioned method, the original report and detailed testing data are stored in an off-chain secure storage system, while the blockchain ledger only stores summary information related to verification. This approach ensures report verifiability while reducing the risk of sensitive testing data being uploaded to the blockchain, thus enhancing the overall privacy protection capabilities of the system. The method described in this application further supports a control mechanism involving regulatory agencies. Upon receiving a control instruction from an authoritative institution, the version status of the target report can be revoked or marked with a regulatory label, and the corresponding status change record can be written to the blockchain ledger to support regulatory audits and accountability. This application further introduces a control mechanism involving regulatory agencies, ensuring that report version management not only possesses technical credibility but also regulatory compliance.

[0103] The blockchain ledger stores only the minimum necessary report summary information for verification, and does not directly store the original report or complete test data. "Complete test data" may include, but is not limited to:

[0104] (1) Raw sequencing data and intermediate files: FASTQ, BAM, VCF, CNV / Fusion result files, quality control reports (Q30, coverage, repetition rate, etc.);

[0105] (2) Sensitive information about the sample and the examinee: patient's name / ID number / visit number, department to which the sample was sent, sample collection time, sample storage conditions, etc.;

[0106] (3) Detailed analysis process: Reference genome version (hg19 / hg38), alignment software and version, filtering threshold, variant call parameters, etc.;

[0107] (4) Full text of clinical explanations and recommendations: evidence grading, medication recommendations, guideline references, interpretations, follow-up recommendations, etc.

[0108] The aforementioned data is preferably stored in off-chain encrypted form, with only the smallest fields directly related to "verification" being uploaded to the blockchain, in order to balance privacy and verifiability.

[0109] In some embodiments, after generating a test report, the testing agency generates a corresponding digital digest and completes its signature. The digital digest is written to the blockchain notarization module, which then writes it to the consortium blockchain ledger. Subsequently, when the report needs to be modified due to database updates or review, a new version association record is established based on the previous version digest.

[0110] When hospitals or regulatory agencies require report verification, they can submit a verification request. By comparing the on-chain summary with the locally generated summary, the authenticity and version status of the report can be confirmed. Those skilled in the art can make various equivalent substitutions or modifications to the above embodiments without departing from the methodological logic of this application; all such substitutions or modifications should fall within the protection scope of this application.

[0111] To enable those skilled in the art to better understand the technical solution of this application, the implementation process of the storage and verification method for the test report of this application will be described in detail below with reference to specific embodiments.

[0112] This application also provides a storage verification device for test reports. It should be noted that this storage verification device for test reports can be used to execute the storage verification method for test reports provided in this application. This device is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that performs a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0113] The storage and verification device for the test report provided in the embodiments of this application will be described below.

[0114] Figure 3 This is a schematic diagram of a storage and verification device for a test report according to an embodiment of this application. Figure 3As shown, the device includes: an acquisition module 10, used to acquire core information of the test report, the core information including at least: the identifier of the test report, the test platform information, the original hash value of the test report, key test result information, and report generation time information, wherein the identifier of the test report includes the first number of the test report and the salted hash of the sample identifier of the test report, the key test result information includes the key mutation sites detected and the multi-layer hash root, and the report generation time information includes the generation timestamp; a generation module 20, used to generate a digital digest of the test report based on the core information; a signature module 30, used to digitally sign the digital digest by the signatory of the test report to generate a digital signature; and a control module 40, used to control multiple report detection platform bases. The system performs target verification on the core information, digital digest, and digital signature of the test report. Target verification includes verifying the legitimacy of the signing entity and the validity of the digital signature. A writing module 50 writes the digital digest and its associated digital signature into the blockchain ledger when the target verification results from multiple report testing platforms indicate successful verification. A verification module 60, upon receiving a verification request for a report to be verified from a report testing platform, verifies the report to be verified in the blockchain ledger based on the report's identifier and core information, obtaining a verification result. The verification result indicates successful verification if the report to be verified matches any test report in the blockchain ledger.

[0115] As an optional scheme, the control module includes a first sub-verification module, a second sub-verification module, a third sub-verification module, a first sub-determination module, a first sub-decryption module, a first sub-generation module, and a first sub-judgment module. The first sub-verification module verifies whether the signer of the test report is a legitimate entity based on the signer's certificate hash corresponding to the test report and the registration record in the consortium blockchain's identity authentication system. The second sub-verification module, if the signer of the test report is verified to be a legitimate entity, verifies whether the signer has valid qualifications based on the digital certificate of the test report. The third sub-verification module, if the signer has valid qualifications, verifies whether the signer has valid qualifications based on the signer's public key and... The signature certificate hash is used to verify the consistency of the signature subject's identity association. The first sub-determination module is used to determine that the signature subject is a legitimate subject if the identity association of the signature subject is consistent. The first sub-decryption module is used to decrypt the original hash value according to the signature subject's public key to obtain the hash value of the decrypted detection report. The first sub-generation module is used to generate the target hash value according to the digital digest, the original hash value of the detection report, and the generation timestamp according to the first preset rule. The first sub-judgment module is used to determine whether the hash value of the target hash value and the hash value of the original hash value are consistent. If the hash value of the target hash value and the hash value of the decrypted detection report are consistent, the original hash value is a valid signature.

[0116] In one optional embodiment, the storage verification device further includes a first judgment module and a second judgment module. The first judgment module is used to determine whether the core information meets the preset information requirements. If the core information does not meet the preset information requirements, the verification result indicates verification failure. The second judgment module is used to determine whether the data format of the information in the core information meets the preset standard format if the core information meets the preset information requirements. If the data format does not meet the preset standard format, the data format of the information that does not meet the preset standard format is corrected.

[0117] In one optional scheme, the storage verification device further includes a first acquisition module and a first establishment module. The first acquisition module is used to acquire the second number of the previous version of the test report, the timestamp of the test report being written into the blockchain ledger, and the status information of the test report, including valid, replaced, and revoked. The first establishment module is used to establish the association relationship of the test report based on the second number, timestamp, first number, and status information. The association relationship represents the relationship between the test report and the previous version of the test report.

[0118] An optional scheme, the first establishment module includes a third sub-judgment module, a fourth sub-judgment module, a fifth sub-judgment module, a sixth sub-judgment module, and a first sub-establishment module. The third sub-judgment module is used to determine whether there is a number in the blockchain ledger identical to the first number, and whether the naming of the first number meets preset naming requirements. The fourth sub-judgment module is used to determine whether the test report is an updated version if there is no number in the blockchain ledger identical to the first number and the naming of the first number meets preset naming requirements. The fifth sub-judgment module is used to determine whether the status information of the previous version of the test report is revoked if the test report is an updated version. The sixth sub-judgment module is used to determine whether the previous version of the test report has been properly stored in the blockchain ledger if the status information of the previous version of the test report is not revoked. The first sub-establishment module is used to establish a relationship between the test report and the previous version of the test report if the previous version of the test report has been properly stored in the blockchain ledger.

[0119] In one optional scheme, the verification module includes a first sub-acquisition module, a seventh sub-judgment module, an eighth sub-judgment module, a ninth sub-judgment module, and a tenth sub-judgment module. The first sub-acquisition module acquires the core information of the report to be verified and determines whether the core information meets preset information requirements. If the core information does not meet the preset information requirements, the verification fails. The seventh sub-judgment module, if the core information meets the preset information requirements, determines whether the identification information of the report to be verified has a corresponding digital digest in the blockchain ledger. If the identification information does not have a corresponding digital digest in the blockchain ledger, the verification fails. The identification information includes the identifier of the report to be verified, or it includes the sample identifier salted hash and version information of the report to be verified. Version information includes the report identifier and status information of the previous version of the report to be verified; the eighth sub-judgment module is used to determine whether the first multi-level hash root of the report to be verified is consistent with the second multi-level hash root of the digital digest corresponding to the report to be verified in the blockchain ledger, provided that the identifier information of the report to be verified has a corresponding digital digest; the ninth sub-judgment module is used to generate a target multi-level hash root by taking some core information of the report to be verified according to the second preset rule, provided that the first multi-level hash root is consistent with the second multi-level hash root; the tenth sub-judgment module is used to determine whether the target multi-level hash root is consistent with the second multi-level hash root, and verification is successful if the target multi-level hash root is consistent with the second multi-level hash root.

[0120] In one optional scheme, the storage verification device further includes a first matching module, a first generation module, and a second generation module. The first matching module is used to obtain the specific information field when the report detection platform verifies the specific information field of the report to be verified, parse the specific information field to obtain the matching field type of the specific information field, and match the matching field type with information in the digital digest corresponding to the report to be verified in the blockchain ledger. The first generation module is used to generate a matching path from the hash node of the specific information field in the digital digest to the multi-level hash root if the match is successful. The second generation module is used to form verification proof data for the specific information field based on the standardized hash value of the specific information field, where the standardized hash value is extracted from the digital digest.

[0121] In one optional scheme, the storage verification device further includes a first determining module, a third judging module, and a second determining module. The first determining module is used to calculate the hash value of a specific information field based on the verification proof data to obtain a first preset hash value. The third judging module is used to judge whether the first preset hash value is consistent with the standardized hash value. If they are consistent, the verification is successful. The second determining module is used to perform aggregation calculations layer by layer from the hash node to the multi-level hash root according to the matching path to determine the second preset hash value. It also judges whether the second preset hash value is consistent with the standardized hash value. If they are consistent, the verification is successful.

[0122] The storage and verification device for the test report includes a processor and a memory. The aforementioned acquisition modules are all stored as program modules in the memory, and the processor executes these program units stored in the memory to achieve the corresponding functions. All of the aforementioned modules are located in the same processor; alternatively, the modules may be located in different processors in any combination.

[0123] The processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured, and adjusting kernel parameters can address the difficulty in verifying the authenticity of test reports during their circulation across multiple institutions.

[0124] The memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0125] This invention provides a computer-readable storage medium including a stored program, wherein the program, when running, controls the device where the computer-readable storage medium is located to execute a storage verification method for a test report.

[0126] Specifically, the methods for storing and verifying test reports include:

[0127] Step S1: Obtain the core information of the test report. The core information includes at least the following: the identifier of the test report, the test platform information, the original hash value of the test report, the key test result information, and the report generation time information. The identifier of the test report includes the first number of the test report and the salted hash of the sample identifier of the test report. The key test result information includes the key variant sites and the multi-layer hash root. The report generation time information includes the generation timestamp.

[0128] Step S2: Generate a digital summary of the test report based on the core information;

[0129] Step S3: The signatory of the test report digitally signs the digital digest to generate a digital signature;

[0130] Step S4: Control multiple report detection platforms to perform target verification on the detection report based on the core information, digital digest and digital signature of the detection report. The target verification includes: verifying the legitimacy of the signing subject and the validity of the digital signature.

[0131] Step S5: If the target verification results from multiple report detection platforms indicate that the verification has passed, write the digital digest and its associated digital signature into the blockchain ledger.

[0132] Step S6: Upon receiving a verification request from the report testing platform for the report to be verified, the report to be verified is verified in the blockchain ledger based on the identifier and core information of the report to be verified, and a verification result is obtained. If the report to be verified matches any test report in the blockchain ledger, the verification result indicates successful verification.

[0133] This invention provides a device including a processor, a memory, and a program stored in the memory and executable on the processor. When the processor executes the program, it performs at least the following steps: acquiring core information of a test report, the core information including at least: the identifier of the test report, testing platform information, the original hash value of the test report, key test result information, and report generation time information. The identifier of the test report includes the first number of the test report and the salted hash of the sample identifier of the test report; the key test result information includes key variant sites and the multi-level hash root; and the report generation time information includes a generation timestamp. Based on the core information, a digital digest of the test report is generated; and the digital digest is digitally signed by the signatory of the test report. The process involves: generating digital signatures; controlling multiple report testing platforms to perform target verification on the test reports based on their core information, digital digests, and digital signatures. Target verification includes verifying the legitimacy of the signing entity and the validity of the digital signature. If the target verification results from multiple report testing platforms indicate successful verification, the digital digest and its associated digital signature are written to the blockchain ledger. Upon receiving a verification request for a report to be verified from a report testing platform, the system verifies the report to be verified in the blockchain ledger based on its identifier and core information, obtaining a verification result. If the report to be verified matches any test report in the blockchain ledger, the verification result indicates successful verification. The devices mentioned in this document can be servers, PCs, tablets, mobile phones, etc.

[0134] This application also provides a computer program product, which, when executed on a data processing device, is suitable for executing an initialization program having at least the following method steps: obtaining core information of a test report, the core information including at least: the identifier of the test report, test platform information, the original hash value of the test report, key test result information, and report generation time information, wherein the identifier of the test report includes the first number of the test report and the sample identifier salting hash of the test report, the key test result information includes key variant sites and multi-layer hash root, and the report generation time information includes a generation timestamp; generating a digital digest of the test report based on the core information; and having the signing entity of the test report digitally sign the digital digest to generate a digital signature; The system controls multiple report testing platforms to perform target verification on the test reports based on the core information, digital digest, and digital signature of the test reports. Target verification includes: verifying the legitimacy of the signing entity and the validity of the digital signature; if the target verification results from multiple report testing platforms indicate that the verification is successful, the digital digest and its associated digital signature are written into the blockchain ledger; upon receiving a verification request for a report to be verified from a report testing platform, the system verifies the report to be verified in the blockchain ledger based on the identifier and core information of the report to be verified, obtaining a verification result. If the report to be verified matches any test report in the blockchain ledger, the verification result indicates successful verification.

[0135] It is obvious to those skilled in the art that the modules or steps of the present invention described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those described herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the present invention is not limited to any particular combination of hardware and software.

[0136] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0137] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0138] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0139] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0140] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0141] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0142] Computer-readable media include both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0143] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0144] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

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

Claims

1. A method for storing and verifying test reports, characterized in that, include: The core information of the test report is obtained, which includes at least: the identifier of the test report, the test platform information, the original hash value of the test report, key test result information, and report generation time information. The identifier of the test report includes the first number of the test report and the sample identifier salting hash of the test report. The key test result information includes key variant sites and multi-level hash root. The report generation time information includes the generation timestamp. The test report is an NGS test report. Based on the core information, a digital summary of the test report is generated; The digital signature is generated by the signatory of the test report digitally signing the digital digest; Multiple report detection platforms are controlled to perform target verification on the detection report based on the core information of the detection report, the digital digest, and the digital signature. The target verification includes verifying whether the legality conditions of the signature subject and the validity conditions of the digital signature are both met. If the target verification results from multiple report detection platforms indicate that the verification has passed, the digital digest and the associated digital signature are written into the blockchain ledger; Upon receiving a verification request from the report detection platform for a report to be verified, the report to be verified is verified in the blockchain ledger based on the identifier and core information of the report to be verified, and a verification result is obtained. If the report to be verified matches any of the detection reports in the blockchain ledger, the verification result indicates successful verification. The storage verification method further includes: when the report detection platform verifies a specific information field of the report to be verified, obtaining the specific information field, parsing the specific information field to obtain a matching field type of the specific information field, and matching the matching field type with information in the digital digest corresponding to the report to be verified in the blockchain ledger; if the match is successful, generating a matching path from the hash node of the specific information field in the digital digest to the multi-level hash root; and forming verification proof data for the specific information field based on the standardized hash value of the specific information field, wherein the standardized hash value is extracted from the digital digest of the specific information field. The hash value of the specific information field is calculated based on the verification data to obtain a first preset hash value; it is then determined whether the first preset hash value is consistent with the standardized hash value. If they are consistent, the verification is successful. Alternatively, based on the matching path, aggregation calculation is performed layer by layer from the hash node to the multi-layer hash root to determine a second preset hash value. The second preset hash value is then determined whether it is consistent with the standardized hash value. If they are consistent, the verification is successful.

2. The storage verification method according to claim 1, characterized in that, The target verification of the test report includes: Based on the signer certificate hash corresponding to the test report and the filing record in the consortium blockchain's identity authentication system, the signature subject of the test report is verified to be a legitimate subject; If the signatory of the test report is verified to be a legitimate entity, the validity of the signatory's qualifications is verified based on the digital certificate of the test report. If the signing entity has been verified to have the valid qualifications, the identity association consistency of the signing entity is verified based on the public key of the signing entity and the public key of the signature certificate hash. If the identity associations of the signing entities are consistent, the signing entity is determined to be a legitimate entity. The original hash value is decrypted using the public key of the signing entity to obtain the hash value of the decrypted detection report; The digital digest, the original text hash value, and the generated timestamp are used to generate a target hash value according to a first preset rule; Determine whether the target hash value and the original hash value are consistent. If the target hash value and the hash value of the decrypted detection report are consistent, the original hash value is a valid signature.

3. The storage verification method according to claim 1, characterized in that, The storage verification method further includes: Determine whether the core information meets the preset information requirements. If the core information does not meet the preset information requirements, the verification result indicates verification failure. If the core information meets the preset information requirements, determine whether the data format of the information in the core information meets the preset standard format. If the data format does not meet the preset standard format, correct the data format of the information that does not meet the preset standard format.

4. The storage verification method according to claim 1, characterized in that, The storage verification method further includes: Obtain the second number of the previous version of the test report, the timestamp of the test report being written into the blockchain ledger, and the status information of the test report, including valid, replaced, and revoked; Based on the second number, the timestamp, the first number, and the status information, an association relationship is established between the test report and the previous version of the test report.

5. The storage verification method according to claim 4, characterized in that, The step of establishing the association relationship of the detection report based on the second number, the timestamp, the first number, and the status information includes: Determine whether there is a number in the blockchain ledger that is the same as the first number, and determine whether the naming of the first number meets the preset naming requirements; If it is determined that there is no number in the blockchain ledger that is the same as the first number and the naming of the first number meets the preset naming requirements, then it is determined whether the detection report is an updated version; If the detection report is determined to be the updated version, determine whether the status information of the previous version of the detection report is "revoked"; If it is determined that the status information of the previous version of the test report is not revoked, then it is determined whether the previous version of the test report has been stored in the blockchain ledger. If it is determined that the previous version of the test report has been stored in the blockchain ledger, the association between the test report and the previous version of the test report is established.

6. The storage verification method according to claim 5, characterized in that, Upon receiving a verification request from the report detection platform for a report to be verified, the process involves verifying the report in the blockchain ledger based on its identifier and core information, yielding a verification result, including: Obtain the core information of the report to be verified, and determine whether the core information meets the preset information requirements. If the core information does not meet the preset information requirements, the verification result fails. If the core information meets the preset information requirements, it is determined whether the identification information of the report to be verified has a corresponding digital digest in the blockchain ledger. If it is determined that the identification information of the report to be verified does not have a corresponding digital digest in the blockchain ledger, the verification result fails. The identification information includes the identification of the report to be verified, or the identification information includes the sample identification salted hash and version information of the report to be verified. The version information includes the report identification of the previous version of the report to be verified and the status information of the previous version of the report to be verified. If it is determined that the identification information of the report to be verified has a corresponding digital digest in the blockchain ledger, it is determined whether the first multi-level hash root of the report to be verified is consistent with the second multi-level hash root of the digital digest corresponding to the report to be verified in the blockchain ledger; If the first multi-level hash root is found to be consistent with the second multi-level hash root, the core information of the report to be verified is used to generate a target multi-level hash root according to the second preset rule. Determine whether the target multi-level hash root is consistent with the second multi-level hash root. If the target multi-level hash root is consistent with the second multi-level hash root, the verification is successful.

7. A storage and verification device for a test report, characterized in that, The acquisition module is used to acquire the core information of the test report. The core information includes at least: the identifier of the test report, the test platform information, the original hash value of the test report, key test result information, and report generation time information. The identifier of the test report includes the first number of the test report and the sample identifier salting hash of the test report. The key test result information includes key variant sites and multi-level hash root. The report generation time information includes the generation timestamp. The test report is an NGS test report. The generation module is used to generate a digital summary of the test report based on the core information. The signature module is used to digitally sign the digital digest by the signatory of the detection report, thereby generating the digital signature; The control module is used to control multiple report detection platforms to perform target verification on the detection report based on the core information of the detection report, the digital digest, and the digital signature. The target verification includes verifying whether the legality conditions of the signature subject and the validity conditions of the digital signature are both met. The writing module is used to write the digital digest and the associated digital signature into the blockchain ledger when the target verification results from multiple report detection platforms indicate that the verification has passed. The verification module is used to verify the report to be verified in the blockchain ledger based on the identifier and core information of the report to be verified when the report detection platform receives a verification request for the report to be verified. The verification result indicates successful verification if the report to be verified matches any of the detection reports in the blockchain ledger. The storage verification device further includes a first matching module, a first generation module, and a second generation module. The first matching module is used to, when the report detection platform verifies a specific information field of the report to be verified, obtain the specific information field, parse the specific information field to obtain a matching field type, and match the matching field type with information in the digital digest corresponding to the report to be verified in the blockchain ledger. The first generation module is used to, if the match is successful, generate a matching path from the hash node of the specific information field in the digital digest to the multi-layer hash root. The second generation module is used to generate verification proof data for the specific information field based on the standardized hash value of the specific information field, where the standardized hash value is extracted from the digital digest. The storage verification device further includes a first determining module and a third judging module. The first determining module is used to calculate the hash value of the specific information field based on the verification proof data to obtain a first preset hash value. The third judging module is used to judge whether the first preset hash value is consistent with the standardized hash value. If they are consistent, the verification is successful. Alternatively, the storage verification device further includes a second determining module. The second determining module is used to perform aggregation calculations layer by layer from the hash node to the multi-layer hash root according to the matching path to determine a second preset hash value. It then judges whether the second preset hash value is consistent with the standardized hash value. If they are consistent, the verification is successful.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein, when the program is executed, it controls the device containing the computer-readable storage medium to perform the storage verification method for the test report as described in any one of claims 1 to 6.

Images