Block chain-based blood safety whole-course tracing system and method

Abstract

The invention discloses a blood safety whole-course tracing system and method based on a block chain, and particularly relates to the technical field of medical information tracing. The method comprises the following steps: performing structured preprocessing on blood information data generated in the whole process from collection, inspection, storage, transportation to use of blood to generate a blood data set, and executing on-chain data uploading processing to generate a blood data identifier; meanwhile, the blood data set is stored in an off-chain database; performing data version change analysis on the update event of the blood data set in the under-chain database to generate a blood data change log; performing data consistency comparison based on the blood data change log; dynamically updating the identifier based on a consistency verification result, and generating an updated on-chain blood data identifier; and whole-process blood tracing query is performed based on the updated on-chain blood data identifier, so that tamper-proof evidence storage and whole-process credible tracing of the blood data are realized, and data transparency and safety supervision capability in the blood circulation process are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of medical information traceability, and more particularly to a blood safety whole-process traceability system and method based on a block chain. BACKGROUND

[0002] Current blood safety traceability mainly relies on centralized databases or traditional information systems to record and manage blood circulation information, and there are problems such as inconsistency between on-chain and off-chain data, which makes it difficult to meet the authenticity, integrity and traceability requirements of blood from collection to use. When blood information changes, there is a lack of a trusted mechanism to record and verify the change process, which can easily lead to a disconnection between on-chain stored information and off-chain business data, affecting blood use safety and management responsibility traceability. SUMMARY

[0003] In order to overcome the above-mentioned defects of the prior art, the embodiments of the present application provide a blood safety whole-process traceability system and method based on a block chain to solve the problems raised in the background art.

[0004] To achieve the above-mentioned purpose, the present application provides the following technical scheme:

[0005] A blood safety whole-process traceability method based on a block chain, comprising the following steps:

[0006] S1, collecting blood information data generated from the whole process of blood collection to use, and structurally preprocessing the blood information data to generate a blood data set;

[0007] S2, performing on-chain data upload processing according to the blood data set to generate on-chain stored blood data identifiers, and storing the blood data set to an off-chain database;

[0008] S3, real-time monitoring of update events of the blood data set in the off-chain database, and performing data version change analysis on the update events to generate a blood data change log;

[0009] S4, based on the blood data change log, updating the blood data set in the off-chain database, and through data consistency comparison, verifying the consistency between the blood data set in the off-chain database and the on-chain stored blood data identifiers;

[0010] S5, based on the consistency verification result, performing dynamic update on the on-chain stored blood data identifiers to generate updated on-chain blood data identifiers;

[0011] S6, based on the updated on-chain blood data identifiers, performing blood whole-process traceability query.

[0012] In one preferred embodiment, S1 specifically comprises:

[0013] Collect blood information data generated in the whole process from the collection link, the inspection link, the storage link, the transportation link to the use link;

[0014] Structurally pre-process the collected blood information data, including data field classification, field format uniform conversion, data abnormal value identification and correction, to generate a blood data set.

[0015] In a preferred embodiment, S2, specifically:

[0016] Based on the hash algorithm, the blood data set is calculated for data summary to obtain a data summary value representing the blood data set;

[0017] According to the transaction packaging rules of the blockchain, the data summary value is uploaded to the blockchain in the form of a smart contract, and the blood data identifier is generated after consensus verification;

[0018] The blood data set is stored in the off-chain database through distributed storage, and the mapping association relationship between the on-chain stored blood data identifier and the blood data set in the off-chain database is established.

[0019] In a preferred embodiment, S3, specifically:

[0020] Real-time monitoring of data update events occurring in the blood data set in the off-chain database, including the operation type and operation time information of the blood data set data field content addition, modification or deletion;

[0021] The blood data set before and after the update is compared by field to analyze the data version change, identify the data field in the blood data set that has changed, and the data content before and after the data field change;

[0022] Based on the data field in the blood data set that has changed and the data content before and after the data field change, a blood data change log is generated.

[0023] In a preferred embodiment, S4, specifically:

[0024] Based on the data field in the blood data set that has changed and the data content after the data field change, the blood data set in the off-chain database is updated;

[0025] Based on the hash algorithm, the blood data set in the off-chain database is recalculated for data summary to obtain a data summary value corresponding to the updated blood data set;

[0026] The blood data identifier stored on the chain is compared with the data digest value corresponding to the updated blood data set, to determine whether the blood data identifier stored on the chain is consistent with the data digest value corresponding to the updated blood data set.

[0027] According to the data comparison result, a consistency check result is generated.

[0028] In a preferred embodiment, S5, specifically:

[0029] When the consistency check result indicates that the blood data identifier stored on the chain is inconsistent with the data digest value corresponding to the updated blood data set, the blood data identifier stored on the chain is replaced with the data digest value corresponding to the updated blood data set.

[0030] According to the transaction packaging rules of the blockchain, the updated data digest value is re-uploaded to the blockchain in the form of a smart contract, and after consensus verification, an updated blood data identifier on the chain is generated.

[0031] Based on the mapping and association relationship between the blood data identifier stored on the chain and the blood data set in the off-chain database, the mapping and association relationship between the updated blood data identifier on the chain and the updated blood data set in the off-chain database is re-established.

[0032] In a preferred embodiment, S6, specifically:

[0033] Based on the updated blood data identifier on the chain, the blood data set corresponding to the updated blood data identifier on the chain is located from the off-chain database through the mapping and association relationship between the blood data identifier stored on the chain and the blood data set in the off-chain database.

[0034] According to the blood information data in the blood data set, a full-process traceability query result of blood from the collection link to the use link is generated through data query.

[0035] On the other hand, the application provides a blood safety full-process traceability system based on a blockchain, comprising:

[0036] A data preprocessing module collects blood information data generated in the whole process from blood collection to use, and performs structured preprocessing on the blood information data to generate a blood data set.

[0037] An on-chain storage and evidence management module performs on-chain data uploading processing according to the blood data set, generates a blood data identifier stored on the chain, and stores the blood data set in an off-chain database.

[0038] A change monitoring and recording module monitors the update event of the blood data set in the off-chain database in real time, performs data version change analysis on the update event, and generates a blood data change log.

[0039] A consistency verification module updates the blood data set in the off-chain database based on the blood data change log, and verifies the consistency between the blood data set in the off-chain database and the blood data identifier stored on the chain through data consistency comparison.

[0040] An on-chain identifier updating module dynamically updates the blood data identifier stored on the chain based on the consistency verification result, and generates an updated on-chain blood data identifier.

[0041] A traceability query output module performs blood full-process traceability query based on the updated on-chain blood data identifier.

[0042] The technical effects and advantages of the blood safety full-process traceability system and method based on the blockchain are as follows:

[0043] By collecting blood information data generated in the whole process from blood collection to use, the data integrity is ensured; by storing the blood information data on the chain and storing it off-chain, the data tamper resistance and high availability are ensured; the update event of the blood data set in the off-chain database is monitored in real time, the blood data change log is generated, and the data change is traceable; through data consistency comparison, the consistency between the blood data set in the off-chain database and the blood data identifier stored on the chain is verified, and the data accuracy is improved; the blood data identifier stored on the chain is dynamically updated, and the on-chain and off-chain data are kept consistent; based on the updated on-chain blood data identifier, blood full-process traceability query is performed, the blood management transparency and safety are improved, the blood data credibility, verifiability and dynamic consistency are enhanced, and the problems of data fragmentation, uncontrollable update and off-chain disconnection in traditional blood traceability are effectively solved. BRIEF DESCRIPTION OF DRAWINGS

[0044] Figure 1 The figure is a blood safety full-process traceability method based on the blockchain.

[0045] Figure 2 The figure is a structure diagram of the blood safety full-process traceability system based on the blockchain. DETAILED DESCRIPTION

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

[0047] Embodiment 1

[0048] Figure 1 This invention presents a blockchain-based method for end-to-end traceability of blood safety, comprising the following steps:

[0049] S1 collects blood information data generated throughout the entire process from blood collection to use, and performs structured preprocessing on the blood information data to generate a blood dataset;

[0050] S2, perform on-chain data upload processing based on the blood dataset, generate on-chain blood data identifiers, and store the blood dataset in the off-chain database;

[0051] S3 monitors the update events of the blood dataset in the off-chain database in real time, performs data version change analysis on the update events, and generates a blood data change log.

[0052] S4, based on the blood data change log, updates the blood dataset in the off-chain database, and verifies the consistency between the blood dataset in the off-chain database and the blood data identifier stored on the chain through data consistency comparison.

[0053] S5, based on the consistency verification result, dynamically updates the blood data identifier stored on the chain to generate the updated blood data identifier on the chain.

[0054] S6 enables full-process traceability queries of blood based on updated on-chain blood data identifiers.

[0055] S1 collects blood information data generated throughout the entire process from blood collection to use, and performs structured preprocessing on the blood information data to generate a blood dataset, including:

[0056] Blood information data generated throughout the entire process of blood collection, from collection, testing, storage, transportation to use;

[0057] Specifically, blood information data refers to the data generated throughout the entire process of blood collection, testing, storage, transportation and use, including all the attribute and characteristic information of blood generated at each stage.

[0058] For example, blood information data generated during the collection process includes, but is not limited to, blood unit number, donor identification information, blood type information, collection date and time, and the name of the blood collection institution; blood information data generated during the testing process includes the results of various indicators for blood safety testing, testing date, and the name of the testing institution; blood information data generated during the storage process includes storage temperature, storage location, storage start and end time, storage device number, and the name of the storage institution; blood information data generated during the transportation process includes the origin and destination of transportation, transportation route, transportation start and end time, temperature and humidity conditions of the transportation environment, the name of the transportation institution, and the identification of the transportation vehicle; blood information data generated during the use process includes the patient's identification, the patient's clinical diagnosis, the time of blood use, the name of the medical institution using the blood, and the identification information of the personnel responsible for administering the transfusion.

[0059] The blood information data generated at each of the above stages fully records the entire process of blood from collection to clinical use, ensuring the continuity and effectiveness of blood safety traceability. The blood information data is acquired by using appropriate data collection equipment at each stage of the blood flow process, including identification systems, barcode scanners, biometric identification devices, and environmental monitoring sensors. The data is then transmitted to the blood management system via a computer network. For example, at the blood collection stage, blood collection personnel scan the barcode on the blood packaging bag to read the donor's identity information, completing the collection and association of the blood unit number and donor information; at the transportation stage, temperature and humidity sensors on the transport vehicle collect temperature and humidity data of the transportation environment.

[0060] The collected blood information data is preprocessed in a structured manner to generate a blood dataset;

[0061] Specifically, structured preprocessing involves systematically processing the collected blood information data to store various types of blood information data in a unified and standardized structure, forming a data set suitable for on-chain evidence storage and traceability. Structured preprocessing of blood information data includes data field classification, unified field format conversion, and outlier identification and correction.

[0062] Data field classification refers to categorizing blood information data obtained from different stages according to its type, source, meaning, and purpose, assigning the data to the corresponding database fields. For example, blood information data generated during the collection stage can be categorized as "collection data," "testing data," or "storage data." Similarly, blood unit numbers generated during collection can be assigned to the "collection stage" field, while transportation route information generated during collection can be assigned to the "transportation stage" field.

[0063] Unified field format conversion refers to standardizing the data storage format and units for all fields in the categorized blood information data, ensuring that data fields from different sources and in different formats meet a unified standard. For example, date data from different stages of blood collection, testing, storage, transportation, and usage is uniformly converted to a "year-month-day hour:minute:second" time format; temperature data during storage and transportation is uniformly converted to degrees Celsius and accurate to one decimal place to ensure data format consistency and standardization.

[0064] Outlier identification and correction refers to verifying numerical values, text, or other data in data fields to identify suspected errors or abnormal data during the data recording process. For example, when identifying abnormal data in the temperature field during transportation that is far above or below the normal transportation temperature range (e.g., the normal range is 2℃-8℃, but the abnormal display is 50℃ or -20℃), corrections or marking of the abnormality are made through methods such as verification, remeasurement, or manual correction to ensure the authenticity and reliability of the data.

[0065] After the above structured preprocessing, the obtained data forms a structured blood dataset, which can fully reflect the entire process of blood from collection to use, ensuring the data standardization and integrity when blood data is stored on the blockchain.

[0066] S2, based on the blood dataset, performs on-chain data upload processing, generates on-chain blood data identifiers for evidence storage, and simultaneously stores the blood dataset in an off-chain database, including:

[0067] A data digest is calculated based on a hash algorithm to obtain a data digest value representing the blood dataset.

[0068] Specifically, a hash algorithm takes all blood information data in a blood dataset as input, processes it through specific mathematical functions and transformations, and generates a fixed-length output value—a data digest value—that uniquely identifies the input data. The data digest value is deterministic, unique, and tamper-proof, uniquely and accurately representing all the information content of the blood dataset. If any data field or field content in the input blood dataset changes, the data digest value calculated by the hash algorithm will change, thus ensuring the authenticity and tamper-proof nature of the data. To ensure the consistency and stability of the hash algorithm calculation, the SHA-256 hash algorithm is used for data digest calculation, and the output data digest value has a fixed length of 256 bits. In practical applications, the output data digest value is usually represented in hexadecimal form, for example, as a hexadecimal string of length 64 characters.

[0069] According to the transaction packaging rules of the blockchain, the data digest value is uploaded to the blockchain in the form of a smart contract, and after consensus verification, a blood data identifier stored on the chain is generated.

[0070] Specifically, the transaction packaging rules of blockchain are as follows: when a node in the blockchain network receives an uploaded data digest value, it first encapsulates the data digest value into a transaction data unit. Then, according to a pre-defined smart contract within the blockchain network, the transaction data unit undergoes rule-based format and validity checks to ensure it conforms to network standards before being included in the block. The smart contract method refers to a programmable rule script pre-deployed in the blockchain network, which automatically executes the verification, processing, and storage of transaction data. After the transaction data unit is verified by the smart contract, consensus verification is performed according to the blockchain's consensus mechanism (such as proof-of-stake or proof-of-work). Consensus verification involves multiple nodes in the blockchain network independently verifying the authenticity, format correctness, and compliance with the predefined rules of the smart contract for the transaction data unit. If the verification is successful, the block containing the transaction data unit is added to the blockchain ledger, thus forming an immutable evidence record. In the transaction data unit that has passed consensus verification and been uploaded to the chain, the data digest value serves as the on-chain evidence identifier, stored in the blockchain ledger, and marked and located with a unique transaction number within the blockchain.

[0071] By storing blood datasets in an off-chain database through distributed storage, a mapping relationship is established between the blood data identifiers stored on the blockchain and the blood datasets in the off-chain database.

[0072] Specifically, distributed storage technology involves distributing blood datasets across multiple distributed storage nodes according to predetermined data splitting rules and redundancy backup mechanisms, forming a redundant backup and highly reliable storage environment. Off-chain databases refer to database systems independent of on-chain storage, used to store the actual data content corresponding to the data digest value, i.e., the complete blood dataset. For example, the blood dataset can be split into multiple data shards and stored simultaneously on three storage nodes. If data is lost on one node, it can be recovered from other nodes, ensuring data integrity and security. Establishing a mapping relationship between on-chain notarized blood data identifiers and blood datasets in the off-chain database involves creating an on-chain / off-chain association index table or mapping table. For example, using the on-chain notarized blood data identifier as the index key, the corresponding location or address of the blood dataset is stored in the off-chain database. This allows for data tracing or verification, locating the blood dataset stored in the off-chain database based on the on-chain notarized blood data identifier, completing data consistency verification and traceability queries.

[0073] S3 monitors update events of the blood dataset in the off-chain database in real time, performs data version change analysis on the update events, and generates a blood data change log, including:

[0074] Real-time monitoring of data update events occurring in the blood dataset in the off-chain database;

[0075] Specifically, a data update event in a blood dataset refers to a database event triggered when data fields in the blood dataset stored in the off-chain database are added, modified, or deleted. For example, if the original data for the storage temperature field in the blood dataset stored in the off-chain database is "4.0℃", and after verification by staff or automation, it is found that the actual storage temperature is "4.5℃", then a modification operation is performed to change the storage temperature field from "4.0℃" to "4.5℃". This modification operation is a data update event.

[0076] Real-time monitoring captures and monitors data changes through the event triggering mechanism or transaction log mechanism of the off-chain database management system, ensuring the real-time capture of data update events in the off-chain database. For example, using database triggers or transaction log listeners, when adding, modifying, or deleting data in the blood dataset in the off-chain database, the corresponding data update event is automatically triggered, and the data update information corresponding to the data update event is captured in real time, including the data operation type (add, modify, or delete), the field names involved in the data operation, the content changes before and after the data operation, and the time of the data update operation, providing raw data evidence for data version change analysis.

[0077] By comparing the blood dataset before and after the update, we can perform data version change analysis to identify the data fields that have changed in the blood dataset and the data content before and after the data field changes.

[0078] Specifically, data version change analysis involves comparing the before and after versions of the blood dataset involved in the captured data update event. First, the blood dataset where the data update event occurred is located. Then, the pre-update and post-update versions of the blood dataset are compared one by one according to their data structure. The changed data fields are identified field by field, indicating the differences in content of these fields before and after the data update event. For example, in the pre-update version of the blood dataset, the transportation route field read "Central Blood Bank to People's Hospital," while in the post-update version, this field reads "Central Blood Bank to Central Hospital." During the data version change analysis, the change in the transportation route field is identified through field-by-field comparison, and the pre- and post-update data are marked as "Central Blood Bank to People's Hospital" and "Central Blood Bank to Central Hospital," respectively.

[0079] The data version change analysis process employs field-level comparison. This involves traversing all fields in the blood dataset and comparing each field with its pre- and post-update versions one by one. By determining whether a field has changed and the differences in data content before and after the change, the changes at all field levels in the dataset before and after the update are identified. This ensures the comprehensiveness, accuracy, and precision of the data change analysis and provides data support for consistency verification.

[0080] Based on the data fields that have changed in the blood dataset and the data content before and after the changes, a blood data change log is generated.

[0081] Specifically, the blood data change log is a structured log document or record unit that records the history of centralized data updates in the blood dataset. It records the changes to each field involved in a data update event in the blood dataset, including but not limited to the name of the data field that was changed, the content before and after the change, the operation type (add, modify, or delete), and the time of the change operation. For example, a data update event might record "Storage Temperature field, content before change: 4.0℃, content after change: 4.5℃, operation type: modification, change time: January 10, 2024, 14:20:00"; another example is "Transportation Route field, content before change: Central Blood Bank to People's Hospital, content after change: Central Blood Bank to Central Hospital, operation type: modification, change time: January 11, 2024, 09:15:30".

[0082] Blood data change logs are stored in a structured format, such as JSON, XML, or database tables. A separate log management table or log storage module is set up in an off-chain database to store the change log data. Recording blood data change logs provides accurate and reliable evidence for on-chain data consistency verification, ensuring that the content, reasons, and process of each data update are fully preserved, enabling effective traceability and auditing.

[0083] S4, based on the blood data change log, updates the blood dataset in the off-chain database and verifies the consistency between the blood dataset in the off-chain database and the blood data identifier stored on-chain through data consistency comparison, including:

[0084] Based on the changed data fields in the blood dataset and the data content after the data field changes, the blood dataset in the off-chain database is updated;

[0085] Specifically, the blood data change log records the changed data fields in the blood dataset in the off-chain database, along with the updated data content. Updating the blood dataset in the off-chain database involves adjusting or replacing the data content in the off-chain database based on the changed data fields and their updated content recorded in the blood data change log. For example, if the original blood dataset stored in the off-chain database contained the transportation route field as "Central Blood Bank to People's Hospital," and the change log determines the record to be "Central Blood Bank to Municipal Central Hospital," then the transportation route field in the off-chain database will be updated to "Central Blood Bank to Municipal Central Hospital," thus achieving accurate data updates.

[0086] For example, in a blood dataset stored in an off-chain database, the original data for the hepatitis B virus test result in the testing process was "negative." After verification and review, it was found that the data was incorrect and should be "positive." The blood data change log clearly records the change operation of this field. Therefore, during the update process, based on the data field name and the changed data content recorded in the blood data change log, the hepatitis B virus test result field in the off-chain database is clearly and accurately updated from the original "negative" to the correct "positive."

[0087] The blood dataset in the off-chain database is updated using a data location and data replacement method. That is, by using the indexing mechanism or data location mechanism of the database management system, the location of each data field that has changed is located one by one, and the changed data content recorded in the blood data change log is replaced field by field to ensure that the updated version of the blood dataset in the off-chain database accurately reflects the latest data.

[0088] Based on the hash algorithm, the updated blood dataset in the off-chain database is recalculated to obtain the data digest value corresponding to the updated blood dataset;

[0089] Specifically, the updated blood dataset from the off-chain database, including all data fields and their corresponding content from each stage (collection, testing, storage, transportation, and use), is concatenated into a unified data input string according to a predefined structural order. This string is then input into the SHA-256 hash algorithm for data digest calculation. For example, the updated blood dataset might contain data such as "Collection date: January 5, 2024, 08:30:00," and "Transportation route: Central Blood Bank to Central Hospital." These data are concatenated to form a unified, continuous data string. After SHA-256 hashing, a fixed-length 256-bit data digest value is generated, which can be represented as a 64-character hexadecimal string. The data digest value represents the updated blood dataset content; any slight change in the data will cause a change in the digest value, ensuring precise verification of data consistency.

[0090] The blood data identifier stored on the blockchain is compared with the data digest value corresponding to the updated blood dataset to determine whether the blood data identifier stored on the blockchain is consistent with the data digest value corresponding to the updated blood dataset.

[0091] Specifically, if the blood data stored on the blockchain is identified as follows:

[0092] "A5F8E9D2B6C1 F4E3D8C7B5A2E1 D6F3B4C2A1 E9F8D7C6B5A4D3C2B1E0F9A8B7C6";

[0093] The updated blood dataset, after recalculation, yielded the following data summary values:

[0094] The sequence “C1 B2A3D4E5F6A7B8C9D0E1 F2A3B4C5D6E7F8A9B0C1 D2E3F4A5B6C7D8E9F0A1B2” is compared character by character to determine if the on-chain blood data identifier is inconsistent with the updated blood dataset's corresponding data digest value. If so, it indicates that the on-chain blood data identifier has not been updated in a timely manner. If the on-chain blood data identifier is completely identical character by character to the updated blood dataset's corresponding data digest value, it indicates that the on-chain and off-chain data are consistent, and the data status is accurate.

[0095] Based on the data comparison results, generate consistency verification results;

[0096] Specifically, the consistency verification result refers to the comparison result generated through data comparison. The data comparison result specifically refers to whether the blood data identifier stored on the record chain is consistent with the data digest value corresponding to the updated blood dataset, including but not limited to consistency or inconsistency, as well as the comparison time and data digest value.

[0097] For example, record "Consistency check result: Inconsistent, comparison time: January 12, 2024, 16:45:00",

[0098] Blood data identifier stored on the blockchain:

[0099] A5F8E9D2B6C1F4E3D8C7B5A2E1 D6F3B4C2A1 E9F8D7C6B5A4D3C2B1 E0F9A8B7C6, the updated data summary values ​​for the blood dataset:

[0100] C1 B2A3D4E5F6A7B8C9D0E1F2A3B4C5D6E7F8A9B0C1 D2E3F4A5B6C7D8E9F0A1B2. The above records ensure data consistency, traceability, and auditability.

[0101] S5, based on the consistency verification result, dynamically updates the on-chain blood data identifier, generating an updated on-chain blood data identifier, including:

[0102] When the consistency verification result shows that the blood data identifier stored on the chain is inconsistent with the data digest value corresponding to the updated blood dataset, the blood data identifier stored on the chain is replaced with the data digest value corresponding to the updated blood dataset.

[0103] Specifically, if the blood data identifier stored on the blockchain is inconsistent with the data digest value corresponding to the updated blood dataset, it means that the blood data identifier stored on the blockchain does not reflect the latest data situation in the off-chain database in a timely manner. Therefore, it needs to be corrected in a timely manner to ensure that the blood data identifier stored on the blockchain can accurately represent the latest blood dataset off-chain.

[0104] Replacing the on-chain blood data identifier with the updated blood dataset data digest value means using the latest calculated data digest value from the off-chain database to replace the original on-chain blood data identifier, thereby restoring the consistency and synchronization between on-chain and off-chain data.

[0105] According to the transaction packaging rules of the blockchain, the updated data digest value is re-uploaded to the blockchain in the form of a smart contract. After consensus verification, an updated on-chain blood data identifier is generated.

[0106] Specifically, the transaction packaging rules of the blockchain are as follows: when the blockchain network receives a data digest value upload request, it encapsulates the data digest value into a transaction data unit. Then, the smart contract preset in the blockchain network automatically executes a rule-based verification and inspection process to ensure that the data format is correct and the content is valid, and the compliant data digest value is included in the block to be uploaded to the chain.

[0107] Smart contracts are pre-deployed, rule-based, automatically executing code programs on a blockchain network, characterized by automated transaction verification, data processing, and storage. Uploading data digest values ​​via smart contracts means: First, the data digest value corresponding to the latest off-chain blood dataset is encapsulated into a transaction data unit and submitted to the smart contract. The smart contract automatically performs verification according to preset rules, ensuring the transaction data unit's format and content are compliant and legal, and then submits it to the blockchain network.

[0108] Consensus verification in a blockchain network refers to the joint verification and confirmation of transaction data units by multiple nodes. Specifically, distributed nodes in the blockchain network independently verify the data unit according to a predetermined consensus mechanism (such as proof-of-stake or proof-of-work). When more than a specified proportion of nodes in the blockchain network have verified the transaction data unit and confirmed its accuracy, the transaction data unit is officially recorded in the blockchain ledger, thereby generating an updated on-chain blood data identifier, which is the on-chain storage result of the latest data digest value.

[0109] Based on the mapping relationship between the blood data identifier stored on the blockchain and the blood dataset in the off-chain database, the mapping relationship between the updated on-chain blood data identifier and the updated blood dataset in the off-chain database is re-established.

[0110] Specifically, the mapping relationship is an on-chain and off-chain association index table or mapping relationship table, which uses the blood data identifier stored on the chain as the index key to indicate the storage location or storage address of the corresponding blood dataset in the off-chain database.

[0111] Re-establishing the updated mapping relationship involves adjusting and replacing the original mapping relationship established with the old data digest value as the index key after the data digest value is updated and replaced with the latest on-chain blood data identifier as the index key, and re-establishing the relationship between the data digest value and the latest blood dataset in the off-chain database.

[0112] S6 performs full-process blood traceability queries based on the updated on-chain blood data identifiers, including:

[0113] Based on the updated on-chain blood data identifier, the blood dataset corresponding to the updated on-chain blood data identifier is located from the off-chain database by means of the mapping relationship between the on-chain blood data identifier and the blood dataset in the off-chain database.

[0114] Specifically, if the latest on-chain stored blood data is identified as...

[0115] The mapping relationship table for "C1B2A3D4E5F6A7B8C9D0E1F2A3B4C5D6E7F8A9B0C1D2E3F4A5B6C7D8E9F0A1 B2" explicitly records the storage location of the blood dataset in the off-chain database corresponding to the blood data identifier as: "Database storage node 3, storage path: / hospital / blood_db / dataset_20240112_165000.json". During data location, the updated on-chain blood data identifier is used to query the mapping relationship table, quickly and accurately finding the corresponding latest blood dataset. Through this mapping retrieval mechanism, without performing a full table scan of all off-chain blood datasets, the target off-chain dataset can be quickly located and retrieved using only the on-chain identifier, ensuring the efficiency and consistency of on-chain and off-chain query logic.

[0116] Based on the blood information data in the blood dataset, a full-process traceability query result for blood from collection to use is generated through data querying.

[0117] Specifically, the data query method is implemented as follows: First, a query language or database interface supported by the database management system is used to execute a data query request on the blood dataset located in the off-chain database. For example, a query command is sent to the off-chain database using Structured Query Language (SQL), such as: SELECT Blood Unit Number, Donor Identity Information, Collection Date, Storage Temperature, Storage Start and End Time, Transportation Route, Transportation Start and End Time, Patient Identification. The execution result of the above query command is to extract all relevant data fields from the off-chain database for the entire process of blood collection to usage.

[0118] The process of generating full-process traceability query results involves systematically summarizing and structuring all relevant data fields obtained from the query to form a visualized and traceable full-process blood traceability report or electronic record. For example, a traceability query result might be a structured traceability data unit containing a labeled blood unit number (e.g., "20240112001"), donor name (e.g., "Li"), collection date (e.g., "January 5, 2024, 08:30:00"), test result (e.g., "Hepatitis B virus test result: negative"), storage location and conditions (e.g., "Storage temperature: 4.5℃, storage location: Warehouse A"), transportation route (e.g., "Central Blood Bank to Central Hospital"), and patient identity (e.g., "Patient: Wang"). This full-process traceability query result clearly records all information about the blood at each stage, ensuring accurate and comprehensive traceability and retrospection of the entire blood process in practical applications.

[0119] The results of the end-to-end traceability query can be displayed and provided in easily identifiable and auditable electronic document formats, such as Extensible Markup Language (XML), JavaScript Object Notation (JSON), or electronic reports. Users can input on-chain blood data identifiers through computer or network systems to obtain corresponding off-chain blood end-to-end data in real time, achieving effective data traceability and real-time monitoring from on-chain to off-chain.

[0120] Example 2

[0121] The difference between Embodiment 2 and Embodiment 1 is that this embodiment introduces a blockchain-based blood safety traceability system.

[0122] Figure 2 A schematic diagram of a blockchain-based blood safety traceability system is provided. The blockchain-based blood safety traceability system includes:

[0123] The data preprocessing module collects blood information data generated throughout the entire process from blood collection to use, and performs structured preprocessing on the blood information data to generate a blood dataset.

[0124] The on-chain evidence management module performs on-chain data upload processing based on the blood dataset, generates blood data identifiers for on-chain evidence storage, and stores the blood dataset in an off-chain database.

[0125] The change monitoring and recording module monitors the update events of the blood dataset in the off-chain database in real time, performs data version change analysis on the update events, and generates a blood data change log.

[0126] The consistency verification module updates the blood dataset in the off-chain database based on the blood data change log, and verifies the consistency between the blood dataset in the off-chain database and the blood data identifier stored on the chain through data consistency comparison.

[0127] The on-chain identifier update module dynamically updates the identifier of the blood data stored on the chain based on the consistency verification result, and generates the updated on-chain blood data identifier.

[0128] The traceability query output module performs full-process traceability queries for blood based on the updated on-chain blood data identifiers.

[0129] The above formulas are all dimensionless calculations. The formulas are derived from software simulations based on a large amount of collected data to obtain the most recent real-world results. The preset parameters and thresholds in the formulas are set by those skilled in the art according to the actual situation.

[0130] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0131] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0132] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and modules described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0133] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0134] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0135] In addition, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0136] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0137] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0138] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A blockchain-based method for end-to-end traceability of blood safety, characterized in that, Includes the following steps: S1 collects blood information data generated throughout the entire process from blood collection to use, and performs structured preprocessing on the blood information data to generate a blood dataset; S2, perform on-chain data upload processing based on the blood dataset, generate on-chain blood data identifiers, and store the blood dataset in the off-chain database; S3 monitors the update events of the blood dataset in the off-chain database in real time, performs data version change analysis on the update events, and generates a blood data change log. S4, based on the blood data change log, updates the blood dataset in the off-chain database, and verifies the consistency between the blood dataset in the off-chain database and the blood data identifier stored on the chain through data consistency comparison. S5, based on the consistency verification result, dynamically updates the blood data identifier stored on the chain to generate the updated blood data identifier on the chain. S6 enables full-process traceability queries of blood based on updated on-chain blood data identifiers.

2. The method for full-process traceability of blood safety based on blockchain according to claim 1, characterized in that, S1, specifically: Blood information data generated throughout the entire process of blood collection, from collection, testing, storage, transportation to use; The collected blood information data undergoes structured preprocessing, including data field classification, unified field format conversion, and outlier identification and correction, to generate a blood dataset.

3. The method for full-process traceability of blood safety based on blockchain according to claim 2, characterized in that, S2, specifically: A data digest is calculated based on a hash algorithm to obtain a data digest value representing the blood dataset. According to the transaction packaging rules of the blockchain, the data digest value is uploaded to the blockchain in the form of a smart contract, and after consensus verification, a blood data identifier stored on the chain is generated. By storing blood datasets in an off-chain database through distributed storage, a mapping relationship is established between the blood data identifiers stored on the blockchain and the blood datasets in the off-chain database.

4. The method for full-process traceability of blood safety based on blockchain according to claim 3, characterized in that, S3, specifically: Real-time monitoring of data update events in the blood dataset in the off-chain database, including the operation type and operation time information of adding, modifying or deleting data fields in the blood dataset; By comparing the blood dataset before and after the update, we can perform data version change analysis to identify the data fields that have changed in the blood dataset and the data content before and after the data field changes. A blood data change log is generated based on the data fields that have changed in the blood dataset and the data content before and after the changes.

5. The method for full-process traceability of blood safety based on blockchain according to claim 4, characterized in that, S4, specifically: Based on the changed data fields in the blood dataset and the data content after the data field changes, the blood dataset in the off-chain database is updated; Based on the hash algorithm, the updated blood dataset in the off-chain database is recalculated to obtain the data digest value corresponding to the updated blood dataset; The blood data identifier stored on the blockchain is compared with the data digest value corresponding to the updated blood dataset to determine whether the blood data identifier stored on the blockchain is consistent with the data digest value corresponding to the updated blood dataset. Based on the data comparison results, a consistency verification result is generated.

6. The method for full-process traceability of blood safety based on blockchain according to claim 5, characterized in that, S5, specifically: When the consistency verification result shows that the blood data identifier stored on the chain is inconsistent with the data digest value corresponding to the updated blood dataset, the blood data identifier stored on the chain is replaced with the data digest value corresponding to the updated blood dataset. According to the transaction packaging rules of the blockchain, the updated data digest value is re-uploaded to the blockchain in the form of a smart contract. After consensus verification, an updated on-chain blood data identifier is generated. Based on the mapping relationship between the blood data identifier stored on the blockchain and the blood dataset in the off-chain database, the mapping relationship between the updated on-chain blood data identifier and the updated blood dataset in the off-chain database is re-established.

7. A method for end-to-end traceability of blood safety based on blockchain as described in claim 6, characterized in that, S6, specifically: Based on the updated on-chain blood data identifier, the blood dataset corresponding to the updated on-chain blood data identifier is located from the off-chain database by means of the mapping relationship between the on-chain blood data identifier and the blood dataset in the off-chain database. Based on the blood information data in the blood dataset, a traceability query result for the entire process of blood from collection to use is generated through data querying.

8. A blockchain-based blood safety end-to-end traceability system, used to implement the blockchain-based blood safety end-to-end traceability method according to any one of claims 1-7, characterized in that, include: The data preprocessing module collects blood information data generated throughout the entire process from blood collection to use, and performs structured preprocessing on the blood information data to generate a blood dataset. The on-chain evidence management module performs on-chain data upload processing based on the blood dataset, generates blood data identifiers for on-chain evidence storage, and stores the blood dataset in an off-chain database. The change monitoring and recording module monitors the update events of the blood dataset in the off-chain database in real time, performs data version change analysis on the update events, and generates a blood data change log. The consistency verification module updates the blood dataset in the off-chain database based on the blood data change log, and verifies the consistency between the blood dataset in the off-chain database and the blood data identifier stored on the chain through data consistency comparison. The on-chain identifier update module dynamically updates the identifier of the blood data stored on the chain based on the consistency verification result, and generates the updated on-chain blood data identifier. The traceability query output module performs full-process traceability queries for blood based on the updated on-chain blood data identifiers.

Images