Medical logistics data tracing method and system based on block chain

Abstract

The invention belongs to the field of data protection, and provides a medical logistics data tracing method and system based on a block chain, and the method comprises the steps: carrying out the stage division of a circulation link of medical supplies; generating a plurality of verification tokens based on the block content of the stage after data writing is completed in each stage; executing state verification operation on all the verification tokens one by one, if all the verification tokens in the verification set pass verification, allowing the data of the current stage to be written into the block chain, and establishing a validity inheritance relationship with the previous stage; if the verification is not passed, stopping the data writing operation of the current stage and all subsequent stages; and marking the frozen subsequent stage block as a non-updatable state, constructing an auditing structure associated with the freezing mark, and performing on-chain auditing evidence storage on the state element and the verification failure reason of the frozen node. According to the invention, the reliability of medical logistics data traceability can be improved.

Description

Technical Field

[0001] The present invention belongs to the field of data protection, and specifically relates to a blockchain-based medical logistics data traceability method and system. Background Art

[0002] In the modern healthcare system, the circulation and management of medical supplies has become a crucial component in ensuring the quality and safety of medical services. Especially in the context of frequent public health incidents, ensuring traceability, data transparency, and operational compliance throughout the medical logistics process is crucial for emergency response, regulatory audits, and accountability. Blockchain technology, with its immutable, verifiable, and distributed storage capabilities, offers a new path for the trusted recording and traceability of medical logistics data.

[0003] Existing medical logistics management methods primarily rely on centralized database systems, which register and track data on the receipt, distribution, inventory, and delivery of medical supplies through logistics information systems. Some systems incorporate methods such as QR codes and RFID tags for material identification and status recording, supplemented by business process management software for node control. However, these approaches often pose risks such as single points of failure in the data center, information lags, tampering risks, and difficulties in cross-system data integration, making it difficult to meet the requirements for authenticity, consistency, and non-repudiation of logistics data across the entire supply chain.

[0004] In practical applications, current technical solutions generally fail to effectively address the problem of insufficient cross-stage data verification mechanisms. Once a data anomaly is discovered at a particular stage, the lack of sufficient on-chain verification methods and accountability mechanisms can easily damage the credibility of subsequent data, affecting the effective traceability and division of responsibilities in the entire logistics chain. In particular, in cases of data contamination, operational omissions, or malicious tampering, existing systems often struggle to promptly detect and prevent the further spread of erroneous data. The lack of on-chain freezing and auditing mechanisms for staged verification failures results in insufficient system response capabilities in the face of anomalies and uncontrollable error propagation, seriously impacting the security and transparency of the medical supply distribution system. Summary of the Invention

[0005] In order to solve the problems in the prior art, the present invention provides a blockchain-based medical logistics data traceability method, comprising the following steps:

[0006] In the medical logistics process, the circulation of medical supplies is divided into stages to form a multi-stage logistics process with sequential dependencies, and the logistics data corresponding to each stage is collected as stage data;

[0007] Preprocessing the stage data to generate a corresponding block data structure, and after completing data writing in each stage, generating multiple verification tokens based on the block content of that stage, wherein the multiple verification tokens respectively correspond to preset elements of different dimensions in the stage, and the multiple verification tokens logically constitute a verification set;

[0008] Before entering the next stage, the verification set is extracted from the previous stage, and the status verification operation is performed on all verification tokens in the set one by one. If all verification tokens in the verification set pass the verification, the data of the current stage is allowed to be written to the blockchain, and the validity inheritance relationship with the previous stage is established;

[0009] If any verification token in the verification set fails verification, data writing operations in the current stage and all subsequent stages are blocked, and a freeze mark is generated in the blockchain, indicating that all subsequent stage data from the verification failure node are not eligible for blockchain validity traceability;

[0010] After the frozen state is generated, the subsequent stage blocks to be frozen are marked as non-updatable and restricted from participating in any validity judgment, traceability analysis and trusted reference operations based on the chain state in the blockchain;

[0011] An audit structure associated with the freeze mark is constructed, and the interrupted logistics chain information is accessed based on the freeze mark. The status elements of the frozen nodes and the reasons for verification failure are audited and recorded on the chain.

[0012] Furthermore, the multiple verification tokens include summary tokens, signature tokens and rule tokens, wherein the summary tokens are used to verify the hash summary consistency of the stage data field, the signature tokens are used to verify the legality of the signature of the preset field, and the rule tokens are used to verify whether the stage data complies with the preset logical rules and boundary conditions. The verification operations of the three types of tokens respectively call the summary calculation module, the public key verification module and the rule matching module, and allow the current stage data to be uploaded to the chain when the verification results are all passed.

[0013] Furthermore, the freeze mark is generated by the freeze control module and recorded in the on-chain status structure in the form of a freeze instruction. The freeze instruction includes the stage identifier of the failure stage, the numbering information of the failure token, the classification code of the failure type and the marked range of the freeze boundary. The freeze instruction generates a frozen node in the chain structure. The frozen node establishes a logical link with the failure stage node through a structural reference and has unique identification information for subsequent on-chain traceability positioning and verification obstacle identification.

[0014] Further, the block in the frozen state is set as an un-updatable state in the blockchain structure, the un-updatable state includes prohibition of data addition, field modification and digest rewriting, and the system limits the block in the frozen state from participating in any state evaluation calculation based on on-chain data, traceable path analysis and cross-system trusted reference call, to prevent subsequent on-chain state pollution caused by the existence of a verification failure node.

[0015] Further, the audit structure associated with the frozen mark includes an on-chain frozen node and an on-chain audit record unit, the system accesses the data content of the frozen node based on the failure token information recorded by the frozen mark, collects the state field, verification strategy and trigger node context, generates a structured audit record containing the verification failure reason, and writes the audit record into the on-chain audit area in an unalterable manner, to support subsequent audit evidence collection, node responsibility attribution analysis and abnormal evolution path backtracking.

[0016] The application also provides a blockchain-based medical logistics data traceability system, comprising:

[0017] A stage division module is configured to divide the flow link of medical supplies in the medical logistics process into stages, form a multi-stage logistics process with sequential dependency, and collect the logistics data of each stage as stage data.

[0018] A block construction module is configured to preprocess the stage data, generate a corresponding block data structure, and generate a plurality of verification tokens based on the block content of each stage after data writing is completed in each stage, the plurality of verification tokens corresponding to different dimensions of preset elements in the stage, and the plurality of verification tokens logically constituting a verification set together.

[0019] A verification control module is configured to extract the verification set from the previous stage before entering the next stage, and perform a state verification operation on each verification token in the set, if all verification tokens in the verification set pass the verification, the data of the current stage is allowed to be written into the blockchain, and an effective inheritance relationship with the previous stage is established.

[0020] A freezing processing module is configured to prevent data writing operation of the current stage and all subsequent stages when any verification token in the verification set fails to pass the verification, and generate a frozen mark in the blockchain to identify that all subsequent stage data from the verification failure node does not have blockchain validity traceability qualification.

[0021] A state limiting module is configured to mark the frozen subsequent stage block as an un-updatable state after the frozen state is generated, and limit its participation in any validity judgment based on on-chain state, traceability analysis and trusted reference operation in the blockchain.

[0022] An audit structure construction module is used to construct an audit structure associated with the freeze mark, access the interrupted logistics chain information based on the freeze mark, and perform on-chain audit and evidence storage of the status elements of the frozen node and the reasons for verification failure.

[0023] Furthermore, the multiple verification tokens include summary tokens, signature tokens and rule tokens, wherein the summary tokens are used to verify the hash summary consistency of the stage data field, the signature tokens are used to verify the legality of the signature of the preset field, and the rule tokens are used to verify whether the stage data complies with the preset logical rules and boundary conditions. The verification operations of the three types of tokens respectively call the summary calculation module, the public key verification module and the rule matching module, and allow the current stage data to be uploaded to the chain when the verification results are all passed.

[0024] Furthermore, the freeze mark is generated by the freeze control module and recorded in the on-chain status structure in the form of a freeze instruction. The freeze instruction includes the stage identifier of the failure stage, the numbering information of the failure token, the classification code of the failure type and the marked range of the freeze boundary. The freeze instruction generates a frozen node in the chain structure. The frozen node establishes a logical link with the failure stage node through a structural reference and has unique identification information for subsequent on-chain traceability positioning and verification obstacle identification.

[0025] Furthermore, the blocks in the frozen state are set to a non-updatable state in the blockchain structure, which includes prohibiting data appending, prohibiting field modification, and prohibiting summary rewriting. The system also restricts the blocks in the frozen state from participating in any state evaluation calculations based on on-chain data, traceable path analysis, and cross-system trusted reference calls, to prevent subsequent on-chain state pollution caused by the existence of verification-failed nodes.

[0026] Furthermore, the audit structure associated with the freeze mark includes an on-chain frozen node and an on-chain audit record unit. The system accesses the data content of the frozen node based on the failure token information recorded in the freeze mark, collects status fields, verification policies and trigger node contexts, generates a structured audit record containing the reason for the verification failure, and writes the audit record into the on-chain audit area in an unalterable manner to support subsequent audit evidence collection, node responsibility analysis and abnormal evolution path backtracing.

[0027] The blockchain-based medical logistics data traceability method provided by this invention effectively verifies the integrity and legitimacy of data at each stage by generating corresponding verification tokens at each logistics stage and constructing verification sets for each stage. This mechanism not only ensures that data meets multi-dimensional consistency requirements before being written to the blockchain, but also immediately triggers a freezing mechanism when verification fails, blocking the subsequent writing of untrusted data to the blockchain, thus limiting the risk of anomalous information transmission at the source.

[0028] This invention further establishes an on-chain audit structure associated with the freeze flag, providing structured evidence of the status elements and trigger context of failed verification nodes, enabling clear tracking and review of each anomaly. Through mechanisms such as chain-level broadcasting, audit zone solidification, and node responsibility mapping, the system's response efficiency and transparency in abnormal situations are enhanced, providing a higher level of data trust and regulatory compliance support for the entire medical logistics process. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0030] Figure 1 This is a schematic diagram of the main process of the present invention;

[0031] Figure 2 It is a schematic diagram of the relationship between the verification token structure and the verification mechanism;

[0032] Figure 3 It is a logic diagram of freezing control and audit evidence structure. DETAILED DESCRIPTION

[0033] In order to make the technical solution of the present invention clearer and more complete, the present invention is further described in detail below with reference to specific embodiments. It should be understood that the described embodiments are only used to illustrate the present invention and do not constitute a limitation on the scope of protection of the present invention.

[0034] Description of the overall system structure and deployment environment.

[0035] The blockchain-based medical logistics data traceability method can be deployed within a consortium chain architecture that supports multi-node participation and a state consensus mechanism. The consortium chain platform utilizes a data structure design with a permission control mechanism and manages access node permissions based on a pre-defined identity verification system. The consortium chain can be jointly constructed by various organizations, including medical supply manufacturers, third-party logistics companies, hospitals, and regulatory authorities, using a cross-institutional trust model to achieve distributed recording and traceability of data throughout the entire medical logistics process.

[0036] The alliance chain system includes multiple types of functional nodes, and each node is deployed in different business systems or terminal devices according to the division of responsibilities. Specifically, the system includes at least data collection nodes, consensus nodes and audit nodes. The data collection nodes are deployed at key physical locations where medical logistics materials are transferred, and are used to collect environmental parameters, operation information and logistics status related to this stage in real time, and send the collected data to the designated block generation module in the blockchain network after standardization; the consensus node is used to receive the data summary and verification token information of each stage, and verify the legitimacy of the data of each stage according to the preset consensus mechanism (such as Byzantine fault tolerance algorithm, weighted voting mechanism or improved PBFT algorithm), and reach a consensus after the verification is passed, and promote the writing of the current stage data to the chain; the audit node is a node of a regulatory unit with audit authority, which performs periodic spot checks and responsibility determination on frozen blocks, verification failure nodes and verification logic execution by calling the on-chain audit structure.

[0037] In the data collection phase, the medical logistics system can integrate a variety of sensing devices with networking capabilities to collect stage elements of different dimensions. The equipment includes: a temperature and humidity sensor for recording the temperature and humidity of the environment in which the materials are located, which can be connected to the environmental monitoring module in the logistics packaging; a GPS positioning device for obtaining the transportation trajectory, which can be installed in the delivery vehicle or transport box; a code scanning terminal and electronic signature recording device for confirming the identity of the handover node and verifying the receipt action, which can be integrated into a mobile data collection terminal PDA or a dedicated logistics transfer station; in some implementations involving the transportation of biological products, a camera module and biometric identification equipment can also be connected to enhance the unique verification of the node identity.

[0038] All types of data collection equipment must be capable of external communication. The communication methods may include Bluetooth, WiFi, cellular communication (such as 4G / 5G), and LoRa wide-area low-power communication. The specific communication method can be flexibly configured based on the environment in which the logistics node is located, network coverage, and device power consumption constraints. The device communicates with the data collection gateway deployed on the edge computing node or cloud node through an embedded communication module. The gateway then encapsulates the collected data into structured message packets and sends them to the data access interface module of the blockchain network for on-chain processing.

[0039] Through the above deployment method, the present invention realizes the technical goals of real-time collection of multi-dimensional status elements, data mutual trust among multiple parties, and trusted chain-up and subsequent auditable traceability based on blockchain during the entire circulation process of medical logistics materials, ensuring data security, process continuity and regulatory verifiability in the distribution process of key medical supplies.

[0040] Based on the above system structure and deployment environment, in actual application, the blockchain-based medical logistics data traceability method described in the present invention relies on the collaborative work of various nodes in the alliance chain platform. In the entire process of medical supplies from the source to the terminal receipt, it realizes the distributed collection of multi-stage status data, chain constraints on the validity transmission between stages, freezing control triggered by data anomalies, and a chain audit mechanism with regulatory traceability.

[0041] The overall process of the present invention is as follows Figure 1 As shown, in order to further illustrate the specific implementation process of the present invention, the following will combine the logical order of each stage to explain in detail the core steps such as stage division and data collection, verification token generation and verification set construction, validity inheritance and on-chain write control, frozen state mark generation and subsequent processing, audit structure construction and access mechanism.

[0042] In medical logistics scenarios, the distribution of medical supplies typically involves multiple carriers and transit nodes, including warehousing, sorting, transportation, handover, storage, and receipt. Each link has a strong dependency on the physical state and operational responsibilities of the medical supplies, and the effectiveness of logistics events often depends on the accuracy and compliance of upstream links. Therefore, in the data traceability process, continuity and dependency between data at each stage must be ensured. That is, only if the data of the previous stage on which the current stage is based is legal and valid, does the current stage's on-chain data have credible traceability value. If anomalies or data are missing at a particular stage, the data of all subsequent stages will directly become meaningless. To this end, in the medical logistics process, the flow of medical supplies is divided into stages, forming a multi-stage logistics process with sequential dependencies, and the logistics data corresponding to each stage is collected as stage data.

[0043] The stage described in this document refers to the operational unit medical supplies undergo as they transition from one state to another in the logistics chain. These units are characterized by changes in physical location, a shift in responsible entities, or adjustments to the operating environment. Stage data refers to a structured set of information corresponding to a specific stage, characterizing the logistics status of that stage. This information includes information such as the start and end times of the stage, environmental parameters, node identities, and operational records. Stages are linked through the temporal sequence of logistics events to form a dependency chain, which serves to construct an on-chain path for medical logistics data.

[0044] During implementation, the system first presets a set of standardized phase division rules based on medical logistics business scenarios. These rules divide the flow of medical supplies into interconnected phase units based on time and operation dimensions. These phase division rules can be loaded through the rule engine and customized based on logistics type, material category, or compliance requirements. During initialization, the blockchain system binds a corresponding logistics model to each type of medical supply and automatically matches the applicable phase division strategy when generating logistics orders.

[0045] During the phase division process, the system first generates a full-process phase sequence, determining each phase's starting and ending conditions, as well as its state dependencies with the previous phase. At the start of each phase, the system automatically activates a data collection task, triggering the sensing devices deployed at the physical nodes in that phase to report data. Data collection tasks can be executed by edge computing nodes or mobile terminals, and their triggering conditions may include a phase start threshold, a material arrival event, or a node operation confirmation signal.

[0046] During the data collection process, the system performs denoising, normalization, field mapping, and metadata encapsulation on the received raw data, and generates a stage data structure based on a preset field template. This stage data structure includes, but is not limited to, fields such as stage identifier, material number, timestamp, collection device number, data summary, and collection source signature. These fields are used to generate verification tokens and store data on the blockchain. After collection, each stage data structure is cached in the local node storage module, and a unique data summary is generated for reference in subsequent stages.

[0047] The system manages the logic of transitions between phases based on a business continuity model. Upon completion of a phase, its data structure and status identifiers are written to a temporary blockchain verification pool as pre-verification for the next phase, pending token verification in subsequent phases. In exceptional circumstances, such as detecting incomplete data or equipment anomalies at the completion of a phase, the system can automatically delay the transition until data is complete or manual verification is performed.

[0048] In a preferred implementation, the medical logistics platform, based on the vaccine delivery task, establishes a five-stage logistics process model: outbound delivery, in-transit transportation, transit handover, final delivery, and receipt. During the outbound delivery phase, the system is triggered by the manufacturer's WMS system, and a temperature and humidity probe installed in the vaccine packaging container records the initial status. This data is then uploaded to the on-site edge acquisition terminal via Bluetooth. During the transportation phase, the vehicle's GPS module continuously uploads location information. Temperature and humidity data is automatically collected every ten minutes and transmitted to the blockchain node via the 4G network. During the transit handover phase, the system uses the PDA terminals of both parties to record the identity, handover time, and vaccine quantity, and performs bidirectional signing to generate the data structure for that phase. During the final delivery phase, data collection equipment records the transfer of vaccines to the vaccination site and uploads the last-mile location and timestamp information to the blockchain network. During the receipt phase, the vaccine recipient completes an electronic signature on the receipt terminal and binds the personal identification to form the final confirmation data. The system packages the data of the above five stages in sequence to generate five stage data structures, and stores them in the blockchain nodes in sequence to form a verifiable and continuous stage data sequence.

[0049] In this embodiment, for a batch of vaccines used for routine vaccination tasks, the system divides the medical logistics process into the following seven sequentially dependent stages:

[0050] Phase 1: Preparation for shipment

[0051] The vaccine picking, packaging, and coding operations are completed by the manufacturer or provincial disease control center. The system collects information on the vaccine type, batch, quantity, packaging type, and expiration date, and records the operator's identity and operation time, and initializes the data structure.

[0052] The second stage: the shipment confirmation stage

[0053] After the vaccine is refrigerated and packaged, temperature and humidity sensors are installed and bound to the delivery number. Designated operators confirm the packing through the identity recognition system, and collect the initial refrigeration environmental parameters and outbound video summary information as stage verification elements.

[0054] The third stage: transportation and shipment

[0055] When the vaccine leaves the shipping place and enters the formal transportation process, the on-board GPS device starts uploading location information, the temperature and humidity sensors upload monitoring data at a fixed period, and the system records the vehicle number, driver's identity and departure time.

[0056] Phase 4: On-the-way monitoring

[0057] While the vaccine is in transit, the logistics control center collects and records the transportation trajectory, environmental status, vehicle status, abnormal alarms and response information in real time. If there is a route deviation or temperature control alarm, the stage will be marked as an abnormality and the freezing mechanism will be triggered.

[0058] Phase 5: Transfer and handover

[0059] When the vaccine arrives at the transfer station, the transporter and the next carrier will carry out the handover operation. The two parties use mobile terminals to complete the information signing, material verification and two-way identity authentication of personnel. The system records the handover time, geographic location and signature information.

[0060] Phase 6: Final delivery

[0061] When the vaccine enters the final distribution link, the last transportation personnel will deliver the vaccine from the transfer point to the vaccination point. The system continuously records the route, time and environmental data to form a data structure consistent with the structure of the shipping stage, and verifies the transfer and connection situation.

[0062] Stage 7: Receiving and signing

[0063] When the vaccine arrives at the vaccination site, the receiving personnel scan the logistics number through the terminal and complete the electronic signature, while binding the identity information, signature time and temperature verification data. The system confirms whether the signature action is completed within the scheduled time window and valid environment.

[0064] In the medical logistics process, because the data collected at each stage often comes from diverse sources, has heterogeneous formats, and is distributed across different nodes, before being written to the blockchain, the data must be uniformly structured to ensure data integrity, consistency, and parsability. Furthermore, because the validity of data in subsequent stages is highly dependent on the credibility of the state in the previous stage, a verifiable token structure must be proactively generated after data processing and uploading to the blockchain at each stage to indicate whether the core state of that stage meets the standards. To achieve collaborative verification of multi-dimensional states, the system must extract elements by field dimension and generate independent and logically related verification tokens for information in different dimensions to construct a complete verification set for subsequent stages to access. To this end, the stage data is preprocessed to generate the corresponding block data structure. After the data is written to each stage, multiple verification tokens are generated based on the block content of that stage. These multiple verification tokens correspond to the preset elements in different dimensions of the stage, and together, these multiple verification tokens logically constitute the verification set.

[0065] Preprocessing refers to the process of formatting, redundancy cleaning, field reconstruction, and hash summary encapsulation of raw collected data, which is used to convert the raw data into data structure units that can be directly used for block generation. The block data structure refers to a data encapsulation format capable of being uploaded to the blockchain, containing a stage identifier, timestamp, status summary, source node signature, and data index information, used to generate formal on-chain records in the blockchain system. The verification token refers to a lightweight data summary generated by encryption or summary calculation based on specific dimension fields in the block data structure, and is used to perform status verification in subsequent stages. The verification set refers to a logical collection of multiple verification tokens in the same stage, used to support the overall verification mechanism.

[0066] In its implementation, the system first launches the data preprocessing module after completing data collection at each stage. This module consists of a structured data engine deployed on edge nodes or connected nodes. Its primary task is to convert the multi-source, heterogeneous raw data into a standard structure that meets the requirements for blockchain writing. The data preprocessing process primarily includes five steps: data deduplication, time alignment, format unification, field mapping, and data summary construction.

[0067] During the data deduplication process, the system constructs a unique index value based on the device number, task number and timestamp to identify and eliminate duplicate data generated during transmission due to network jitter or overlapping collection cycles. During the time calibration process, the system uses the on-chain time synchronization mechanism to uniformly map the local time collected by each device to the main timeline of the alliance chain to ensure the consistency of data across devices. In the format unification stage, the system converts the structured or semi-structured data output by different data sources into a set of standard fields, including stage number, collection time, node identity, sensor number, measurement parameters, location information, etc. During the field mapping process, the system establishes a mapping relationship between the collection field and the on-chain field standard based on the preset field template to ensure the stability of the structure.

[0068] After completing the above preprocessing steps, the system encapsulates each field into a unified data structure, called a stage data structure unit. This structure unit provides the data foundation for subsequent block generation and verification token generation. The stage data structure unit includes several field blocks, each consisting of a field name, field value, generation time, and signature information. An overall hash digest is generated at the structure level to identify the integrity of the data at that stage.

[0069] After the structure is generated, the system calls the verification token generation module to generate corresponding verification tokens for the multiple key dimension fields preset in the data structure unit at this stage. Each verification token is generated by performing a hash function or digital signature function on the field values ​​and metadata in the corresponding field block. Hash functions can be SHA-256, SM3, or BLAKE2, and signature algorithms can be ECDSA, SM2, etc. Each verification token structure includes a token number, token type, source field identifier, digest value, generation timestamp, and generation node signature. The verification token does not contain the original field value to protect the business privacy of the field content.

[0070] The system generates at least two verification tokens at each stage, representing key dimensions such as the environmental status, identity verification, and operation timing. All verification tokens are logically bound to that stage and collectively constitute a verification set, which is written into the block header structure or on-chain index table. The system automatically marks the verification set with the stage identifier and actively calls it in subsequent stages. Verification sets can also include an expiration date field to set a verification time limit to accommodate special circumstances such as long-term detention or cold chain interruptions.

[0071] When writing a block, the system constructs the block data structure primarily based on the phase data structure units. Each block structure consists of a block header and a block body. The block header contains the phase number, the hash of the previous phase block, a generation timestamp, a verification set summary, and the node signature. The block body contains the phase data structure units and their complete field contents. Blocks are written to the consortium chain through a consensus mechanism and, after completion, enter a locked state, awaiting verification in subsequent phases.

[0072] Optional implementation solutions include: generating verification tokens as an off-chain operation, where the edge node generates verification tokens locally and pushes them to the chain after data collection is completed; or integrating verification token generation into blockchain smart contracts, automatically generating and recording verification sets during the block construction process; the system can also support a dynamic field mapping mechanism, allowing verification dimensions to be adjusted according to different types of medical supplies to support adaptability to multiple medical scenarios.

[0073] In a preferred implementation, in the vaccine cold chain transportation task, the system extracts the following fields for the data structure of the outbound stage: initial temperature value, operator identification number, equipment number and outbound time. The system performs SM3 summary calculation and SM2 signature operation on the above four fields respectively to generate four verification tokens. Each token is bound to a field and records its hash summary, timestamp and issuance signature. The above four tokens are bound to the block header corresponding to the outbound stage as a verification set. The verification set is called when the transportation stage starts, and each check is made to see if the temperature is within the outbound standard range, whether the operator is on the authorized list, whether the equipment number meets the task parameters, and whether the time is within the scheduling window. Only when all tokens are verified can the data be uploaded to the chain during the transportation stage.

[0074] The verification token mechanism employed in this invention independently generates corresponding verification tokens for multiple key dimension fields in each stage, and then combines these verification tokens into a verification set, ensuring that each key state element has a clear on-chain identity. Each verification token, generated from independent fields, is independently verifiable, enabling subsequent stages to conduct state verification on a per-item basis for specific dimensions in the previous stage. This prevents local anomalies from being masked by the overall summary, ensuring the accuracy of state inheritance and the security of chained transfers.

[0075] The verification token maintains a strict structural binding relationship with the block data structure. At the completion of each phase of data writing, the verification token is also written to the chain, forming a logically traceable verification record. The existence of the verification token allows subsequent phases to not only reference the block data of the previous phase, but also confirm the validity of its core state based on the verification set, thus structurally ensuring the legitimacy of data across phases.

[0076] Verification tokens are generated using encrypted summaries or digital signatures. They are lightweight, secure, and do not expose the original field content. This ensures data immutability while effectively mitigating the risk of leaking sensitive business information. This mechanism is particularly suitable for processing key fields in medical logistics that require privacy, such as operator information, time windows, equipment numbers, and temperature control data. It balances the verification capabilities of on-chain data with the compliance requirements of the data itself.

[0077] The system supports parameterized configuration of verification token generation strategies. Different types of medical supplies can select different field combinations for token generation based on regulatory rules or business characteristics. Multiple tokens can form a logical verification set. When executing verification operations, the system verifies the legitimacy of each token based on the set definition, ensuring the flexibility, scalability, and extensibility of the verification path. This structure also has good processing performance, suitable for executing verification tasks on edge nodes in a distributed environment, and has high feasibility for engineering implementation.

[0078] Through a verification token mechanism, this paper establishes a blockchain state authentication system that achieves both granular verification of state and structural uniformity and privacy protection. This mechanism effectively enhances data continuity, on-chain verification capabilities, and regulatory transparency across all stages of medical logistics, serving as a key technical link supporting trusted multi-stage block inheritance.

[0079] For example, in a vaccine distribution mission, after the vaccine is shipped out of the warehouse, it enters the transportation and shipment phase. This phase is handled by a third-party cold chain logistics company. The system uses smart terminals deployed on transport vehicles to collect multi-dimensional status data related to this phase, forming a phase data structure unit. This structure unit includes the following key fields: vehicle number, departure time, driver identification, geographic coordinates of the departure point, initial temperature and humidity values, equipment number, and GPS location information.

[0080] After the stage data is collected and pre-processed, the system selects four key fields from the above data structure as verification dimensions based on the field configuration strategy. These fields are vehicle number field, departure time field, driver identity field, and initial temperature field. The system generates a separate verification token based on each field:

[0081] For the vehicle number field, the system performs a hash digest and appends the signature information of the logistics enterprise node to generate a token for vehicle compliance verification;

[0082] For the departure time field, the system normalizes the timestamp and generates a summary to verify whether it is within the dispatch window;

[0083] For the driver identity field, the system references the pre-registered authorized personnel signature template to generate a token for identity cross-confirmation;

[0084] For the initial temperature field, the system sets upper and lower limits and generates a token for temperature control compliance verification.

[0085] The four verification tokens above constitute the verification set for the shipping phase. This set is bound to the block data structure corresponding to the shipping phase and forms a verifiable on-chain structure after the blockchain is written. When the next phase, the in-transit monitoring phase, begins, the system automatically calls this verification set and verifies each of the four verification tokens.

[0086] In the entire process of medical logistics, the data of each stage has a strong sequential dependency. Whether the logistics status of any stage is legal directly affects the credibility and writability of the data in the subsequent stage. If the data status of the previous stage is not fully verified, it may cause abnormal status to be transmitted on the chain, thus forming irreversible trust pollution. In order to ensure that the data of each stage has a clear legal basis in terms of status, the system needs to verify each item based on the verification set generated in the previous stage before the start of each stage, so as to ensure the validity inheritance between stages. The data of the current stage can only be written after the verification is passed, thereby realizing chain-based trusted control based on state continuity. To this end, before entering the next stage, the verification set is extracted from the previous stage, and the status verification operation is performed one by one on all the verification tokens in the set. If all the verification tokens in the verification set pass the verification, the data of the current stage is allowed to be written to the blockchain, and a validity inheritance relationship with the previous stage is established.

[0087] The verification set is a logical combination of multiple verification tokens formed after the previous stage of data processing. The verification set is bound to the block header or index record corresponding to the previous stage and serves as the verification entry point for subsequent stages. The state verification operation refers to the process by which the system verifies the legitimacy of each verification token in the verification set according to preset rules. It mainly includes field value verification, time consistency judgment, signature validity confirmation, and rule matching analysis. After the state verification is completed, the system determines whether the data in the current stage has on-chain write permission and whether it has state inheritance capabilities based on the verification results.

[0088] In the specific implementation process, when the current phase starts, the system first obtains the block hash value corresponding to the previous phase through the block index structure. Based on this hash value, it locates and extracts the verification set bound to this phase from the on-chain data structure or the node's local cache. As part of the on-chain structure, the verification set is usually embedded in the block header of the previous phase as a structured data record, or stored in the smart contract address space through the on-chain state mapping table to ensure its accurate reference in subsequent phases.

[0089] After obtaining the verification set, the system assigns a corresponding verification strategy to each verification token in the set. The strategy is dynamically matched according to the token generation method, field source, material attributes and current task context. Figure 2 As shown, the system performs the following verification methods depending on the token type:

[0090] For digest-type verification tokens, the system re-extracts the original value of the relevant field in the current phase from the local computer and recalculates the digest of the field value using the same hash function (such as SHA-256, SM3, etc.) as used in the token generation phase. The resulting digest value is then compared with the digest value stored in the verification token. If they match, verification passes. This method is suitable for verifying static fields, such as the initial temperature value and vehicle number.

[0091] This verification method has the characteristics of simple structure and high computational efficiency. It is suitable for deployment on edge computing nodes or mobile terminals, and can achieve real-time verification effects with low latency and low resource usage.

[0092] For signature-based verification tokens, the system extracts the original signature value from the verification token and uses the trusted public key information stored locally or on the chain to verify the integrity of the signature field. The verification process includes signature parsing, hash digest recalculation, and signature restoration operations. It is suitable for scenarios such as operator identity and receiving unit authorization information that require third-party identity verification.

[0093] This method has the advantages of traceable identity and unforgeable signatures. It is suitable for implementing a responsibility confirmation mechanism between participants. In the medical supplies distribution scenario, it can be used to achieve on-chain compliance confirmation of multi-party collaborative signatures.

[0094] For rule-based verification tokens, the system extracts the target field value from the current stage data structure based on the field identifier bound to the token, and matches it with the legal interval or logical relationship in the preset rule template. For example, it can determine whether the departure time is within the permitted scheduling window or whether the temperature value is within the permitted vaccine transportation range. Rule templates can be dynamically loaded by on-chain contracts or preset through the system configuration interface, and support automatic adaptation based on the type of material.

[0095] This verification method has the characteristics of flexible strategies and clear constraints. It is suitable for handling diverse constraints caused by differences in material properties. It enhances the system's adaptability while ensuring compliance.

[0096] The system applies a "pass-all" principle throughout the verification process. This means that only when all verification tokens in the verification set pass the corresponding verification policy will the system allow the current phase of block generation and writing to the blockchain. If any token in the verification set fails verification, the system immediately aborts the current phase of data writing and triggers a freeze mechanism or exception reporting process. The freeze mechanism inserts a status marker node into the current blockchain structure, restricting write permissions in subsequent phases and prompting the system to enter audit mode.

[0097] This control logic implements a strong constraint mechanism for the state inheritance path, ensuring that the on-chain state will not continue to be transmitted after verification fails, effectively blocking the spread of abnormal states and protecting the overall credibility of on-chain data.

[0098] In a preferred implementation, after extracting the verification set, the system invokes a parallel verification engine to simultaneously execute verification tasks on multiple verification tokens. This parallel verification engine can be implemented as a multi-threaded process within the same physical node, or deployed in a distributed manner across multiple nodes. The execution channels are divided according to the verification task dimension, and the verification results of each verification task are written to an off-chain cache structure after execution.

[0099] Preferably, when the system generates a block in the current stage, it writes the summary of the final result of this round of verification set into the metadata field of the block, and binds the verification status to the current stage data in a chain structure to form a state inheritance path, so that subsequent nodes, audit agencies or regulatory units can quickly retrieve the verification link and verification history.

[0100] This preferred solution has technical effects such as high execution efficiency, complete status expression, and traceable verification results. It can support high-concurrency chain operations and multi-role collaborative supervision needs in medical logistics scenarios, and is suitable for deployment at the city level or cross-regional medical logistics management platforms.

[0101] By binding verification sets and verification result summaries on-chain, this invention achieves the integrated storage of verification and writing behaviors. This ensures that each piece of on-chain data not only records the logistics status but also the verification history of that status, facilitating subsequent chain-level traceability, accountability audits, and compliance analysis. This structure is particularly advantageous in regulatory scenarios, significantly reducing the need for regulators to repeatedly verify data credibility, thereby improving audit efficiency and credibility.

[0102] The verification strategy framework is designed to be highly configurable and adaptable, supporting dynamic adjustment of verification dimensions and strength based on material type, stage category, and participating role, making it suitable for different levels of logistics mission scenarios. For example, for high-risk vaccines, more verification dimensions can be enabled to improve the level of assurance, while for conventional drugs, rules can be simplified as needed to improve chain efficiency.

[0103] The system as a whole forms a closed-loop mechanism for chain verification control paths. Through the structural process of verifying the set in the previous stage → calling verification in the current stage → successfully writing and generating a new block → embedding the next round of verification structure, a closed loop of the state verification link is formed, avoiding the occurrence of logical loopholes such as chain breaks and chain jumps, and ensuring the consistency and completeness of chain-level state governance.

[0104] Continuing with the previous example, four verification tokens form a verification set and are written to the metadata structure of the stage block at the end of the transport shipment stage.

[0105] When the system is ready to enter the in-transit monitoring phase, it first extracts the verification set from the block header corresponding to the transport and shipment phase based on the task number and phase index. The system performs the following operations on each verification token:

[0106] For the vehicle number verification token, the system re-extracts the vehicle number field value, executes the same hash algorithm as the original token to generate a digest, and compares it with the digest value in the token. If the result is consistent, the verification is passed;

[0107] For the driver's authentication token, the system extracts the signature information and calls the driver's public key registered on the chain to verify the legitimacy of the signature. The verification is successful.

[0108] For the departure time verification token, the system reads the timestamp value and matches it with the preset scheduling window interval rules. If the time is within the allowed range, the verification is passed;

[0109] For the initial temperature value verification token, the system matches the upper and lower limits of the temperature control standards corresponding to the vaccine type. The temperature value is within the compliance range and the verification is passed.

[0110] Once all four verification tasks have passed, the system allows the intermediate monitoring phase to generate a new block data structure and write it to the blockchain. The system also records the summary of the verification results of this verification set in the metadata of the current block, forming a complete state inheritance path, ensuring that the supervisory node can trace the verification evidence of the state in the previous phase.

[0111] If any of the above verification tasks fail (for example, the temperature value exceeds the allowed range), the system will prevent the block generation operation during the monitoring phase, directly generate a freeze mark, and insert a freeze node at the current chain position, recording the reason for the verification failure, the failure token type, and the stage identifier. The system will also start the audit module and push the verification anomaly to the supervision node for processing.

[0112] This example shows that the verification set mechanism not only provides on-chain control capabilities at the state level, but also establishes a structured state inheritance path between stages, ensuring the continuity and verifiability of the legal transmission of data in the logistics chain, significantly enhancing the security, reliability and regulatory friendliness of the system.

[0113] Throughout the entire medical logistics process, the credibility of data is strictly stage-dependent, that is, whether the status of a certain stage is legal or not will directly determine the credibility of the data in the subsequent stages. Once there are defects or anomalies in the status of the previous stage, even if the execution process of the subsequent stage is complete, it will lose its traceability significance because it is built on an erroneous basis. In order to prevent this type of logical pollution from spreading backward in the blockchain, the write path must be interrupted immediately when any verification token in the verification set fails, and the chain operations of all subsequent stages must be blocked, structurally cutting off the state transfer link to ensure the boundary credibility and structural cleanliness of the on-chain data. To this end, if any verification token in the verification set fails to pass the verification, the data write operation of the current stage and all subsequent stages will be blocked, and a freeze mark will be generated in the blockchain, indicating that from the verification failure node, all subsequent stage data are not eligible for blockchain validity traceability.

[0114] The verification failure node refers to the stage node where the verification set fails the first time. The block data at this node does not meet the state inheritance requirements and becomes a breakpoint in the chain write path. The freeze mark is a special status mark embedded in the blockchain structure by the system. It records the location of the verification failure, the reason for the failure, and the boundaries of the frozen range. It also prevents block write operations after the mark is marked through structural restrictions. Traceability refers to the legal reference rights of subsequent stage data in the blockchain. Once the freeze mark is generated, the subsequent data will no longer be eligible to participate in compliance verification or audit analysis as valid logistics evidence.

[0115] like Figure 3 As shown, in the specific implementation process, when the system is executing the verification task of the current stage, if it detects that any verification token in the verification set has failed the status verification, the data writing process of the current stage will be terminated immediately, and the freeze control module will be triggered to generate a freeze instruction. The freeze instruction is a structured control data unit, which at least includes a failure stage identifier, a failure token number, a failure type description, and a freeze boundary information. The failure stage identifier is used to indicate the stage number or block index position where the verification failure occurred. The failure token number corresponds to the specific token field that failed the verification. The failure type is used to identify the specific cause of the failure, such as temperature control parameter exceeding the limit, invalid timestamp, identity signature mismatch, etc. The freeze boundary is used to define the scope of the freeze, such as freezing to the end of the chain or freezing a specific subsequent stage.

[0116] Once a freeze instruction is generated, the system synchronously writes it to the blockchain state structure and immediately inserts a freeze node. A freeze node is a uniquely identified on-chain structural unit that does not carry regular business data but instead represents a write breakpoint in the chain structure caused by a state anomaly. This freeze node establishes a logical connection with the failed block through a structural reference mechanism, ensuring that any continuity break in the on-chain data structure is perceptible and traceable at the state level. The freeze node contains a freeze summary, a triggering timestamp, the signature of the responsible node, and an index of the freeze range for subsequent audit and regulatory review.

[0117] When the system freezes the node generation, it automatically closes the data writing interface of the current stage and its subsequent stages. The closing mechanism covers the on-chain write interface, contract call path, cache channel and data uplink network port, forming a comprehensive data upload blockade to prevent any unverified new data from being written. In the frozen state, the system will also synchronously write the frozen state into the off-chain cache structure and access node control table to ensure that the temporary data in the edge collection or relay transmission state is not submitted by mistake. All subsequent blocks on the frozen path enter a logically closed state, unable to expand, unable to participate in state references, unable to be included in consensus promotion, and cannot be used as valid traceability nodes for business analysis or regulatory assessment.

[0118] The freeze flag structure can be implemented in a variety of ways. Options include recording the freeze information directly as fields in the block header of the frozen node, creating a lightweight embedded structure that facilitates instant detection of the freeze status during chain traversal. Alternatively, the freeze instruction can be constructed as a separate structure, stored in an on-chain state mapping table, and associated with the frozen node via an index. This approach supports complex freeze information expansion and dynamic field access, facilitating contract calls or audit checks. The freeze mechanism can also be triggered through two methods: static interception and dynamic smart contract judgment. The static interception mechanism pre-configures the freeze trigger conditions, such as freezing upon verification failure. It offers rapid response and stable rules, making it suitable for scenarios with clear structures and well-defined exception patterns. The smart contract approach embeds the freeze judgment logic into the on-chain contract, dynamically determining whether to freeze and the freeze scope based on a combination of factors such as failure level, task type, and node reputation. This approach is suitable for business scenarios with high task diversity and strict security requirements.

[0119] The frozen node structure has a clear state expression capability and can provide clear state breakpoint identification within the chain structure, allowing for accurate disconnection of on-chain data in the state dimension, thereby achieving controllable closure of node-level state inheritance links. This mechanism securely blocks data while preserving the integrity and logical continuity of the chain structure, facilitating structural restoration and breakpoint recovery of frozen paths.

[0120] The freeze instruction field design supports the precise location of failed tokens and responsible nodes, making the frozen state not only a closed-chain state but also a responsible mapping function for data anomalies. Regulators can use the instruction field in the frozen node to quickly query the anomaly location, failure cause, and associated nodes, thereby improving the efficiency of abnormal event handling and clarifying accountability tracking.

[0121] Through a system-level permission closure mechanism and simultaneous network-wide broadcast of the frozen state, the frozen state can be rapidly propagated across the consortium blockchain network, effectively preventing write offsets or structural disorganization caused by inconsistent node caches or information lags. This network-wide consistent freezing coordination mechanism significantly improves the synchronous response and write management capabilities of multi-node systems in abnormal conditions.

[0122] The introduction of a freezing mechanism also enhances the system's structural tolerance for anomalous on-chain behavior. By freezing nodes and achieving structural isolation of abnormal data links, the system can audit, rollback, or manually intervene in frozen paths without disrupting other business chains, improving the system's overall stability and local error correction capabilities. Furthermore, the freezing mechanism is highly coupled with the audit process, facilitating on-chain review, responsibility attribution, and status recovery based on frozen breakpoints, providing key support for building a highly trusted and strongly constrained medical logistics blockchain system.

[0123] In conjunction with the aforementioned vaccine distribution example, if the rule-based verification token of the initial temperature field fails to pass the verification during the transportation and shipment stage, the system will immediately generate a freeze instruction and write it into the chain structure, inserting a freeze node after the corresponding block in the transportation and shipment stage. The frozen node records the failure field as temperature, the failure type as interval non-compliance, and the responsible node as the carrier number. The freezing range covers all subsequent stages from the en route monitoring stage to the receipt stage. The system closes all relevant write interfaces, sends a freeze instruction to the edge device, and broadcasts it to the alliance node simultaneously. All subsequent attempts to upload blocks are rejected, and the frozen node becomes a breakpoint in the status verification path until the audit mechanism is completed or the freeze is unfrozen by the regulatory contract. This implementation process effectively prevents the backward transmission of non-compliant status and protects the overall availability and structural rigor of the on-chain data.

[0124] In the medical logistics blockchain traceability system, if verification fails in the previous stage and a frozen state is generated, if the frozen stage is not restricted from continuing to participate in the available on-chain activities, the non-compliant state may still be referenced and distort subsequent analysis. Therefore, the system needs to set the blocks in the frozen stage and subsequent stages to a non-updatable state and prevent them from participating in any validity judgment, traceability analysis, and trusted reference operations based on the on-chain state. To this end, after the frozen state is generated, the frozen subsequent stage blocks are marked as non-updatable and restricted from participating in any validity judgment, traceability analysis, and trusted reference operations based on the on-chain state in the blockchain.

[0125] The non-updatable state refers to blocks in the frozen or subsequent stages being set to a read-only state by the system, prohibiting any form of field modification, signature overwriting, recalculation, or consensus advancement. The trusted reference operation refers to the process of using blockchain data for traceability, compliance verification, audit analysis, or smart contract invocation. If a block is marked as non-updatable, it no longer has any trusted reference value.

[0126] During the specific implementation process, after generating a frozen node, the system will traverse all subsequent stage blocks that are directly dependent on the frozen node, set the metadata fields of these blocks to the frozen flag, and modify their status fields to read-only mode. The system also updates the reference verification rules in the on-chain query interface and logical judgment path, so that any query request for the frozen stage or its subsequent stages will first verify its frozen flag. If a frozen state is detected, subsequent logic will be rejected, including data extraction, status verification, or pattern matching operations. At the same time, the system broadcasts the freeze status update instruction to the access node, preventing the off-chain system or client from making further calls to the frozen stage.

[0127] Optional implementations include embedding the freeze flag in the block header, enabling verification with a simple field check. Alternatively, the freeze status can be recorded as an independent mapping table entry on the chain, with block number or stage code index used to determine whether the block is frozen. Frozen status detection can be implemented at the smart contract layer or the blockchain network node layer, with the specific implementation being flexible based on the system security architecture and performance requirements.

[0128] In a preferred implementation, after a frozen node is generated, the system not only inserts a freeze flag but also adds a freeze reason summary, freeze timestamp, and responsible node identifier to the block header and smart contract index, and simultaneously writes this information to the on-chain log structure for audit access. Preferably, the system integrates freeze status determination into all data call interfaces when configuring verification logic. Any data request in the encrypted execution path that attempts to reference a frozen block will be rejected, with the rejection reason and call record recorded in the chain log. This approach increases the overall system's protection depth, ensuring that the chain structure in a frozen state is strictly unavailable, and enhancing the system's security and consistency under abnormal conditions.

[0129] Through this mechanism, the system implements a complete frozen state control path on-chain, ensuring that frozen blocks remain on-chain for audit purposes while preventing them from being misused as data references. The non-updatable and non-referenceable nature of the frozen path effectively terminates state transfer, preventing frozen blocks from being mistakenly called or referenced, and effectively maintaining the reliability and structural isolation of on-chain data.

[0130] In conjunction with the aforementioned example of vaccine distribution, if the verification failure in the transportation and shipment stage triggers a freeze state, the system will mark all subsequent stage blocks, such as the in-transit monitoring stage, the transfer and handover stage, the distribution stage, and the receipt stage, with a freeze mark and set them to read-only mode. Upon receiving any user or system's access request for these stage data, the system will detect the freeze mark and refuse to return the data, while recording the reason for access rejection and the caller's identity information in the chain log. Users or regulators can only view valid stage data before the transportation and shipment stage, and subsequent stage data will not be able to participate in compliance verification, data analysis, or traceability review. Through this mechanism, the system strictly guarantees the credibility of the boundaries of on-chain data references and avoids the misuse of invalid data in subsequent stages.

[0131] In a medical logistics blockchain system, once a freeze mark is generated, if a structured method is not provided to access the interrupted logistics chain information and audit the reasons for verification failure, the data during the abnormal state will be impossible to restore, and regulatory audits will fall into a blind spot. Therefore, the system needs to build an audit structure associated with the freeze mark, support access to the interrupted logistics chain information based on the freeze mark, and conduct on-chain audit and evidence storage of the status elements of the frozen node and the reasons for verification failure. To this end, an audit structure associated with the freeze mark is built to access the interrupted logistics chain information based on the freeze mark, and conduct on-chain audit and evidence storage of the status elements of the frozen node and the reasons for verification failure.

[0132] The audit structure refers to a record unit that stores freeze-related information in a structured manner on the chain or in an on-chain mapping table. It includes a frozen node index, a failed stage identifier, a failed token identifier, a description of the failure type, and a summary of related status fields. Accessing interrupted logistics chain information refers to retrieving the data structure of the last valid stage before the logistics process was interrupted by indexing the frozen node and its upstream valid blocks using the freeze mark. The status elements refer to the summary of key field information and the verification token summary in the frozen node. The verification failure reason is the determination result field indicating that a specific token in the verification set failed verification.

[0133] During the specific implementation process, after the system generates a frozen node, it also generates an audit record unit. This unit copies or encapsulates all fields of the freeze control instruction and binds it to the index information of the frozen node. The audit structure can be stored in the audit mapping table of the on-chain contract. The mapping key includes the task number and the failure stage identifier, and the mapping value includes the failure token identifier, the failure reason description, the freeze timestamp, and the upstream stage hash reference. The system provides an audit query interface, which is only open to supervisory nodes with audit permissions. After verifying the permissions during access, the corresponding chain segment can be quickly located through the freeze mark and the interrupted logistics chain information and failure factors can be restored.

[0134] Implementation options include embedding the audit structure within the frozen node block to simplify query paths, or storing the audit structure as a separate data structure hosted by a smart contract, enabling batch retrieval by task number or time range. Audit access logic can be implemented as an on-chain contract function or a built-in node interface. Based on compliance requirements, the system can set different audit access rights to restrict query scope or field details.

[0135] In a preferred implementation, the system shares the audit structure summary and contractual public key signature with the regulatory agency node on the day the frozen node is generated. The audit record is then stored with the regulatory agency node to ensure that the audit information cannot be tampered with and has cross-institutional verification capabilities. Preferably, the audit structure includes a hash summary of failed verification tokens and a mechanism entry for unfreezing, facilitating future reassessment of the node status through error correction or supplemental data. This approach ensures that audit records are transparent, traceable, and tamper-proof, and can support on-chain data reassessment when subsequent error correction processes are initiated, enabling on-chain problem status governance.

[0136] Through this mechanism, the system achieves a tight integration of frozen status and audit structure, ensuring that any chain interruption caused by verification failure is both visually accessible and supported by underlying audit evidence. Interrupted logistics chains can be fully restored to their last valid stage, with the reasons for verification failures transparent and auditable. Any regulatory entity can trace responsibility and make audit decisions based on on-chain data, significantly enhancing the system's regulatory credibility and its ability to handle abnormal events.

[0137] In the aforementioned vaccine delivery example, when a temperature verification failure causes a freeze in the transport phase, the system generates an audit structure record including the task number, transport phase number, the failure token (initial temperature), the failure type (temperature outside the standard range), a summary of the comparison between the failed temperature value and the standard upper limit, as well as the freeze generation timestamp and the signature of the responsible unit. Supervisory nodes can quickly locate the frozen node through the audit query interface and access data from all stages before the interruption point in the logistics process. They can also view a summary of the reasons for the verification failure, helping regulators quickly determine responsibility and guide emergency response.

[0138] In another embodiment, the present invention also provides a blockchain-based medical logistics data traceability system, comprising

[0139] The stage division module is used to divide the flow of medical supplies into stages during the medical logistics process, forming a multi-stage logistics process with sequential dependencies, and collecting the logistics data corresponding to each stage as stage data;

[0140] A block construction module is configured to pre-process the data of the stages to generate a corresponding block data structure, and after completing data writing at each stage, generate multiple verification tokens based on the block content of that stage, wherein the multiple verification tokens respectively correspond to preset elements of different dimensions in the stage, and the multiple verification tokens logically constitute a verification set;

[0141] A verification control module is configured to extract the verification set from the previous stage before entering the next stage, and perform status verification operations on all verification tokens in the set one by one. If all verification tokens in the verification set pass verification, the data of the current stage is allowed to be written to the blockchain, and a validity inheritance relationship with the previous stage is established;

[0142] A freeze processing module is configured to, when any verification token in the verification set fails verification, block data writing operations in the current stage and all subsequent stages, and generate a freeze mark in the blockchain, indicating that data in all subsequent stages starting from the verification failure node are not eligible for blockchain validity traceability;

[0143] A state restriction module, which is used to mark the frozen subsequent stage blocks as non-updatable after the frozen state is generated, and restrict them from participating in any validity judgment, traceability analysis, and trusted reference operations based on the chain state in the blockchain;

[0144] An audit structure construction module is used to construct an audit structure associated with the freeze mark, access the interrupted logistics chain information based on the freeze mark, and perform on-chain audit and evidence storage of the status elements of the frozen node and the reasons for verification failure.

[0145] In a further implementation, the multiple verification tokens include summary tokens, signature tokens and rule tokens, wherein the summary tokens are used to verify the hash summary consistency of the stage data field, the signature tokens are used to verify the legitimacy of the signature of the preset field, and the rule tokens are used to verify whether the stage data complies with the preset logical rules and boundary conditions. The verification operations of the three types of tokens respectively call the summary calculation module, the public key verification module and the rule matching module, and allow the current stage data to be uploaded to the chain when the verification results are all passed.

[0146] In a further implementation, the freeze mark is generated by a freeze control module and recorded in the on-chain status structure in the form of a freeze instruction. The freeze instruction includes the stage identifier of the failure stage, the numbering information of the failure token, the classification code of the failure type, and the marked range of the freeze boundary. The freeze instruction generates a frozen node in the chain structure. The frozen node establishes a logical link with the failure stage node through a structural reference and has unique identification information for subsequent on-chain traceability positioning and verification obstacle identification.

[0147] In a further implementation, the blocks in the frozen state are set to a non-updatable state in the blockchain structure, and the non-updatable state includes prohibiting data appending, prohibiting field modification, and prohibiting summary rewriting. The system restricts the blocks in the frozen state from participating in any state evaluation calculation based on on-chain data, traceable path analysis, and cross-system trusted reference calls, to prevent subsequent on-chain state pollution caused by the existence of verification failed nodes.

[0148] In a further implementation, the audit structure associated with the freeze mark includes an on-chain frozen node and an on-chain audit record unit. The system accesses the data content of the frozen node based on the failure token information recorded in the freeze mark, collects status fields, verification policies, and trigger node contexts, generates a structured audit record containing the reason for the verification failure, and writes the audit record into the on-chain audit area in an unalterable manner to support subsequent audit evidence collection, node responsibility analysis, and abnormal evolution path backtracing.

[0149] It should be noted that the explanation of the aforementioned blockchain-based medical logistics data traceability method embodiment is also applicable to the device of the embodiment of this application and will not be repeated here.

[0150] Those skilled in the art will appreciate that the various units and algorithm steps described in the embodiments disclosed herein can be implemented using a combination of electronic hardware, computer software, and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians 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.

[0151] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0152] In the several embodiments provided in this application, if any function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the method described in each embodiment of this application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (Read-Only Memory; hereinafter referred to as: ROM), random access memory (Random Access Memory; hereinafter referred to as: RAM), magnetic disk or optical disk, and other media that can store program code.

[0153] The above is only a specific embodiment of the present application. Any person skilled in the art can easily think of changes or replacements within the technical scope disclosed in this application, which should be included in the scope of protection of this application. For some module structures that are not particularly clear in the present invention, the content recorded in the prior art shall prevail. The prior art mentioned in the above background technology section and the specific embodiment section of the present invention can be regarded as part of the present invention and is used to understand the meaning of some technical features or parameters.

Claims

1. A medical logistics data traceability method based on blockchain, characterized in that: The method comprises the following steps: In the medical logistics process, the circulation of medical supplies is divided into stages to form a multi-stage logistics process with sequential dependencies, and the logistics data corresponding to each stage is collected as stage data; Preprocessing the stage data to generate a corresponding block data structure, and after completing data writing in each stage, generating multiple verification tokens based on the block content of that stage, wherein the multiple verification tokens respectively correspond to preset elements of different dimensions in the stage, and the multiple verification tokens logically constitute a verification set; Before entering the next stage, the verification set is extracted from the previous stage, and the status verification operation is performed on all verification tokens in the set one by one. If all verification tokens in the verification set pass the verification, the data of the current stage is allowed to be written to the blockchain, and the validity inheritance relationship with the previous stage is established; If any verification token in the verification set fails verification, data writing operations in the current stage and all subsequent stages are blocked, and a freeze mark is generated in the blockchain, indicating that all subsequent stage data from the verification failure node are not eligible for blockchain validity traceability; After the frozen state is generated, the subsequent stage blocks to be frozen are marked as non-updatable and restricted from participating in any validity judgment, traceability analysis and trusted reference operations based on the chain state in the blockchain; An audit structure associated with the freeze mark is constructed, and the interrupted logistics chain information is accessed based on the freeze mark. The status elements of the frozen nodes and the reasons for verification failure are audited and recorded on the chain.

2. The blockchain-based medical logistics data traceability method according to claim 1 is characterized in that: The multiple verification tokens include summary tokens, signature tokens and rule tokens, among which the summary tokens are used to verify the hash summary consistency of the stage data field, the signature tokens are used to verify the legality of the signature of the preset field, and the rule tokens are used to verify whether the stage data complies with the preset logical rules and boundary conditions. The verification operations of the three types of tokens respectively call the summary calculation module, the public key verification module and the rule matching module, and allow the current stage data to be uploaded to the chain when the verification results are all passed.

3. The blockchain-based medical logistics data traceability method according to claim 1 is characterized in that: The freeze mark is generated by the freeze control module and recorded in the on-chain status structure in the form of a freeze instruction. The freeze instruction includes the stage identifier of the failure stage, the number information of the failure token, the classification code of the failure type and the marked range of the freeze boundary. The freeze instruction generates a frozen node in the chain structure. The frozen node establishes a logical link with the failure stage node through a structural reference and has unique identification information for subsequent on-chain traceability positioning and verification obstacle identification.

4. The blockchain-based medical logistics data traceability method according to claim 1 is characterized in that: The blocks in the frozen state are set to a non-updatable state in the blockchain structure. The non-updatable state includes prohibiting data appending, prohibiting field modification, and prohibiting summary rewriting. The system also restricts the blocks in the frozen state from participating in any state evaluation calculations based on on-chain data, traceable path analysis, and cross-system trusted reference calls, to prevent subsequent on-chain state pollution caused by the existence of verification failed nodes.

5. The blockchain-based medical logistics data traceability method according to claim 1 is characterized in that: The audit structure associated with the freeze mark includes an on-chain frozen node and an on-chain audit record unit. The system accesses the data content of the frozen node based on the failure token information recorded in the freeze mark, collects status fields, verification policies, and trigger node contexts, generates a structured audit record containing the reason for the verification failure, and writes the audit record into the on-chain audit area in an unalterable manner to support subsequent audit evidence collection, node responsibility analysis, and abnormal evolution path backtracking.

6. A blockchain-based medical logistics data traceability system, characterized by: The system comprises: The stage division module is used to divide the flow of medical supplies into stages during the medical logistics process, forming a multi-stage logistics process with sequential dependencies, and collecting the logistics data corresponding to each stage as stage data; A block construction module is configured to pre-process the data of the stages to generate a corresponding block data structure, and after completing data writing at each stage, generate multiple verification tokens based on the block content of that stage, wherein the multiple verification tokens respectively correspond to preset elements of different dimensions in the stage, and the multiple verification tokens logically constitute a verification set; A verification control module is configured to extract the verification set from the previous stage before entering the next stage, and perform status verification operations on all verification tokens in the set one by one. If all verification tokens in the verification set pass verification, the data of the current stage is allowed to be written to the blockchain, and a validity inheritance relationship with the previous stage is established; A freeze processing module is configured to, when any verification token in the verification set fails verification, block data writing operations in the current stage and all subsequent stages, and generate a freeze mark in the blockchain, indicating that data in all subsequent stages starting from the verification failure node are not eligible for blockchain validity traceability; A state restriction module, which is used to mark the frozen subsequent stage blocks as non-updatable after the frozen state is generated, and restrict them from participating in any validity judgment, traceability analysis, and trusted reference operations based on the chain state in the blockchain; An audit structure construction module is used to construct an audit structure associated with the freeze mark, access the interrupted logistics chain information based on the freeze mark, and perform on-chain audit and evidence storage of the status elements of the frozen node and the reasons for verification failure.

7. The blockchain-based medical logistics data traceability system according to claim 6 is characterized in that: The multiple verification tokens include summary tokens, signature tokens and rule tokens, among which the summary tokens are used to verify the hash summary consistency of the stage data field, the signature tokens are used to verify the legality of the signature of the preset field, and the rule tokens are used to verify whether the stage data complies with the preset logical rules and boundary conditions. The verification operations of the three types of tokens respectively call the summary calculation module, the public key verification module and the rule matching module, and allow the current stage data to be uploaded to the chain when the verification results are all passed.

8. The blockchain-based medical logistics data traceability system according to claim 6 is characterized in that: The freeze mark is generated by the freeze control module and recorded in the on-chain status structure in the form of a freeze instruction. The freeze instruction includes the stage identifier of the failure stage, the number information of the failure token, the classification code of the failure type and the marked range of the freeze boundary. The freeze instruction generates a frozen node in the chain structure. The frozen node establishes a logical link with the failure stage node through a structural reference and has unique identification information for subsequent on-chain traceability positioning and verification obstacle identification.

9. The blockchain-based medical logistics data traceability system according to claim 6 is characterized in that: The blocks in the frozen state are set to a non-updatable state in the blockchain structure. The non-updatable state includes prohibiting data appending, prohibiting field modification, and prohibiting summary rewriting. The system also restricts the blocks in the frozen state from participating in any state evaluation calculations based on on-chain data, traceable path analysis, and cross-system trusted reference calls, to prevent subsequent on-chain state pollution caused by the existence of verification failed nodes.

10. The blockchain-based medical logistics data traceability system according to claim 6 is characterized in that: The audit structure associated with the freeze mark includes an on-chain frozen node and an on-chain audit record unit. The system accesses the data content of the frozen node based on the failure token information recorded in the freeze mark, collects status fields, verification policies, and trigger node contexts, generates a structured audit record containing the reason for the verification failure, and writes the audit record into the on-chain audit area in an unalterable manner to support subsequent audit evidence collection, node responsibility analysis, and abnormal evolution path backtracking.

Images