Block chain-based drug full-life-cycle data credible tracing method and system

Abstract

The invention discloses a drug full-life-cycle data credible tracing method and system based on a block chain, and relates to the related field of medicine supply chain management, and the method comprises the steps: adding a plurality of transfer nodes to an alliance chain network, and respectively configuring data permissions for the plurality of transfer nodes; respectively extracting a plurality of associated transfer node sets associated with the plurality of data uplink stages from the plurality of transfer nodes, respectively performing encryption joint verification through an asynchronous key segmentation mechanism, and when the verification is passed, performing data uplink of the plurality of data uplink stages by the plurality of associated transfer node sets according to the plurality of data permissions; and the target user scans the drug identifier through the terminal device, performs data tracing on the alliance chain network, performs feedback auditing on the drug use data, and performs uplink in an off-chain storage and on-chain indexing mode to complete closed-loop tracing. The technical problem that privacy protection and cross-link credible cooperation cannot be compatible in existing credible tracing is solved, and the technical effect of privacy protection and cross-link credible sharing is achieved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of pharmaceutical supply chain management, in particular to a blockchain-based pharmaceutical full life cycle data credible traceability method and system. BACKGROUND

[0002] Pharmaceutical full life cycle data credible traceability is the core link of ensuring drug safety, preventing fake drug circulation and realizing quality supervision, and its data authenticity, integrity and cross-link collaboration directly affect public health safety and the trust system of the pharmaceutical industry. The existing technology mainly relies on a single blockchain architecture for drug traceability, stores full-process data on the chain and relies on digital signature to verify the legality of the node. However, the single blockchain architecture adopts a homogeneous node design, resulting in all nodes having equal access rights to full data, and sensitive information being easily obtained by unauthorized nodes. At the same time, a single consensus mechanism cannot adapt to the trust differences in different links of drug circulation, leading to data privacy leakage risk and low cross-link collaboration efficiency.

[0003] At the present stage, there is a technical problem of incompatibility between privacy protection and cross-link credible collaboration in the related art of pharmaceutical full life cycle data credible traceability. SUMMARY

[0004] The present application provides a blockchain-based pharmaceutical full life cycle data credible traceability method and system, which constructs a pharmaceutical full life cycle alliance chain network and assigns differential data rights, uses an asynchronous key segmentation mechanism to encrypt and jointly verify the associated node set of each circulation stage, and after verification, the data is uploaded to the chain by stage according to the rights, the user scans the code for traceability, and the use data is fed back, and after review, it is uploaded to the chain in a "chain storage + chain index" manner, etc. Technical means solve the technical problem of incompatibility between privacy protection and cross-link credible collaboration in the existing pharmaceutical full life cycle data credible traceability, and achieve the technical effect of privacy protection and cross-link credible sharing.

[0005] The present application provides a blockchain-based pharmaceutical full life cycle data credible traceability method, comprising: constructing an alliance chain network, adding a plurality of circulation nodes in the pharmaceutical full life cycle to the alliance chain network, and respectively configuring a plurality of data rights for the plurality of circulation nodes; extracting a plurality of associated circulation node sets associated with a plurality of data uploading stages from the plurality of circulation nodes, respectively encrypting and jointly verifying the plurality of associated circulation node sets through an asynchronous key segmentation mechanism, when the encryption and joint verification is passed, the plurality of associated circulation node sets perform data uploading of the plurality of data uploading stages according to the plurality of data rights; when a target user scans a drug identification through a terminal device, data traceability of the pharmaceutical full life cycle is performed on the alliance chain network, and after feedback and review of drug use data, it is stored off-chain and indexed on-chain to complete closed-loop traceability.

[0006] In a possible implementation, the following processing is performed: the plurality of flow transfer nodes include a bulk drug supply node, a drug production node, a warehousing and transportation node, a wholesale and retail node, a medical institution node, and a patient node.

[0007] In a possible implementation, a plurality of associated flow transfer node sets associated with a plurality of data on-chain stages are extracted from the plurality of flow transfer nodes respectively, and the plurality of associated flow transfer node sets are encrypted and jointly verified through an asynchronous key splitting mechanism. When the encrypted and joint verification is passed, the plurality of associated flow transfer node sets perform data on-chain of the plurality of data on-chain stages according to the plurality of data authorities. The following processing is performed: a first data on-chain stage is extracted from the plurality of data on-chain stages, and a first associated flow transfer node set is extracted from the plurality of associated flow transfer node sets; a first master key is randomly generated based on a trusted hardware module of a consortium chain network; a node quantity of the first associated flow transfer node set is obtained, and a dynamic blank node generator is combined to obtain a dynamic splitting quantity; the first master key is split into a plurality of sub-keys based on the asynchronous key splitting mechanism according to the dynamic splitting quantity, to obtain a set of sub-keys; the set of sub-keys is randomly distributed to the first associated flow transfer node set through different channels for identity binding, to obtain a first associated flow transfer node binding sub-key set; when the first data on-chain stage is triggered, the first associated flow transfer node set can sign data hash through an loT chip and combine the first associated flow transfer node binding sub-key set for encrypted joint verification; if the number of valid first associated flow transfer node binding sub-keys in the first associated flow transfer node binding sub-key set is greater than or equal to a preset quantity threshold, the consortium chain network restores the first master key through a threshold reconstruction algorithm to complete the encrypted joint verification.

[0008] In a possible implementation, according to the dynamic split quantity, the first master key is split based on an asynchronous key split mechanism to obtain a split sub-key set, and the following processing is performed: a historical split sub-key set is obtained; an initial key split bandwidth in the asynchronous key split mechanism is invoked, the first master key is split for the first time, and key reliability verification is performed in combination with the historical split sub-key set, if the verification is passed, a first split sub-key and a first split master key are obtained; if the verification is not passed, the initial key split bandwidth is adjusted multiple times in a random adjustment manner to obtain multiple adjusted key split bandwidths, the first master key is split for the first time by using the multiple adjusted key split bandwidths to obtain multiple adjusted split sub-keys, the multiple adjusted split sub-keys are verified for key reliability respectively, and the first split sub-key and the first split master key are obtained; the first split master key is split for the second time according to the initial key split bandwidth, and key reliability verification is performed in combination with the historical split sub-key set, until the split quantity satisfies the dynamic split quantity minus 1, and the split sub-key set is obtained.

[0009] In a possible implementation, if the verification is passed when the initial key split bandwidth in the asynchronous key split mechanism is invoked to split the first master key for the first time and the key reliability verification is performed in combination with the historical split sub-key set, the following processing is performed: the initial key split bandwidth in the asynchronous key split mechanism is invoked to split the first master key for the first time to obtain a first initial split sub-key; a matching similarity between the first initial split sub-key and historical split sub-keys in the historical split sub-key set is calculated to obtain a matching similarity set; a mean value of the matching similarity set is calculated, and an inverse of a calculation result is taken as a key reliability coefficient; it is judged whether the key reliability coefficient is greater than or equal to a preset key reliability coefficient threshold, if yes, the verification is passed, the first initial split sub-key is taken as the first split sub-key, and a remaining part after the first master key is split is taken as the first split master key.

[0010] In a possible implementation, a node quantity of the first associated flow conversion node set is obtained, a dynamic split quantity is obtained in combination with a dynamic blank node generator, and the following processing is performed: a preset maximum blank node quantity is obtained; a first random number is randomly generated based on the dynamic blank node generator, the first random number is multiplied by the preset maximum blank node quantity to obtain a dynamic blank node quantity; the dynamic blank node quantity is added to the node quantity of the first associated flow conversion node set to obtain the dynamic split quantity.

[0011] In a possible implementation, when the encryption joint verification passes, the multiple associated flow transfer node sets perform data chaining in multiple data chaining stages according to the multiple data authorities, and then the following processing is performed: triggering a smart contract deployed on the alliance chain network to perform real-time checking instructions; based on the real-time checking instructions of the smart contract, calling the loT device signature of the multiple associated flow transfer node sets to perform signature verification and integrity verification on the chained data, to obtain multiple real-time checking results, wherein each real-time checking result includes a signature verification result and an integrity verification result; and based on the multiple real-time checking results, performing a punishment and reward mechanism on the multiple associated flow transfer node sets.

[0012] In a possible implementation, the following processing is performed: the punishment and reward mechanism includes deducting a preset reputation value of the associated flow transfer node when any one of the signature verification result and the integrity verification result fails, and counting the number of deductions; when the number of deductions exceeds a preset deduction threshold, a punishment measure is triggered; and when the signature verification result and the integrity verification result both pass, the preset reputation value of the associated flow transfer node is increased, and the number of increases is counted; when the number of increases exceeds a preset increase threshold, an incentive measure is triggered.

[0013] In a possible implementation, the following processing is performed: the alliance chain network adopts a Byzantine fault tolerance or an authority proof consensus mechanism to ensure data consistency of the multiple flow transfer nodes.

[0014] The application also provides a blockchain-based drug full-life-cycle data trusted traceability system, which includes: an alliance chain network construction module, configured to construct an alliance chain network, add multiple flow transfer nodes in a drug full life cycle to the alliance chain network, and configure multiple data authorities for the multiple flow transfer nodes respectively; an encryption joint verification module, configured to extract multiple associated flow transfer node sets associated with multiple data chaining stages from the multiple flow transfer nodes respectively, perform encryption joint verification on the multiple associated flow transfer node sets respectively through an asynchronous key splitting mechanism, and perform data chaining in multiple data chaining stages according to the multiple data authorities when the encryption joint verification passes; and a traceability module, configured to perform data tracing of a drug full life cycle on the alliance chain network when a target user scans a drug identifier through a terminal device, and perform off-chain storage and on-chain indexing of drug use data after feedback auditing, to complete closed-loop tracing.

[0015] The application provides a blockchain-based drug full-life-cycle data credible tracing method and system. First, a consortium chain network is constructed, multiple flow nodes in the drug full-life-cycle are added to the consortium chain network, and multiple data permissions are configured for the multiple flow nodes respectively, then multiple associated flow node sets associated with multiple data on-chain stages are extracted from the multiple flow nodes respectively, the multiple associated flow node sets are encrypted and jointly verified through an asynchronous key splitting mechanism, when the encryption and joint verification is passed, the multiple associated flow node sets perform data on-chain of the multiple data on-chain stages according to the multiple data permissions, finally, when a target user scans a drug identifier through a terminal device, the consortium chain network is subjected to data tracing of the drug full-life-cycle, and drug use data is fed back for audit, and then is stored off-chain and indexed on-chain for on-chain, and closed-loop tracing is completed. The technical effects of privacy protection and cross-link credible sharing are achieved. BRIEF DESCRIPTION OF DRAWINGS

[0016] In order to more clearly illustrate the technical solutions of the embodiments of the application, the drawings of the embodiments of the application will be briefly introduced below. In the present application, a flowchart is used to illustrate the operations performed by the system according to the embodiments of the application. It should be understood that the foregoing or the following operations are not necessarily performed in sequence. On the contrary, according to the needs, various steps can be processed in reverse order or simultaneously. At the same time, other operations can be added to these processes, or one or more steps of operation can be removed from these processes.

[0017] Figure 1 The flowchart of the blockchain-based drug full-life-cycle data credible tracing method provided by the embodiments of the application is shown.

[0018] Figure 2 The structure diagram of the blockchain-based drug full-life-cycle data credible tracing system provided by the embodiments of the application is shown.

[0019] The reference signs are explained as follows: the consortium chain network construction module 10, the encryption joint verification module 20, and the tracing module 30. DETAILED DESCRIPTION

[0020] The above description is only a summary of the technical solutions of the application. In order to more clearly understand the technical means of the application, the application can be implemented according to the content of the specification, and in order to make the above and other purposes, features and advantages of the application more obvious and easy to understand, the following specific embodiments of the application are described.

[0021] In order to make the purposes, technical solutions and advantages of the present application clearer, the present application will be further described in detail below with reference to the drawings. The described embodiments should not be regarded as limitations to the present application. All other embodiments obtained by those of ordinary skill in the art without creative labor fall within the scope of protection of the present application.

[0022] In the following description, "some embodiments" are referred to, which describe a subset of all possible embodiments, but it can be understood that "some embodiments" can be the same subset or different subsets of all possible embodiments, and can be combined with each other without conflict. The term "first\second" referred to is only to distinguish similar objects, and does not represent a specific order of the objects. The terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product or server including a series of steps or units does not have to be limited to those steps or units clearly listed, but can include other steps or modules that are not clearly listed or inherent to these processes, methods, products or devices. Unless otherwise defined, all technical and scientific terms used herein have the same meaning as understood by those skilled in the art to which the present application belongs. The terms used herein are only for the purpose of describing the embodiments of the present application.

[0023] The embodiments of the present application provide a blockchain-based drug full-life-cycle data trusted traceability method, as shown in Figure 1 The method comprises the following steps:

[0024] In step S100, a consortium chain network is constructed, a plurality of circulation nodes in the full life cycle of a drug are added to the consortium chain network, and a plurality of data authorities are respectively configured for the plurality of circulation nodes. The plurality of circulation nodes include a bulk drug supply node, a drug production node, a warehousing and transportation node, a wholesale and retail node, a medical institution node and a patient node. The consortium chain network adopts a Byzantine fault tolerance or authority proof consensus mechanism, which is used to ensure the data consistency of the plurality of circulation nodes.

[0025] Specifically, an open-source consortium chain framework such as Hyperledger Fabric and FISCO BCOS is used as the underlying framework to build a consortium chain network. The consortium chain is a blockchain maintained by multiple pre-authorized organizations, which balances decentralization and permission control. Independent blockchain nodes are deployed for each flow node, including API supplier, drug production, warehousing and transportation, wholesale and retail, medical institutions, patients, regulatory agencies, etc. The nodes communicate through a P2P network. The consortium chain network uses Byzantine fault tolerance or authority proof consensus mechanism. The Byzantine fault tolerance consensus mechanism allows some faulty or malicious nodes in the network, but still ensures normal operation of the system. The authority proof consensus mechanism is a consensus mechanism that relies on a few authoritative nodes to verify transactions, suitable for high-throughput scenarios, for example, authoritative nodes such as regulatory agencies and large pharmaceutical companies act as verifiers to confirm transactions through pre-authorized signatures, improving transaction processing efficiency.

[0026] The permission management contract is written in Solidity or Chaincode to configure data permissions, for example, API supplier nodes can only upload API batch data and quality inspection reports; medical institution nodes can query drug whole-process data, but can only upload patient medication records. At the same time, sensitive data such as patient privacy is attribute-based encrypted, only users who meet certain attributes can decrypt and view, such as doctors in a Level III hospital.

[0027] Step S200, extracting a plurality of associated flow node sets associated with a plurality of data on-chain stages from the plurality of flow nodes respectively, and performing encrypted joint verification on the plurality of associated flow node sets through an asynchronous key splitting mechanism. When the encrypted joint verification is passed, the plurality of associated flow node sets perform data on-chain in the plurality of data on-chain stages according to the plurality of data permissions.

[0028] Specifically, the drug life cycle is divided into API procurement, production, transportation, sales, and use stages, each stage being associated with a specific node set. For example, the production stage is associated with API supplier nodes and production nodes; the transportation stage is associated with warehousing and transportation nodes and wholesale and retail nodes. The mapping relationship between nodes and stages is defined by a smart contract, for example, "if the drug batch is X, the production stage needs to include API supplier nodes and drug production nodes".

[0029] Asynchronous key splitting refers to splitting an encryption key into multiple parts, which are held by different nodes and need to cooperate to complete decryption or signature. For example, key splitting uses the Shamir secret sharing scheme to split the master key into n parts and distribute them to some nodes in the associated node set. For example, if the threshold is equal to 3, at least 3 nodes are needed to cooperate to recover the key. Asynchronous verification means that nodes locally sign data with partial keys, and the alliance chain network verifies data integrity by pulling enough signatures. For example, production stage data needs to be signed by raw material supply nodes, drug production nodes, and quality inspection nodes. If a node is offline, other nodes can make up the signature. After verification, the data is stored in the blockchain ledger in an encrypted form, and only authorized nodes can decrypt and view it through the permission contract.

[0030] In one possible implementation, a plurality of associated flow transfer node sets associated with a plurality of data on-chain stages are extracted from the plurality of flow transfer nodes respectively, and the plurality of associated flow transfer node sets are encrypted and jointly verified by an asynchronous key splitting mechanism. When the encrypted joint verification is passed, the plurality of associated flow transfer node sets perform data on-chain of the plurality of data on-chain stages according to the plurality of data permissions. Step S200 further includes step S210, extracting a first data on-chain stage from the plurality of data on-chain stages, and extracting a first associated flow transfer node set from the plurality of associated flow transfer node sets. Specifically, one stage is selected from the pre-divided plurality of data on-chain stages, such as raw material procurement, production, transportation, sales, and use stages, as the first data on-chain stage. Here, "first" does not represent the order, but only refers to any one of the plurality of stages. At the same time, the associated flow transfer node set corresponding to the first data on-chain stage, i.e. the first associated flow transfer node set, is extracted from the plurality of associated flow transfer node sets associated with each data on-chain stage. For example, if the first data on-chain stage is the production stage, the first associated flow transfer node set includes raw material supply nodes and drug production nodes.

[0031] Step S220, a first master key is randomly generated based on a trusted hardware module of the alliance chain network. Specifically, a master key for encryption is randomly generated based on the trusted hardware module of the alliance chain network, which is called the first master key. The trusted hardware module is used to provide a secure environment to ensure that the generated key has high security and randomness.

[0032] Step S230, the number of nodes of the first associated flow transfer node set is obtained, and the dynamic blank node generator is combined to obtain the dynamic splitting number. Specifically, the number of nodes in the first associated flow transfer node set, i.e. the number of nodes participating in the data on-chain stage, is obtained. The dynamic blank node generator is combined to dynamically determine the number of key splits. The dynamic blank node generator can flexibly adjust the number of splits according to the actual situation to enhance the adaptability and security of the system.

[0033] Step S240, according to the dynamic number of divisions, the first master key is divided based on the asynchronous key division mechanism to obtain a set of divided sub-keys. Specifically, according to the dynamic number of divisions determined in step S230, the first master key is divided by using the asynchronous key division mechanism. Asynchronous key division refers to splitting the encryption key into multiple parts, that is, splitting the first master key into multiple sub-keys to obtain a set of divided sub-keys. For example, the Shamir secret sharing scheme is used to split the master key into n parts.

[0034] Step S250, the set of divided sub-keys is randomly distributed to the first associated flow transfer node set through different channels for identity binding to obtain a first associated flow transfer node binding divided sub-key set. Specifically, the set of divided sub-keys is randomly distributed to each node in the first associated flow transfer node set through different channels, and the divided sub-keys are identity-bound to the nodes. In this way, each node holds part of the divided sub-keys, and the distribution through different channels can reduce the risk of key leakage. Only the legal nodes can obtain the corresponding divided sub-keys.

[0035] Step S260, when the first data on-chain stage is triggered, the first associated flow transfer node set can sign the data hash through the loT chip and combine the first associated flow transfer node binding divided sub-key set for encrypted joint verification. Specifically, when the first data on-chain stage is triggered, the nodes in the first associated flow transfer node set can calculate the hash of the data to be chained through the Internet of Things (IoT) chip to obtain the hash value of the data. Then, each node signs the data hash according to the bound divided sub-key to confirm the integrity of the data and the authenticity of the source.

[0036] Step S270, if the number of valid first associated flow transfer node binding divided sub-keys in the first associated flow transfer node binding divided sub-key set is greater than or equal to a preset number threshold, the consortium chain network recovers the first master key through a threshold reconstruction algorithm to complete the encrypted joint verification. Specifically, the number of valid first associated flow transfer node binding divided sub-keys in the first associated flow transfer node binding divided sub-key set is checked. Among them, the valid divided sub-key refers to the key that can normally participate in the verification process and has not been tampered with or leaked. If the number of valid first associated flow transfer node binding divided sub-keys is greater than or equal to the preset number threshold, it indicates that enough legal nodes participate in the verification process, at which time the consortium chain network recovers the first master key through the threshold reconstruction algorithm. The threshold reconstruction algorithm can recover the original master key according to part of the divided sub-keys, thereby completing the encrypted joint verification. Only after verification, the first associated flow transfer node set can perform data on-chain operation in the first data on-chain stage according to the pre-configured multiple data permissions.

[0037] In a possible implementation, the number of nodes in the first set of associated flow transfer nodes is obtained, a dynamic blank node generator is combined to obtain a dynamic splitting number, and step S230 further includes step S231 of obtaining a preset maximum blank node number. Specifically, a maximum blank node threshold is preset, such as 10, 20, or the like. The value is determined based on system security requirements and performance balance. Too high may cause the splitting number to be too large to increase the computing overhead, and too low may weaken randomness. The preset maximum blank node number is used to provide an upper limit constraint for dynamic blank node generation, to ensure that the number of randomly generated blank nodes does not exceed the system processing capability.

[0038] Step S232, a first random number is randomly generated based on the dynamic blank node generator, the first random number is multiplied by the preset maximum blank node number, and the dynamic blank node number is obtained. Specifically, a random number in the interval [0, 1] is generated through the dynamic blank node generator, such as a Rand function. The random number is multiplied by the preset maximum value and is rounded, such as rounded or rounded down, to obtain the dynamic blank node number. By introducing randomness, the number of blank nodes in each splitting is dynamically changed, avoiding the fixed mode being used by attackers, and improving the system attack resistance.

[0039] Step S233, the dynamic blank node number is added to the number of nodes in the first set of associated flow transfer nodes to obtain a dynamic splitting number. Specifically, the dynamic blank node number is added to the actual number of nodes in the first set of associated flow transfer nodes to obtain the dynamic splitting number. For example, if the associated node set in a certain stage has 5 nodes, and the dynamic blank node number is 3, then the dynamic splitting number is 8. By randomly adding blank nodes, the complexity of key splitting is increased to prevent the splitting strategy from being inferred from the number of nodes.

[0040] In a possible implementation, according to the dynamic splitting number, the first master key is asynchronously split based on an asynchronous key splitting mechanism to obtain a set of split sub-keys, and step S240 further includes step S241 of obtaining a set of historical split sub-keys. Specifically, a set of historical split sub-keys generated when the key splitting operation is performed previously is obtained from the storage. These historical split sub-keys are generated in other data chaining stages or related encryption scenarios, and can be used as a reference basis to evaluate the reliability of the sub-key obtained by the current splitting. For example, the set of historical split sub-keys includes a plurality of sub-keys and related use information of the sub-keys obtained by splitting in different data chaining stages in the past period of time.

[0041] Step S242, the initial key splitting bandwidth in the asynchronous key splitting mechanism is called to split the first master key for the first time and combine the historical split sub-key set for key reliability verification. If the verification is passed, the first split sub-key and the first split master key are obtained. Specifically, the initial key splitting bandwidth in the asynchronous key splitting mechanism is called, which is the sub-key length obtained by equally dividing the first master key according to the dynamic splitting number. For example, if the length of the first master key is 1024 bits and the dynamic splitting number is 4, the initial key splitting bandwidth is 256 bits. The first master key is split for the first time using the initial key splitting bandwidth to obtain a sub-key (i.e., a candidate for the first split sub-key) and a remaining part after splitting (i.e., the first split master key).

[0042] The sub-key obtained by the first splitting is compared and analyzed with the historical split sub-key set for key reliability verification. The verification indicators can include randomness of the sub-key, similarity with the historical key, whether it meets the requirements of a specific encryption algorithm, etc. If the verification is passed, it means that the sub-key has high reliability, and it is determined as the first split sub-key, while the first split master key is reserved for subsequent splitting.

[0043] Step S243, if the verification is not passed, the initial key splitting bandwidth is adjusted multiple times according to a random adjustment method to obtain multiple adjusted key splitting bandwidths, and the first master key is split for the first time using the multiple adjusted key splitting bandwidths to obtain multiple adjusted split sub-keys, and the multiple adjusted split sub-keys are verified for key reliability to obtain the first split sub-key and the first split master key. Specifically, if the sub-key obtained by the first splitting is not verified, the initial key splitting bandwidth is adjusted according to a random adjustment method. The adjustment direction is smaller than the initial key splitting bandwidth, which is used to ensure that the final splitting number can meet the requirements of the dynamic splitting number after multiple adjustments. For example, the initial key splitting bandwidth is 256 bits, which can be adjusted to 200 bits, 180 bits, etc. during random adjustment. Multiple adjusted key splitting bandwidths are obtained by multiple adjustments, and then the first master key is split for the first time using the multiple adjusted key splitting bandwidths to obtain multiple adjusted split sub-keys. The multiple adjusted split sub-keys are verified for key reliability. In the verification process, multiple indicators are combined to select the split sub-key that meets the requirements and has the highest reliability as the first split sub-key, and the corresponding first split master key is determined.

[0044] Step S244, the first split master key is split for the second time according to the initial key split bandwidth again, and key reliability verification is performed in combination with the historical split sub-key set until the split number satisfies the dynamic split number minus 1, and the split sub-key set is obtained. Specifically, the first split master key is split for the second time according to the initial key split bandwidth again, and a new sub-key (candidate) and a remaining part are obtained. The sub-key obtained by the second split is subjected to key reliability verification with the historical split sub-key set. The above-mentioned second split and verification process is repeated, and a sub-key is generated each time the split is performed until the split number satisfies the dynamic split number minus 1. The master key remaining after the last split is directly used as the last sub-key, and finally the split sub-key set containing multiple reliable sub-keys is obtained.

[0045] In a possible implementation, the initial key split bandwidth in the asynchronous key split mechanism is called to split the first master key for the first time, and key reliability verification is performed in combination with the historical split sub-key set. If the verification is passed, the first split sub-key and the first split master key are obtained. Step S242 further includes step S2421 of calling the initial key split bandwidth in the asynchronous key split mechanism to split the first master key for the first time to obtain the first initial split sub-key. Specifically, the first master key is split using the obtained initial key split bandwidth, and a sub-key, i.e., the first initial split sub-key, and a remaining part of the master key after the split are obtained.

[0046] Step S2422, the matching similarity of the first initial split sub-key and the historical split sub-key in the historical split sub-key set is calculated, and a matching similarity set is obtained. Specifically, each historical split sub-key in the historical split sub-key set is taken out in turn, and for each taken historical split sub-key, the matching similarity of the first initial split sub-key is calculated. The matching similarity can be calculated by using a variant of the Hamming distance. The Hamming distance refers to the number of different characters of two equal-length strings at the same position, and the matching similarity can be defined as (1-Hamming distance / key length). Assuming that the first initial split sub-key is 1010 and a historical split sub-key is 1001, the Hamming distance is 2, and the key length is 4, and the matching similarity is 1-2 / 4=0.5. The matching similarity calculated by each historical split sub-key and the first initial split sub-key is recorded to form a matching similarity set.

[0047] Step S2423, the mean of the matching similarity set is calculated, and the reciprocal of the calculation result is taken as the key reliability coefficient. Specifically, the average of all elements in the matching similarity set is calculated, and the reciprocal of the average of the matching similarity set is taken as the key reliability coefficient. Wherein, the reciprocal is used in order to make the key reliability coefficient and the overall situation of the matching similarity set present inverse relationship, that is, the lower the matching similarity, the higher the key reliability coefficient.

[0048] Step S2424, it is judged whether the key reliability coefficient is greater than or equal to a preset key reliability coefficient threshold value, if yes, the verification is passed, the first initial split sub-key is taken as the first split sub-key, and the part remaining after the first master key is split is taken as the first split master key. Specifically, the calculated key reliability coefficient is compared with the preset key reliability coefficient threshold value. The preset key reliability coefficient threshold value is a value set according to actual security requirements and experience. If the key reliability coefficient is greater than or equal to the preset key reliability coefficient threshold value, it is indicated that the difference between the first initial split sub-key and the historical split sub-key is large enough, and the reliability is high, and the verification is passed. At this time, the first initial split sub-key is determined as the first split sub-key, and the part remaining after the first split is taken as the first split master key, which is used for subsequent key splitting operation. If the key reliability coefficient is less than the preset key reliability coefficient threshold value, it is indicated that the first initial split sub-key is too similar to the historical split sub-key, and there is a security risk, and the verification is not passed. At this time, the initial key splitting bandwidth is adjusted in a random adjustment mode, and the splitting and verification operation are performed again until the reliable sub-key is obtained.

[0049] In a possible implementation, when the encryption joint verification is passed, the multiple associated flow transfer node sets perform data chaining in multiple data chaining stages according to the multiple data authorities, and then the method further includes: triggering a smart contract deployed in the alliance chain network to perform real-time checking instructions; based on the real-time checking instructions of the smart contract, calling the loT device signature of the multiple associated flow transfer node sets to perform signature verification and integrity verification on the chained data, and obtaining multiple real-time checking results, wherein each real-time checking result includes a signature verification result and an integrity verification result; based on the multiple real-time checking results, performing a punishment and reward mechanism on the multiple associated flow transfer node sets.

[0050] Specifically, when the encryption joint verification passes, the smart contract automatically deployed by the alliance chain network is activated to generate real-time verification instructions. The instructions can be triggered based on a timestamp, event-driven or external signals. The digital signature generated by the IoT device of each node in the associated flow transfer node set is called, and the smart contract verifies the validity of the signature through a preset public key to confirm the authenticity and non-tampering of the data source. For example, the batch data uploaded by the raw material drug supply node needs to be accompanied by the signature of its IoT device, and if the verification fails, it is marked as abnormal. Hash verification is performed on the on-chain data, and the hash value stored on the blockchain is compared with the recalculated hash value to detect whether the data has been tampered with during transmission or storage. Each node generates a binary result set containing signature verification results and integrity verification results. Among them, the signature verification result contains pass or fail, and the integrity verification result includes consistent or inconsistent. For nodes that pass the verification for a continuous number of times, their data rights are improved, their credit scores are increased, or they are given economic rewards such as token incentives. For nodes that fail the verification, gradient penalties are taken according to the severity, for example, if it is mild, a warning is issued, the data is required to be resubmitted with additional verification; if it is moderate, the rights are temporarily reduced, and a manual review process is started; if it is severe, the node is permanently removed, listed on a blacklist and publicized, and its subsequent participation in the alliance chain is affected.

[0051] In a possible implementation, the punishment and reward mechanism further includes: when any one of the signature verification result and the integrity verification result does not pass, a preset reputation value of the associated flow transfer node is deducted, and the number of deductions is counted, and when the number of deductions exceeds a preset deduction threshold, a punishment measure is triggered; when the signature verification result and the integrity verification result both pass, the preset reputation value of the associated flow transfer node is increased, and the number of increases is counted, and when the number of increases exceeds a preset increase threshold, an incentive measure is triggered.

[0052] Specifically, when joining the alliance chain, each associated flow transfer node is assigned an initial reputation value, such as 100 points, which is stored in a smart contract or a chain reputation account. When either the signature verification result or the integrity verification result does not pass, i.e. signature = fail or integrity = inconsistent, the associated flow transfer node is deducted by a preset reputation value, and each failure is deducted by a fixed value or by a percentage. When the signature and integrity verification both pass, i.e. signature = pass and integrity = consistent, the associated flow transfer node is increased by a preset reputation value, and each success is increased by a fixed value or by a percentage.

[0053] The preset deduction threshold, such as 3 consecutive failures, if the cumulative number of deductions of a node is greater than the preset deduction threshold, a punishment measure is triggered, such as temporarily limiting data upload rights, permanently removing the node and publicizing it, freezing its on-chain assets such as tokens, reputation collateral, etc.

[0054] A preset increase threshold, such as 10 consecutive successes, is set. If the cumulative increase number of a certain node is greater than the preset increase threshold, an incentive measure is triggered, such as issuing a consortium chain token, preferentially participating in high-value data transactions, upgrading permissions, and the like.

[0055] For a node that has not participated in verification for a long time, the reputation value is decayed over time, for example, automatically deducted by 1 point per month, to avoid zombie nodes occupying resources. At the same time, the threshold is dynamically adjusted according to the overall security situation of the consortium chain, such as reducing the preset deduction threshold to strengthen management and control during a high-attack period. All reputation value changes and reward and punishment records are written into the blockchain for supervision by all nodes in the chain.

[0056] In step S300, after the target user scans the drug identification through the terminal device, the drug full life cycle data is traced on the consortium chain network, and the drug use data is fed back for audit and stored off-chain and indexed on-chain for uploading, completing the closed-loop tracing.

[0057] Specifically, after the target user, i.e., the patient, purchases the drug, the target user scans the drug identification through a terminal device such as a mobile phone. The drug identification is a unique identifier of the drug, which can adopt a GS1 standard or a self-defined code and is bound to the full life cycle data of the drug. The identifier is encoded into a two-dimensional code or implanted into an NFC chip, so that the terminal device can scan and read. After the target user scans the identification, the terminal application calls the consortium chain node through an API to query all uploaded data of the drug from raw materials to the current link. For example, the patient scans the two-dimensional code on the drug box to view the production date, transportation temperature record, and sales pharmacy information.

[0058] The medical institution node submits the patient medication data such as a prescription, efficacy, and adverse reactions to the consortium chain for audit of authenticity by the regulatory node or the pharmaceutical enterprise node and uploading. Among them, large files such as CT images are stored in a distributed file storage system or a cloud storage, and only the file hash value is saved as an index on the chain to save space.

[0059] The embodiments of the present application adopt the technologies of constructing a drug full life cycle consortium chain network and assigning differentiated data permissions, using an asynchronous key segmentation mechanism to encrypt and jointly verify the associated node set of each transfer stage, uploading the data in stages according to the permissions after verification, feeding back the use data when the user scans the code for tracing, and closing the loop by uploading the data in a “off-chain storage + on-chain indexing” manner after audit, to solve the technical problem that the existing drug full life cycle data credible tracing cannot be compatible with privacy protection and cross-link credible cooperation, and achieve the technical effects of privacy protection and cross-link credible sharing.

[0060] In the foregoing, the Figure 1 The drug full life cycle data credible tracing method based on a blockchain according to the embodiments of the present application is described in detail. Next, the Figure 2A blockchain-based pharmaceutical full-life-cycle data credible traceability system according to an embodiment of the present application is described.

[0061] The blockchain-based pharmaceutical full-life-cycle data credible traceability system according to the embodiment of the present application is used to solve the technical problem that the existing pharmaceutical full-life-cycle data credible traceability cannot be compatible with privacy protection and cross-link credible cooperation, and achieve the technical effect of privacy protection and cross-link credible sharing. The blockchain-based pharmaceutical full-life-cycle data credible traceability system comprises a consortium chain network construction module 10, an encryption joint verification module 20, and a traceability module 30.

[0062] The consortium chain network construction module 10 is configured to construct a consortium chain network, add a plurality of flow nodes in a pharmaceutical full life cycle to the consortium chain network, and configure a plurality of data permissions for the plurality of flow nodes respectively. The encryption joint verification module 20 is configured to extract a plurality of associated flow node sets associated with a plurality of data on-chain stages from the plurality of flow nodes respectively, perform encryption joint verification on the plurality of associated flow node sets respectively through an asynchronous key division mechanism, and when the encryption joint verification is passed, the plurality of associated flow node sets perform data on-chain of the plurality of data on-chain stages according to the plurality of data permissions. The traceability module 30 is configured to perform data traceability of a pharmaceutical full life cycle on the consortium chain network when a target user scans a pharmaceutical identifier through a terminal device, and perform on-chain in a manner of off-chain storage and on-chain indexing after feedback auditing of pharmaceutical use data, and complete closed-loop traceability.

[0063] The specific configuration of the consortium chain network construction module 10 is described in detail as follows: as described above, the consortium chain network construction module 10 can further comprise: the plurality of flow nodes comprise a bulk drug supply node, a pharmaceutical production node, a warehousing and transportation node, a wholesale and retail node, a medical institution node, and a patient node.

[0064] The detailed description of the specific configuration of the encryption joint verification module 20 is explained as follows: as described above, the plurality of associated flow node sets associated with the plurality of data on-chain stages are extracted from the plurality of flow nodes, and the plurality of associated flow node sets are subjected to encryption joint verification through an asynchronous key splitting mechanism, when the encryption joint verification is passed, the plurality of associated flow node sets perform data on-chain of the plurality of data on-chain stages according to the plurality of data authorities, the encryption joint verification module 20 can further include: a data extraction unit for extracting a first data on-chain stage from the plurality of data on-chain stages, and extracting a first associated flow node set from the plurality of associated flow node sets; a first master key generation unit for randomly generating a first master key based on a trusted hardware module of a consortium chain network; a dynamic splitting number acquisition unit for acquiring the number of nodes of the first associated flow node set, and obtaining a dynamic splitting number in combination with a dynamic blank node generator; an asynchronous key splitting unit for performing asynchronous key splitting on the first master key based on an asynchronous key splitting mechanism according to the dynamic splitting number, and obtaining a split sub-key set; an identity binding unit for randomly distributing the split sub-key set to the first associated flow node set through different channels for identity binding, and obtaining a first associated flow node binding split sub-key set; an encryption joint verification unit for, when the first data on-chain stage is triggered, the first associated flow node set can sign data hash through an loT chip, and perform encryption joint verification in combination with the first associated flow node binding split sub-key set; a first master key recovery unit for, if the number of valid first associated flow node binding split sub-keys in the first associated flow node binding split sub-key set is greater than or equal to a preset number threshold, the consortium chain network recovers the first master key through a threshold reconstruction algorithm, and completes the encryption joint verification.

[0065] The asynchronous key splitting unit can further include: a historical split subkey set obtaining subunit configured to obtain a historical split subkey set; a key reliability verification subunit configured to call an initial key splitting bandwidth in the asynchronous key splitting mechanism, perform first splitting on the first master key, and perform key reliability verification in combination with the historical split subkey set, and if the verification is passed, obtain a first split subkey and a first split master key; a first split subunit configured to, if the verification is not passed, adjust the initial key splitting bandwidth multiple times in a random adjustment manner, obtain multiple adjusted key splitting bandwidths, perform first splitting on the first master key by using the multiple adjusted key splitting bandwidths, obtain multiple adjusted split subkeys, perform key reliability verification on the multiple adjusted split subkeys respectively, and obtain the first split subkey and the first split master key; and a second split subunit configured to perform second splitting on the first split master key again according to the initial key splitting bandwidth, perform key reliability verification in combination with the historical split subkey set, until the number of times of splitting meets the dynamic splitting number minus 1, and obtain the split subkey set.

[0066] The key reliability verification subunit can further include: an initial key splitting bandwidth calling component configured to call an initial key splitting bandwidth in the asynchronous key splitting mechanism, perform first splitting on the first master key, and obtain a first initial split subkey; a matching similarity calculation component configured to traverse and calculate matching similarities of the first initial split subkey and historical split subkeys in the historical split subkey set, and obtain a matching similarity set; a key reliability coefficient obtaining component configured to calculate a mean value of the matching similarity set, and take a reciprocal of a calculation result as a key reliability coefficient; and a judgment processing component configured to judge whether the key reliability coefficient is greater than or equal to a preset key reliability coefficient threshold, and if yes, the verification is passed, the first initial split subkey is taken as a first split subkey, and a remaining part after the first master key is split is taken as a first split master key.

[0067] The node quantity of the first associated flow transfer node set is obtained, and the dynamic blank node generator is combined to obtain a dynamic segmentation quantity.

[0068] When the encryption joint verification is passed, the multiple associated flow transfer node sets perform data chaining in multiple data chaining stages according to the multiple data authorities, and then the system can further include: a real-time verification instruction triggering module for triggering a smart contract real-time verification instruction deployed in the alliance chain network; a real-time verification module for performing signature verification by calling loT device signatures of the multiple associated flow transfer node sets based on the smart contract real-time verification instruction, and performing integrity verification on the chained data to obtain multiple real-time verification results, wherein each real-time verification result includes a signature verification result and an integrity verification result; and a punishment and reward mechanism implementation module for implementing a punishment and reward mechanism for the multiple associated flow transfer node sets based on the multiple real-time verification results.

[0069] The punishment and reward mechanism implementation module can further include: a punishment measure triggering unit for the punishment and reward mechanism to include a preset reputation value deduction for the associated flow transfer node when any one of the signature verification result and the integrity verification result fails, and to count the number of deductions, and to trigger a punishment measure when the number of deductions exceeds a preset deduction threshold; and an incentive measure triggering unit for increasing a preset reputation value for the associated flow transfer node when both the signature verification result and the integrity verification result pass, and for counting the number of increases, and for triggering an incentive measure when the number of increases exceeds a preset increase threshold.

[0070] The alliance chain network construction module 10 can further include: the alliance chain network adopts a Byzantine fault tolerance or an authority proof consensus mechanism to ensure data consistency of the multiple flow transfer nodes.

[0071] The blockchain-based drug full life cycle data credible traceability system provided in the embodiments of the present application can execute the blockchain-based drug full life cycle data credible traceability method provided in any embodiment of the present application, and has the corresponding function modules and beneficial effects of the execution method.

[0072] Although the present application makes various references to certain modules in the system according to the embodiments of the present application, however, any number of different modules can be used and run on the user terminal and / or server, the various units and modules are only divided according to the functional logic, but are not limited to the above division, as long as the corresponding functions can be realized; in addition, the specific name of each functional unit is only for the convenience of mutual differentiation, and does not serve to limit the protection scope of the present application.

[0073] The above detailed description does not constitute a limitation on the protection scope of the present application. Those skilled in the art should understand that various modifications, combinations and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present application shall be included in the protection scope of the present application. In some cases, the actions or steps described in the present application can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multi-task processing and parallel processing are possible or can be advantageous.

Claims

1. A blockchain-based method for trusted traceability of pharmaceutical lifecycle data, characterized in that: The method includes: Consortium blockchain network is constructed, and multiple circulation nodes throughout the entire life cycle of a drug are added to the consortium blockchain network, and multiple data permissions are configured for each circulation node; Multiple sets of associated circulation nodes are extracted from the multiple circulation nodes and associated with multiple data on-chain stages respectively. The multiple sets of associated circulation nodes are encrypted and jointly verified by an asynchronous key splitting mechanism. When the encryption and joint verification is passed, the multiple sets of associated circulation nodes upload data to the blockchain for multiple data on-chain stages according to the multiple data permissions. When a target user scans a drug label using a terminal device, the consortium blockchain network performs data traceability throughout the entire drug lifecycle. After the drug usage data is reviewed and verified, it is stored off-chain and indexed on-chain to complete closed-loop traceability.

2. The blockchain-based trusted traceability method for the entire lifecycle of pharmaceutical data as described in claim 1, characterized in that, The multiple circulation nodes include raw material supply nodes, drug production nodes, warehousing and transportation nodes, wholesale and retail nodes, medical institution nodes, and patient nodes.

3. The blockchain-based trusted traceability method for the entire lifecycle of pharmaceutical data as described in claim 1, characterized in that, Multiple sets of associated circulation nodes, each linked to a specific data uplink stage, are extracted from the multiple circulation nodes. An asynchronous key splitting mechanism is used to perform encrypted joint verification on each of these sets. When the encrypted joint verification passes, the multiple sets of associated circulation nodes upload data to the blockchain for multiple data uplink stages based on the multiple data permissions, including: Extract the first data on-chain stage from the multiple data on-chain stages, and extract the first associated flow node set from the multiple associated flow node sets; The first master key is randomly generated by a trusted hardware module based on a consortium blockchain network. Get the number of nodes in the first associated flow node set, and combine it with the dynamic blank node generator to obtain the number of dynamic splits; Based on the dynamic number of segments, the first master key is asynchronously segmented using an asynchronous key segmentation mechanism to obtain a set of segmented subkeys. The segmented key set is randomly distributed to the first associated circulation node set through different channels for identity binding, thereby obtaining the first associated circulation node bound segmented key set; When the first data on-chain stage is triggered, the first set of associated circulation nodes can sign the data hash through the IoT chip and perform encrypted joint verification in combination with the first set of associated circulation nodes bound to the segmented key set. If the number of valid first associated transfer node bound to the first associated transfer node in the set of bound sub-keys is greater than or equal to a preset threshold, the consortium blockchain network recovers the first master key through the threshold reconstruction algorithm and completes the encrypted joint verification.

4. The blockchain-based trusted traceability method for the entire lifecycle of pharmaceutical data as described in claim 3, characterized in that, Based on the dynamically segmented number, the first master key is asynchronously segmented using an asynchronous key segmentation mechanism to obtain a set of segmented subkeys, including: Obtain the historical set of slicing keys; The initial key splitting bandwidth in the asynchronous key splitting mechanism is retrieved, the first master key is split for the first time, and the key reliability is verified by combining the historical split sub-key set. If the verification is successful, the first split sub-key and the first split master key are obtained. If the verification fails, the initial key splitting bandwidth is adjusted multiple times in a random adjustment manner to obtain multiple adjusted key splitting bandwidths. The first master key is then split for the first time using the multiple adjusted key splitting bandwidths to obtain multiple adjusted splitting sub-keys. The key reliability of each of the multiple adjusted splitting sub-keys is verified to obtain the first splitting sub-key and the first split master key. The first master key is split a second time according to the initial key splitting bandwidth, and the key reliability is verified by combining the historical split sub-key set until the number of splits meets the dynamic splitting number minus 1, and the split sub-key set is obtained.

5. The blockchain-based trusted traceability method for the entire lifecycle of pharmaceutical data as described in claim 4, characterized in that, The initial key splitting bandwidth in the asynchronous key splitting mechanism is retrieved, the first master key is split for the first time, and key reliability is verified by combining the historical split sub-key set. If the verification passes, the first split sub-key and the first split master key are obtained, including: The initial key splitting bandwidth in the asynchronous key splitting mechanism is retrieved, and the first master key is split for the first time to obtain the first initial split subkey; The matching similarity between the first initial segmentation key and the historical segmentation keys in the historical segmentation key set is calculated to obtain a matching similarity set; Calculate the mean of the matching similarity set, and use the reciprocal of the calculation result as the key reliability coefficient; Determine whether the key reliability coefficient is greater than or equal to the preset key reliability coefficient threshold. If so, the verification is successful, and the first initial split subkey is used as the first split subkey, and the remaining part after splitting the first master key is used as the first split master key.

6. The blockchain-based trusted traceability method for the entire lifecycle of pharmaceutical data as described in claim 3, characterized in that, Obtain the number of nodes in the first associated flow node set, and combine this with the dynamic blank node generator to obtain the dynamic splitting count, including: Get the preset maximum number of blank nodes; A first random number is generated based on a dynamic blank node generator. The first random number is multiplied by a preset maximum number of blank nodes to obtain the number of dynamic blank nodes. The number of dynamic blank nodes is added to the number of nodes in the first associated flow node set to obtain the number of dynamic splits.

7. The blockchain-based trusted traceability method for the entire lifecycle of pharmaceutical data as described in claim 1, characterized in that, When the cryptographic joint verification passes, multiple associated flow node sets perform multiple data on-chain stages according to the multiple data permissions, followed by: Trigger real-time verification instructions for smart contracts deployed on the consortium blockchain network; Based on the real-time verification instruction of the smart contract, the signature of IoT devices in multiple associated circulation node sets is called to perform signature verification, and the integrity verification of the on-chain data is performed to obtain multiple real-time verification results, wherein each real-time verification result includes a signature verification result and an integrity verification result. A penalty and reward mechanism is implemented for the multiple sets of associated circulation nodes based on the multiple real-time verification results.

8. The blockchain-based trusted traceability method for the entire lifecycle of pharmaceutical data as described in claim 7, characterized in that, The penalty and reward mechanism includes deducting a preset reputation value from the associated circulation node when either the signature verification result or the integrity verification result fails, and counting the number of deductions. When the number of deductions exceeds a preset deduction threshold, penalty measures are triggered. When both the signature verification result and the integrity verification result pass, the preset reputation value of the associated circulation node is increased, and the number of increases is counted. When the number of increases exceeds the preset increase threshold, incentive measures are triggered.

9. The blockchain-based trusted traceability method for the entire lifecycle of pharmaceutical data as described in claim 1, characterized in that, The consortium blockchain network employs a Byzantine fault-tolerant or proof-of-authority consensus mechanism to ensure data consistency across multiple circulation nodes.

10. A blockchain-based trusted traceability system for the entire lifecycle of pharmaceutical data, characterized in that: The system is used to implement the blockchain-based trusted traceability method for the entire lifecycle of pharmaceutical data as described in any one of claims 1-9, and the system comprises: The consortium blockchain network construction module is used to build a consortium blockchain network, add multiple circulation nodes throughout the entire life cycle of a drug to the consortium blockchain network, and configure multiple data permissions for each circulation node. The encrypted joint verification module is used to extract multiple sets of associated transfer nodes that are associated with multiple data on-chain stages from the multiple transfer nodes, and to perform encrypted joint verification on the multiple sets of associated transfer nodes through an asynchronous key splitting mechanism. When the encrypted joint verification passes, the multiple sets of associated transfer nodes perform data on-chain for multiple data on-chain stages according to the multiple data permissions. The traceability module is used to trace the entire lifecycle of a drug through the consortium blockchain network when a target user scans the drug label using a terminal device. After feedback and review, the drug usage data is stored off-chain and indexed on-chain to complete closed-loop traceability.

Images