Cross-region and cross-mechanism health medical data security sharing method based on block chain

Abstract

The invention discloses a cross-regional cross-mechanism health medical data security sharing method based on a block chain, and relates to the technical field of data security, and the method comprises the steps: 1, carrying out the content balance fragmentation of an electronic health record, and obtaining a plurality of content fragments, encrypting each content fragment by using a random salt value generated by the head hash value of the previous height block to obtain a salt-added ciphertext fragment; 2, calculating a hash sequence for all salted ciphertext fragments of the same patient and generating a Merkel root; 3, when the external medical institution makes an access application, the chain smart contract compares the identity code set of the applied external medical institution with the patient agreement white list; and when an agreement threshold value set by the patient is met, generating and verifying an access authorization token by adopting a signature mechanism, and writing an authorization result into a block chain auditing side chain. According to the method, the problems of low data sharing efficiency, high trust dependence, difficulty in auditing and the like in a traditional mode are solved.

Description

Technical Field

[0001] The present invention relates to the technical field of data security, and particularly to a method for secure sharing of cross-regional and cross-institutional health care data based on blockchain. Background Art

[0002] In the context of the rapid development of digital healthcare, health care data has become a core resource of great strategic significance. Various medical institutions, regional health platforms, third-party research institutions, and public health management departments have continuously accumulated a large amount of key medical data, such as electronic health records, medical histories, test results, imaging data, and individualized intervention feedback. If this data can be shared securely, efficiently, and compliantly across regions and institutions, it will not only contribute to clinical collaborative diagnosis and treatment, prevention and control of major diseases, and formulation of personalized treatment paths, but also significantly improve the utilization efficiency of medical resources and the level of public health governance. However, due to multiple reasons such as extremely high data sensitivity, complex data ownership structures, and urgent privacy protection needs, current cross-institutional health care data sharing still faces many technical obstacles and trust bottlenecks in actual operation.

[0003] In the existing technology system, the main data sharing modes include centralized data exchange platforms, interoperability interface standards, entrusted data trusteeship, and encrypted transmission protocols. In the centralized platform mode, multiple medical institutions upload some or all of the patient data to a unified platform managed by the government or an authoritative institution, which is responsible for unified storage, indexing, access authorization, and auditing. However, this mode usually brings the problem of transforming information silos into "centralized risk centers" in technical implementation. Once the central platform is attacked, or there is a loophole in a certain permission management link, the trust mechanism of the entire data sharing system will face a serious threat. In addition, the patient's control over personal health data is very limited in this model, and it is difficult to achieve fine-grained access control based on individual wishes.

[0004] Interoperability interface standards, such as HL7, FHIR, etc., although they provide standardized data formats and communication protocols, mainly solve the problem of "being able to understand", rather than the problem of "being able to trust". In actual deployment, different medical institutions have deviations in the interpretation of the standards, inconsistent versions, and poor interface compatibility, resulting in frequent semantic inconsistencies and interoperability failures in the data sharing process. At the same time, in the process of multi-institutional cooperation, there is a lack of guarantee of immutability in data transmission and storage, and any node being invaded or maliciously tampering with data may lead to ambiguous responsibility attribution or even medical accidents. Summary of the Invention

[0005] The objective of the present invention is to provide a cross - regional and cross - institutional health care data security sharing method based on blockchain. This method has strong data integrity verification capabilities, a flexible patient - led access control mechanism, and a decentralized data governance structure, significantly enhancing the security, credibility, and compliance in the process of cross - domain flow of medical data, and solving problems such as low data sharing efficiency, high trust dependence, and difficult auditing in the traditional model.

[0006] To solve the above - mentioned technical problems, the present invention provides a cross - regional and cross - institutional health care data security sharing method based on blockchain, and the method includes: Step 1: Perform content - balanced fragmentation on the electronic health record to obtain multiple content fragments, and each content fragment has a fragment serial number; generate a one - time fragment key based on the patient's public key, fragment serial number, and write - chain timestamp; encrypt each content fragment with a random salt value generated by the hash value of the previous - height block header to obtain a salt - encrypted ciphertext fragment; Step 2: Calculate the hash sequence for all the salt - encrypted ciphertext fragments of the same patient and generate a Merkle root; splice the Merkle root, the hash value of the current - height block header, and the address of the governance - layer smart contract to form a fragment index token; mint and write it into the main blockchain network according to the non - fungible token standard, making it an immutable cross - institutional index asset; Step 3: When an external medical institution submits an access application, the on - chain smart contract compares the set of identity codes of the applying external medical institution with the patient's consent whitelist; when the consent threshold set by the patient is met, a signature mechanism is used to generate and verify an access authorization token, and the authorization result is written into the blockchain audit side - chain.

[0007] Further, in Step 1, call the structured parsing algorithm to scan the electronic health record byte by byte, identify and extract the diagnosis and treatment data elements; attach three types of metadata to each data element: byte length, sensitivity label, and timestamp label; write the data elements and their metadata into a temporary element table; in the temporary element table, calculate the content weight for each data element, sum up the content weights of all data elements, divide the sum of the content weights by a preset segmentation coefficient to obtain the target fragment capacity; if the target fragment capacity is less than the minimum I / O threshold, automatically adjust the preset segmentation coefficient to a smaller value until the target fragment capacity meets the minimum I / O threshold requirement.

[0008] Further, in step 1, a one-way streaming traversal is performed on the temporary element table in the original occurrence order in the electronic health record, including: maintaining an accumulative weight register, starting from 0 to accumulate the content weight of the current data element; when the value of the accumulative weight register first reaches or exceeds the target fragment capacity, immediately insert a boundary marker at the tail of this data element, encapsulate all data elements before the boundary into a content fragment; reset the accumulative weight register to 0, and continue to traverse the unprocessed data elements, repeating the above steps until all data elements are divided; if the value of the accumulative weight register of the last remaining data element is less than 50% of the target fragment capacity, it is merged with the previous content fragment to ensure that the capacity difference between fragments does not exceed ±50%.

[0009] Further, in step 1, the target fragment capacities of all content fragments are statistically analyzed to calculate the capacity variance; if the capacity variance is greater than the set smoothing threshold, two-way adjacent merging is performed: preferentially merge the smallest adjacent content fragment and the second smallest content fragment; update the capacity variance in real time after each merge until the capacity variance does not exceed the smoothing threshold; number all the finally obtained content fragments in logical order, starting from 0 and incrementing, and each number is the unique fragment serial number; calculate a separate pre-encryption hash check code for each content fragment and write it into the integrity field at the tail of the content fragment; combine the fragment serial number, hash check code and sensitivity label into a structured metadata header and embed it at the beginning of the corresponding content fragment to form a content fragment containing the metadata header and integrity field.

[0010] Further, the process of calculating the hash sequence in step 2 includes: retrieving all salted ciphertext fragments of the same patient in ascending order of fragment serial number; loading the salted ciphertext fragments into a restricted memory buffer and establishing a mapping table from fragment serial numbers to memory pointers; starting a thread pool with the same number of threads as the salted ciphertext fragments, and binding each thread to a single salted ciphertext fragment; performing a single-round hash operation on the bound salted ciphertext fragments in the thread pool to output a 512-bit fixed-length digest; writing the fixed-length digest and the corresponding fragment serial number into the specified index position of the hash sequence array to form an ordered hash sequence; when the last thread in the thread pool completes the hash operation, calculate the completion flag of the thread pool operation result, and if any thread returns an error code, terminate immediately.

[0011] Further, the process of generating the Merkle root in step 2 includes: initializing the Merkle layer list according to the length of the hash sequence array, and copying the hash sequence array as the first-layer node list; if the length of the hash sequence array is odd, copy the last hash digest and append it to the end of the Merkle layer list to ensure that the number of nodes is even; record the number of nodes at the current layer and enter an iterative loop with the condition that the number of nodes at the current layer is greater than 1; in each loop, take two adjacent hash digests in order from left to right by node, perform string concatenation to obtain a 1024-bit intermediate string; calculate the hash digest of the new 512-bit parent node for the 1024-bit intermediate string again; write the hash digests of all parent nodes into the next-layer node list in the generation order; if the length of the next-layer node list is odd, copy the hash digest of the last parent node and append it to maintain an even number; update the number of nodes at the current layer to the length of the next-layer node list; repeat the above process until the number of nodes at the current layer is equal to 1, and this unique hash digest is the Merkle root.

[0012] Further, in step 2, within the same thread context, perform binary concatenation on the Merkle root, the current height block header hash value, and the governance layer smart contract address in a fixed order to generate a 1600-bit zero-redundancy data block; perform an anti-hash operation on the zero-redundancy data block to obtain a 512-bit fragment index token body; perform a readable processing on the fragment index token body using Base58Check encoding to generate the final fragment index token string; call the mint interface in the governance layer smart contract on the blockchain to mint the fragment index token string into a non-fungible token and bind it to the patient's unique address; after the governance layer smart contract returns the transaction hash, write the transaction hash, the fragment index token string, the Merkle root, and the current height block header hash value into the on-chain event log together to achieve an immutable cross-institutional index asset registration.

[0013] Further, in step 3, after the on-chain smart contract receives the access application from an external medical institution, it first performs a set intersection operation on the identity codes of all external medical institutions listed in this application and the patient consent whitelist. If the number of intersection elements reaches or exceeds the consent threshold set by the patient, it immediately locks the intersection result, generates a candidate consent set, and marks the threshold satisfaction status in the same transaction. Once in the threshold satisfaction status, the candidate consent set is written into a read-only memory slot and cannot be changed due to subsequent revocation or addition of consents, ensuring that the parties involved in the subsequent signature process remain fixed. A random polling algorithm is executed on the candidate consent set, and the identity codes of external medical institutions are divided into multiple rounds in a pseudo-random order, with each round containing no more than one-third of the identity codes of external medical institutions. At the beginning of each round, the on-chain smart contract sends a signature invitation to the external medical institution node corresponding to the identity codes of this round. The invitation message includes the random polling round number, patient identification code, current height block header hash value, and a temporary challenge random number. After receiving the signature invitation, the external medical institution node completes the signature response within the specified time window; otherwise, the signature for this round fails and triggers the backup node strategy, and the backup node is randomly selected from the remaining unassigned identity codes in the same round. After each round of signature is completed, the signature fragments obtained in each round are written into the signature buffer pool in the order of rounds. In the signature buffer pool, an elliptic curve point addition operation is performed on two consecutive rounds of signature fragments to generate an intermediate aggregated signature. The intermediate aggregated signature is added to the signature fragment of the next round again, and the iteration is carried out step by step until all signature fragments are consumed, and finally a unique aggregated signature is obtained.

[0014] Further, after obtaining the unique aggregated signature, the on-chain smart contract writes the patient identification code, candidate consent set, write chain timestamp, current height block header hash value, and unique aggregated signature into a variable-length byte buffer in the form of key-value pairs in sequence, and then performs a hash operation once to obtain a 512-bit access authorization token fingerprint. The access authorization token fingerprint is made readable by using Base64URL encoding to form an access authorization token, and a unique index key is assigned to this access authorization token in the storage area of the on-chain smart contract.

[0015] The blockchain-based cross-region and cross-institution health care data security sharing method of the present invention has the following beneficial effects: It can effectively solve the key problems such as lack of trust, extensive access control, and difficulty in verifying data integrity in the prior art during the data sharing process. By introducing a content-balanced fragmentation mechanism, the present invention can achieve load balancing and efficient encryption processing while ensuring the semantic integrity of the original electronic health records; combined with the joint encryption strategy of one-time fragment keys and blockchain height hash salt values, it effectively prevents the security risks of replay or reverse deduction of duplicate encrypted content. Through hash sequence generation and Merkle root calculation, the present invention establishes a verifiable data integrity structure, and forms a fragment index token by combining the Merkle root, block header hash value, and governance contract address and casting it into a non-fungible token, making the index information unique, immutable, and cross-institutionally identifiable on the chain. In terms of the authorization mechanism, the present invention introduces technical means such as consent thresholds, candidate consent sets, random polling signatures, multi-round replacement mechanisms, and elliptic curve aggregate signatures to achieve multi-institution collaborative authorization under the leadership of patients, ensuring that the authorization results are both credible and traceable. The finally formed access authorization token undergoes hash compression and readable encoding, which can not only quickly verify authenticity, but also has cross-chain availability and governance auditability. The overall solution forms a full-process closed loop from data fragment generation to on-chain authorization, ensuring that data has high security, high controllability, and high availability sharing capabilities throughout the entire life cycle. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 It is a schematic flowchart of the method for the blockchain-based cross-region and cross-institution health care data security sharing method provided by an embodiment of the present invention; Figure 2 It is a schematic diagram of the content-balanced fragmentation processing effect analysis experiment provided by an embodiment of the present invention; Figure 3 It is a schematic diagram of the Merkle root generation process thread pool performance analysis experiment provided by an embodiment of the present invention; Figure 4 It is a schematic diagram of the access authorization token verification success rate statistics experiment provided by an embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0017] Refer to Figure 1 : The blockchain-based cross-region and cross-institution health care data security sharing method, the method comprising: Step 1: Perform content-balanced fragmentation on the electronic health records to obtain a plurality of content fragments, each content fragment having a fragment serial number; generate a one-time fragment key based on the patient's public key, fragment serial number, and write chain timestamp; encrypt each content fragment using the random salt value generated by the hash value of the previous height block header to obtain a salted ciphertext fragment; Step 2: Calculate the hash sequence for all salted ciphertext fragments of the same patient and generate a Merkle root; concatenate the Merkle root, the hash value of the current height block header, and the governance layer smart contract address to form a fragment index token; mint it according to the non-fungible token standard and write it to the blockchain mainnet, making it an immutable cross-institutional index asset; Step 3: When an external medical institution submits an access application, the on-chain smart contract compares the identity code set of the external medical institution applying with the patient's consent whitelist; when the consent threshold set by the patient is met, a signature mechanism is used to generate and verify the access authorization token, and the authorization result is written into the blockchain audit sidechain.

[0018] In the off-chain processing stage, the same electronic health record is broken down into several content fragments through content balanced fragmentation, and each content fragment is assigned a fragment number. This design is not just for data segmentation. Its essence is to reduce the single-chip sensitive entropy density in the sense of information theory, so that any single content fragment is difficult to restore the full picture of the patient, while maintaining the approximate balance of all content fragments in byte scale and sensitivity label to control the probability of successful reconstruction. Subsequently, the process of synchronously generating a one-time fragment key uses the patient's public key, fragment number, and write chain timestamp to input the key derivation function to ensure that the key cannot be reused horizontally and vertically, and prevents two types of attacks: "same secret cross-slice" and "cross-time replay"; this reflects the forward and backward security principles. The source of the random salt value is the hash value of the previous height block header instead of the local random number, because the blockchain consensus layer has completed the distributed randomness verification of the hash value, and introduced the unpredictability recognized by the entire network from the perspective of the entropy pool. Therefore, the salted ciphertext fragment has the characteristics of anti-rainbow table and anti-dictionary attack, and will not reduce the security strength due to defects in the terminal random number generator.

[0019] The salted ciphertext fragments are written into the decentralized storage network of the InterPlanetary File System (IPFS) class. Only their addressing hashes and minimized metadata are stored on the main chain, achieving hierarchical access of "fat chain indexing and thin chain data" in terms of architecture, avoiding high-throughput medical files from directly squeezing the on-chain capacity, and ensuring immutability at the index level. In the on-chain stage, the one-way hash outputs of all salted ciphertext fragments are linked into a Merkle tree structure with the hash sequence as the bridge. The existence of the Merkle root compresses the overall integrity proof to a single constant size. Any change to the content of a single piece will cause a hash mismatch from the leaf to the root path, enabling the verification of global immutability in a zero-knowledge scenario. The Merkle root is concatenated with the current height block header hash value and the governance layer smart contract address and further encapsulated into a fragment index token, which is then issued through the non-fungible token protocol, making the index itself have trading attributes and uniqueness, and can serve as a traceable query entry in cross-regional and cross-institutional scenarios without leaking the details of the underlying data structure. At the access control level, when an external medical institution submits an application, the on-chain smart contract compares the set of identity codes of the external medical institution with the patient consent whitelist through set operations, and uses the explicit policy threshold of the consent threshold set by the patient to avoid single-point authorization, and triggers the signature mechanism after reaching the threshold.

[0020] This signature mechanism does not rely on a traditional centralized authorization server, but uses a multi-round random polling and segmented aggregation method to generate an aggregated signature, which not only avoids the signature queue blockage that may be caused by a fixed order, but also cryptographically ensures that each signature fragment is included in the final aggregated result, and finally constructs an access authorization token. Only after the access authorization token is successfully verified will the off-chain decryption channel be opened, and any branch with a verification failure is written to the blockchain audit side chain in real time. The blockchain audit side chain records every successful, failed, or abnormally terminated authorization in the form of an immutable event log, and combines the access authorization token fingerprint, the current height block header hash value, and the write chain timestamp to form a three-element time lock. Any subsequent audit entity only needs to replay the event order and hash path to completely reconstruct the decision-making trajectory, thereby meeting the forensic requirements of electronic health records in a multi-jurisdictional compliance environment.

[0021] Furthermore, in step 1, a structured parsing algorithm is called to scan the electronic health record byte by byte, identify and extract medical data elements; attach three types of metadata to each data element: byte length, sensitivity label, and timestamp label; write the data element and its metadata into a temporary element table; in the temporary element table, calculate the content weight for each data element, sum up the content weights of all data elements, divide the sum of the content weights by a preset segmentation coefficient to obtain the target fragment capacity; if the target fragment capacity is less than the minimum I / O threshold, automatically adjust the preset segmentation coefficient to a smaller value until the target fragment capacity meets the minimum I / O threshold requirement.

[0022] This structured parsing algorithm first disassembles heterogeneous fields such as diagnostic conclusions, image binary blocks, test results, and prescription details into independent medical treatment data elements through a character-level state machine combined with a natural language rule library. Subsequently, to maintain data measurability and traceability of sensitivity grading, the system synchronously generates three types of metadata for each data element, namely byte length, sensitivity label, and timestamp label. Among them, the byte length is measured instantaneously by the parsing thread in the memory buffer, the sensitivity label is automatically mapped according to the preset medical information grading standard, and the timestamp label references the high-precision clock value at the moment when parsing starts. Before writing the data element and its metadata into the temporary element table, the parsing thread will first perform a hash check on the original text to ensure that there is no garbled code or encoding drift during the reading process. The temporary element table is essentially an array of compact structures located in restricted memory, which not only maintains the insertion order of elements but also facilitates subsequent traversal.

[0023] Immediately afterwards, the system enters the stage of calculating the content weight based on information theory metrics. The content weight is obtained by multiplying the byte length by the coefficient corresponding to the sensitivity label, so as to reflect the comprehensive importance of a single medical treatment data element in terms of patient privacy leakage risk and data processing cost. After the algorithm completes the calculation of the content weight for all elements, it immediately aggregates to obtain the total content weight, providing a constant reference for subsequent determination of the fragment capacity. To avoid a decrease in off-chain storage efficiency caused by too small fragments, the system divides the total content weight by the preset segmentation coefficient to obtain the target fragment capacity. In the case of high-sensitivity medical records or extremely long images, the target fragment capacity may be lower than the minimum I / O threshold of the storage medium. Therefore, the parsing module will automatically adjust the preset segmentation coefficient to a smaller value, increase the single-piece capacity by reducing the segmentation share, and ensure that the target fragment capacity gradually increases until it meets the minimum I / O threshold requirement. This adaptive parameter adjustment logic is simultaneously updated to the shared configuration area of the parsing thread and broadcast to the parallel encryption threads to ensure that the sequence benchmark does not drift during the key derivation and salt value generation processes.

[0024] Data elements include: diagnostic items, image files, test results, prescription information, nursing notes, and expense lists.

[0025] Further, in step 1, a one-way streaming traversal is performed on the temporary element table according to the original occurrence order in the electronic health record, including: maintaining an accumulative weight register, starting from 0, adding the content weight of the current data element; when the value of the accumulative weight register first reaches or exceeds the target fragment capacity, immediately insert a boundary marker at the tail of this data element, encapsulate all data elements before the boundary into a content fragment; reset the accumulative weight register to 0, and continue to traverse the unprocessed data elements, repeating the above steps until all data elements are divided; if the value of the accumulative weight register of the last remaining data elements is less than 50% of the target fragment capacity, then merge it with the previous content fragment to ensure that the capacity difference between fragments does not exceed ±50%.

[0026] The temporary element table retains the original occurrence order in the electronic health record, which means that any slicing operation that deviates from the order will destroy the position information mapping during subsequent reconstruction, thus introducing an additional indexing burden in a cross-institutional environment. The one-way streaming traversal solidifies the order constraint into a linear scan. Each time it moves forward one step, it only needs to read the content weight of the current data element and add it to the accumulative weight register, strictly controlling the time complexity at the linear level and eliminating the cache jitter caused by random addressing. The accumulative weight register starts from zero, which is equivalent to applying a sliding window to the data stream, and the window threshold is the target fragment capacity. The moment the register value first reaches or exceeds the target fragment capacity, the algorithm determines the predecessor position of the current stream pointer as the slice boundary and writes a boundary marker at the tail of the corresponding data element. The content fragments obtained in this way naturally inherit the property of the continuous subsequence covered by the window, with its capacity having a controllable error from the target fragment capacity, and each boundary marker records the exact time point and order position, providing an undeniable anchor for the subsequent hash sequence generation.

[0027] The core principle of this design is to use the cumulative information volume between consecutive data elements as a metric. Slicing is triggered only when the information volume reaches a specified threshold, thereby ensuring that the distribution of sensitive information in each content fragment is approximately balanced, and reducing the risk of single-piece leakage from the perspective of information theory. At the same time, since the target fragment capacity is dynamically derived by combining the minimum I / O threshold and the total content weight, the register threshold naturally adapts to the block write granularity of the underlying storage medium, avoiding the write amplification problem caused by a large number of sub-block writes. After the streaming traversal ends, if the tail segment capacity is less than half of the target fragment capacity, the system uses the merging strategy to incorporate the tail segment into the previous content fragment, so that the capacity difference between the final fragments is limited within plus or minus 50%. The theoretical basis for this step is the variance constraint in statistics - by restricting the appearance of extremely small fragments, the overall distribution is closer to the mean, which not only ensures that the sizes of data blocks in the same batch are consistent during encrypted batch processing, reducing the performance loss of the encryption algorithm in short block padding, but also ensures that the size of a single record is within a predictable range when writing metadata to the subsequent blockchain, thereby achieving the stability of network bandwidth and on-chain Gas overhead. The insertion and merging operations of boundary markers are all completed in memory, and immutable segment pointers are used to point to the original data buffer, avoiding redundant copies; this not only improves the slicing speed but also ensures that no external process can observe the fragmentation traces of unencrypted data at the disk level, further narrowing the potential attack surface. The updated content fragments after merging maintain the original sequential continuity, so the temporary element table can be directly handed over to the next stage to generate one-time fragment keys without rearrangement.

[0028] Furthermore, in step 1, the target fragment capacities of all content fragments are statistically analyzed to calculate the capacity variance; if the capacity variance is greater than the set smoothing threshold, two-way adjacent merging is performed: first, the adjacent smallest content fragment and the second smallest content fragment are merged preferentially; after each merge, the capacity variance is updated in real time until the capacity variance does not exceed the smoothing threshold; all the finally obtained content fragments are numbered in logical order, starting from 0 and incrementing, and each number is the unique fragment serial number; a separate pre-encryption hash check code is calculated for each content fragment and written into the integrity field at the end of the content fragment; the fragment serial number, hash check code, and sensitivity label are combined into a structured metadata header and embedded at the beginning of the corresponding content fragment to form a content fragment containing the metadata header and integrity field.

[0029] Capacity reorganization adopts a two-way adjacent merging algorithm. Different from the simple "global sorting first and then pairwise merging", the two-way adjacent merging algorithm first locates the current smallest content fragment in the logical order list, and then checks the capacities of its left and right neighbors respectively; if the left neighbor has a smaller capacity, the system selects the smallest content fragment to merge with the left neighbor, otherwise it selects the right neighbor. This strategy can preferentially eliminate capacity troughs without disrupting the original order, thereby narrowing the tail region of the capacity distribution curve. When the smallest content fragment is merged with its preferred neighbor into a new content fragment, the algorithm immediately recalculates the capacity variance and writes the updated capacity into the runtime metric register. If the updated capacity variance is still greater than the smoothing threshold, the algorithm continues to locate the new smallest content fragment and perform the next round of merging. Since each merge reduces the list length by one and simultaneously raises the minimum capacity, the capacity variance will gradually decrease; when the capacity variance does not exceed the smoothing threshold, the algorithm terminates. Through multiple rounds of adaptive merging, the system achieves the best capacity balance with the least amount of boundary adjustment, without introducing any additional padding bytes or redundant data, thus maintaining the off-chain storage efficiency.

[0030] After capacity balancing is completed, the system immediately numbers all the finally obtained content fragments in logical order, starting from 0 and incrementing. Each number is the unique fragment serial number. As the only order identifier for the entire slicing stage, the fragment serial number will be repeatedly referenced during subsequent one-time fragment key derivation, hash sequence splicing, and blockchain metadata writing. Therefore, it must be monotonically increasing and non-repeating. To prevent concurrent threads from generating race conditions in extreme cases, the numbering process is completed in a single-threaded write mode, and an ever-increasing atomic counter is written at runtime to ensure that the maximum fragment serial number read at any time is globally up-to-date.

[0031] In the same batch processing loop after numbering is completed, the system calculates a separate pre-encryption hash checksum for each content fragment and writes the hash checksum into the content fragment tail integrity field. Different from performing hash verification after the salted ciphertext fragment is generated, the pre-encryption hash checksum can directly measure data integrity in the plaintext context, and can detect problems in advance when off-chain storage is damaged or disk degradation occurs in the future, avoiding waste of encryption calculations caused by entering incorrect data into the encryption pipeline. In addition, the pre-encryption hash checksum uses a quantum-resistant hash function consistent with the blockchain side, making the calculation semantics of the front and back chains and off-chain completely aligned, facilitating fine-grained comparison on the audit side chain.

[0032] Subsequently, the system combines the fragment serial number, hash check code, and sensitivity label into a structured metadata header and embeds it at the beginning of the corresponding content fragment. The structured metadata header adopts a TLV (Type-Length-Value) layout: the Type field indicates the tags of the three segments of metadata, the Length field records the byte length of each field, and the Value field writes the fragment serial number, hash check code, and sensitivity label respectively. Since the sensitivity label comes from the previous parsing stage, it can be directly read on the smart contract side of the chain without decrypting the text after embedding, enabling fine-grained pre-filtering of access control. The content fragment maintains an integrity field at the tail, adds a structured metadata header at the head, and still maintains the sequential continuity of the original diagnosis and treatment data in the middle. This "injecting at both ends without modifying the text" wrapping method ensures that the diagnosis and treatment data is not interspersed and segmented by any additional fields, reducing the cache break during data alignment by the encryption algorithm. The five actions of capacity variance smoothing, bidirectional adjacent merging, unique fragment serial number, pre-embedded hash check code before encryption, and structured metadata header jointly complete the seamless connection from the slicing stage to the encryption stage. Capacity smoothing ensures the load balance of subsequent encryption threads, the fragment serial number provides the mapping basis for encryption key derivation and on-chain indexing, the hash check code buries points in advance in the plaintext stage to ensure storage integrity, and the structured metadata header directly binds the key access control metrics to the data itself, providing a plug-and-play field for authorization judgment on the blockchain side.

[0033] The salted ciphertext sharding is as follows: ; Among them, is the th salted ciphertext shard generated for the patient , which is written to the IPFS + metadata on the chain; is the electronic health record (HL7 FHIR format) of the patient ; is the th content fragment with balanced content (≤10MB); is the one-time fragment key; derived from , is the patient's public key; is the write chain timestamp; is the patient identification code; is the medical institution license number; is the random salt value generated from the hash value of the previous height block header; is the bitwise exclusive OR operation; is the hash operation.

[0034] Further, the process of calculating the hash sequence in step 2 includes: retrieving all salted ciphertext fragments of the same patient in ascending order of fragment numbers; loading the salted ciphertext fragments into a restricted memory buffer and establishing a mapping table from fragment numbers to memory pointers; starting a thread pool with the same number of threads as the number of salted ciphertext fragments, and binding each thread to a single salted ciphertext fragment; performing a single-round hash operation on the bound salted ciphertext fragments within the thread pool to output a fixed-length digest of 512 bits; writing the fixed-length digest and the corresponding fragment number together to the specified index position of the hash sequence array to form an ordered hash sequence; when the last thread in the thread pool completes the hash operation, calculating the completion flag of the thread pool operation result, and if any thread returns an error code, terminating immediately.

[0035] First, retrieve all salted ciphertext fragments of the same patient in ascending order of fragment numbers. This step ensures that the path index in the subsequent Merkle tree construction corresponds one-to-one with the fragment numbers, avoiding the risk of mismatch between on-chain indexes and off-chain data in a cross-institutional scenario. After retrieval, all salted ciphertext fragments are loaded into a restricted memory buffer, which runs within a hardware-isolated trusted execution environment and can block side-channel detection at the operating system level. To eliminate the performance bottleneck caused by traversing pointers, the system simultaneously establishes a mapping table from fragment numbers to memory pointers, enabling any subsequent algorithm to access a specified salted ciphertext fragment in constant time. Subsequently, the system dynamically configures the size of the thread pool according to the number of salted ciphertext fragments. Each thread in the thread pool is fixedly bound to a physical core and its cache affinity is locked to reduce context switching and cross-core cache coherence overhead.

[0036] Each thread reads the bound salted ciphertext fragment in its own private register, calls a cryptographic hash function to complete a single-round hash operation, and outputs a fixed-length digest with a constant length of 512 bits. The reason for choosing this digest length is that it can provide sufficient second-preimage resistance security margin in the face of quantum attack models, and at the same time maintain a unified field width at the blockchain index level to facilitate subsequent serialization. When the fixed-length digest is generated, the thread holds a local copy of the fragment number and writes the digest and the fragment number together to the specified index position of the hash sequence array through an atomic write instruction to ensure lock-free competition during the multi-threaded writing process. The hash sequence array itself has been pre-allocated with an offset according to the size of the fragment numbers during initialization, so any thread only needs one write to complete the mapping without triggering expansion or fragmentation movement.

[0037] After the thread finishes writing, it returns a completion signal to the thread pool scheduler. The scheduler uses a bitmap to record the thread completion status, avoiding a giant lock. Only when all the flag bits in the bitmap are set to completed will the system update the completion flag of the computing thread pool operation result to successful and trigger the downstream Merkle tree construction process. If any thread encounters a memory read exception, hash function failure, or output length mismatch during the hash operation, it will immediately return an error code. After detecting the exception, the thread pool scheduler will atomically mark the failure status and terminate all threads, then release the restricted memory buffer, write the off-chain failure audit log, and block further execution to prevent pushing the corrupted hash sequence onto the chain.

[0038] Further, the process of generating the Merkle root in step 2 includes: initializing the Merkle level list according to the length of the hash sequence array, and copying the hash sequence array as the first-level node list; if the length of the hash sequence array is odd, copy the last hash digest and append it to the end of the Merkle level list to ensure that the number of nodes is even; record the number of nodes at the current level and enter an iterative loop with the condition that the number of nodes at the current level is greater than 1; in each loop, take two adjacent hash digests in order from left to right by node, perform string concatenation to get a 1024-bit intermediate string; calculate the hash digest of the new 512-bit parent node for the 1024-bit intermediate string again; write the hash digests of all parent nodes into the next-level node list in the order of generation; if the length of the next-level node list is odd, copy the hash digest of the last parent node and append it to maintain evenness; update the number of nodes at the current level to the length of the next-level node list; repeat the above process until the number of nodes at the current level is equal to 1, and this unique hash digest is the Merkle root.

[0039] The essence of generating the Merkle root is a cryptographic compression process of "mapping a large amount of local integrity into a constant-level global credential". To explain this core principle, it is necessary to first understand the three properties of the hash function: one-wayness, collision resistance, and avalanche effect. One-wayness ensures that anyone can only calculate the hash digest from the salted ciphertext fragments, but cannot reverse the original text from the hash digest; collision resistance ensures that it is extremely difficult for two different inputs to produce the same 512-bit fixed-length digest; the avalanche effect means that any change in any bit of the input will cause the output binary string to flip exponentially. These properties together determine that the hash digest can be used as an "untampered fingerprint", but a single fingerprint is not sufficient to cover the entire set of salted ciphertext fragments, because changing any one of them will only change the digest corresponding to that one piece, and if the blockchain side only stores a single piece of fingerprint, it cannot prove the status of all the other fragments. The Merkle tree elevates the locally untampered fingerprints to globally untampered fingerprints, that is, the Merkle root, by recursively operating on "hashing two adjacent fingerprints again". Once the Merkle root is embedded in the blockchain block header, the integrity of all the fragments below it is bound together with the immutable property of the blockchain itself.

[0040] When initializing the Merkle hierarchy list, the system copies each 512-bit hash digest in the hash sequence array losslessly to the leaf layer. To ensure the perfect closure of the binary pairing structure, the number of leaf nodes needs to be even. This is why the last hash digest is copied and appended when the sequence length is odd. This action does not reduce security because the copied node shares the same hash value as the original node, but still participates independently in the calculation of the parent node in the left-right order in the tree combination. Therefore, any attempt to delete the tail fragment will destroy the pairing structure and be immediately exposed when recalculating the Merkle root.

[0041] After entering the iterative loop, the operation of "successively taking adjacent two hash digests from left to right, concatenating them into a 1024-bit intermediate string, and then hashing them into a 512-bit parent node hash digest" essentially uses the confusion property of the hash function to entropy-merge the information of two child nodes. If an attacker only tampers with one of the child nodes, even if the hash length can still be kept unchanged, it is impossible to create a new parent node digest that matches the old value because the value of the other child node must be inversely deduced at the same time, which is almost impossible to complete under the anti-collision assumption. Using 1024-bit concatenation instead of byte-by-byte interleaving or other serialization methods is to simplify the implementation: concatenation ensures a definite input arrangement rule, and any node can reconstruct the input in O(1) time without causing inconsistent verification between the two parties due to differences in optional serialization schemes. In addition, the output of each layer is uniformly a 512-bit fixed-length digest, keeping the width of the nodes at all levels of the tree consistent, which is convenient for storage alignment and also ensures a constant log space budget.

[0042] After the parent nodes are generated, they are written into the next layer node list in order. Emphasizing the order invariance here is because the fragment serial numbers originally correspond to the logical positions of the real medical information in the medical record. If the node order is disrupted at a certain layer, even if the Merkle root can still be calculated correctly, the future retrieval path on the chain will shift, resulting in the inability to search for leaves according to the root during cross-institutional verification. At the end of each layer, it is necessary to check again whether the number of nodes is odd and fill it up. The purpose is to keep the shape of the tree balanced at all levels. The balanced tree brings two important results: First, the verification path length from any leaf node to the Merkle root is the same, and the network transmission overhead is predictable; Second, when the blockchain side makes a static estimate of the verification proof size, it does not need to pay attention to the node distribution, and the "worst case" is the same as the "average case", which is convenient for the consensus protocol to package and price at one time in terms of Gas charging or transaction size limit.

[0043] When the iterative loop stops when only one node remains, this unique hash digest is the Merkle root. The length of the Merkle root is still 512 bits, but it already contains the integrity information of all the fragments. The blockchain only needs to store this constant-level value to achieve the proof of immutability of massive data. When any medical institution wants to verify individual salted ciphertext fragments, it only needs to request the sibling hash values on the path from the corresponding fragment to the root node. The length of such a path is logarithmic, and the verification complexity is much less than recalculating the entire tree. A deeper principle lies in "separability": in the Merkle tree structure, deleting or adding any piece will change a series of hash outputs from its parent node, grandparent node to the root node. Therefore, the Merkle root can be regarded as a commitment to the set of fragments, and the path proof is the disclosure between the commitment and a specific fragment. This commitment-disclosure model allows the blockchain to maintain a small fingerprint to support the integrity verification of infinitely sharded external data, which is very suitable for the bandwidth and storage constraints in cross-regional and cross-institutional scenarios.

[0044] In addition, the Merkle root also bears sequential integrity. Since the leaf layer arrangement is directly in ascending order of fragment numbers, any attempt to swap the positions of two fragments will simultaneously change the parent node generation sequence of both, resulting in the misalignment of the entire path to the root node and ultimately causing the Merkle root verification to fail. Therefore, the Merkle tree not only detects content tampering but also prevents sequential tampering, which is crucial for the chronological credibility of medical records. After binding the Merkle root to the block header hash and supplementing it with a timestamp on the chain, a dual time attribution is formed: on the one hand, the generation time of the block cannot be changed retroactively, and on the other hand, the root value and time together depict the fact that "the system did hold these fragments and in this order at a certain moment", providing strong technical support for subsequent medical dispute evidence.

[0045] Finally, the reason why the Merkle root can be further encapsulated into the fragment index token by the governance layer smart contract address is that the index token not only needs to express integrity but also the semantics of "belonging to a certain patient and being subject to a certain governance strategy". The Merkle root provides the integrity coordinate, the current height block header hash value provides the full-chain synchronization coordinate, and the governance layer smart contract address provides the governance and access control coordinate. The index token formed by combining the three can be retrieved across institutions and simultaneously forms a triple lock on any attempt to tamper with the fragments or misappropriate the token afterwards. In other words, the Merkle root is not an isolated tree root in this method but the cryptographic center of the entire cross-regional and cross-institutional shared link, assuming the role of a one-stop proof from data security, sequential consistency to audit and accountability.

[0046] Further, in step 2, within the same thread context, the Merkle root, the hash value of the current height block header, and the governance layer smart contract address are concatenated in binary in a fixed order to generate a 1600-bit zero-redundancy data block; perform an anti-hash operation on the zero-redundancy data block to obtain a 512-bit fragment index token body; use Base58Check encoding to make the fragment index token body readable, generating the final fragment index token string; call the mint interface in the governance layer smart contract on the blockchain to mint the fragment index token string into a non-fungible token and bind it to the patient's unique address; after the governance layer smart contract returns the transaction hash, write the transaction hash, the fragment index token string, the Merkle root, and the hash value of the current height block header into the on-chain event log together to achieve tamper-proof cross-institutional index asset registration.

[0047] In the index construction stage of the cross-regional and cross-institutional healthcare data security sharing method based on blockchain, the system must implement the previously obtained Merkle root as a unique symbol that can be quickly retrieved between different chain nodes and has asset attributes at the same time. To achieve this goal, first, within the same thread context, the Merkle root, the hash value of the current height block header, and the governance layer smart contract address are concatenated in binary in a strict fixed order to obtain a zero-redundancy data block with a length of 1600 bits. The main motivation for using "binary hard concatenation" instead of tag-value sequences or variable-length fields is to remove the encoding ambiguity caused by redundant delimiters: as long as the concatenation order is fixed, any node can use the same algorithm to restore the same set of inputs to exactly the same zero-redundancy data block, thus eliminating the hash bias that may be introduced by cross-implementation differences. The second meaning of zero redundancy is to "entropy merge" three pieces of information that already have independent tamper-proof attributes into a carrier with a higher information density, so that the subsequent hash function does not waste calculations on blank bits or delimiters, but acts 100% on the business-critical information.

[0048] Perform an anti-hash operation on the zero-redundancy data block to output a fragment index token body with a constant length of 512 bits. Here, an anti-hash algorithm is selected instead of a traditional hash function to maintain the second collision complexity still higher than 2^256 under the quantum threat model, which is particularly crucial for medical data spanning multiple years of storage cycles. The 512-bit output not only ensures the safety margin but also keeps the same hash bit width as the previous leaf layer and parent layer, avoiding parsing branches caused by multiple lengths of on-chain evidence fields.

[0049] After the fragment index token body is completed, it needs to be converted into a representation form that can be read and written unambiguously by both humans and systems. Therefore, the Base58Check encoding is used to generate the fragment index token string. Compared with the more common Base64, Base32, or hexadecimal representations, on the one hand, the Base58Check encoding eliminates confusing characters such as zero, uppercase and lowercase O, and uppercase and lowercase I, reducing the misidentification rate during manual entry or visual verification; on the other hand, it has a built-in checksum bit, which can automatically detect single-character errors when copying between nodes or spreading through QR codes, meeting the low error tolerance characteristics of the medical scenario. The generated fragment index token string thus has the double robustness of "machine-parsable and human-eye-verifiable".

[0050] After the index is generated and locally verified without error, the system calls the mint interface in the governance layer smart contract on the blockchain to mint the fragment index token string into a non-fungible token, and directly binds the non-fungible token to the patient's unique address through the contract parameters. The reasons for using non-fungible tokens instead of ordinary key-value pairs are as follows: First, non-fungible tokens naturally guarantee uniqueness and transferability at the protocol layer, avoiding duplicate minting or malicious tampering; Second, the ownership and transfer history of non-fungible tokens are all written into the immutable ledger on the chain, facilitating subsequent regulatory agencies or data subjects to track in real time; Third, the existing decentralized custody wallets and multi-signature libraries already have a perfect permission model support for non-fungible tokens, saving the additional governance layer code maintenance cost.

[0051] Once the governance layer smart contract returns the transaction hash, the system immediately writes the transaction hash, the fragment index token string, the Merkle root, and the current height block header hash value into the chain event log together to achieve immutable cross-institutional index asset registration. The chain event log, as an "append-only and non-deletable" data structure, naturally meets the requirements of audit traceability; at the same time, the event log broadcasts to all blockchain nodes at the subscription layer, ensuring that the newly minted non-fungible tokens are synchronized to the cross-regional query gateway with the minimum delay. In this way, any external medical institution holding the patient's authorization only needs to grab the fragment index token string, and can reverse-resolve the corresponding Merkle root and the block height when writing to the chain through the contract query interface, so as to verify the integrity of the salted ciphertext fragment set without touching the plaintext; if there is a chain fork or cross-chain verification is required in the future, the current height block header hash value recorded in the event log will provide the only anchor point for consensus backtracking.

[0052] The Merkle root is:[[]] ; Among them, is the Merkle root of the patient ; is the number of content fragments of the patient ; is the data element to which the content fragment belongs; is the random salt value generated for the hash value of the current height block header; is the address of the governance layer smart contract.

[0053] Furthermore, in step 3, after the on-chain smart contract receives an access request from an external medical institution, it first performs a set intersection operation on the identity codes of all external medical institutions listed in this application and the patient consent whitelist; if the number of intersection elements reaches or exceeds the consent threshold set by the patient, it immediately locks the intersection result, generates a candidate consent set, and marks the threshold satisfaction status in the same transaction; once in the threshold satisfaction status, the candidate consent set is written into a read-only memory slot and cannot be changed due to subsequent revocation or addition of consents, ensuring that the parties involved in the subsequent signature process remain fixed; a random polling algorithm is executed on the candidate consent set, and the identity codes of external medical institutions are divided into multiple rounds in a pseudo-random order, with each round containing no more than one-third of the identity codes of external medical institutions; at the beginning of each round, the on-chain smart contract sends a signature invitation to the external medical institution nodes corresponding to the identity codes of this round, and the invitation message includes the random polling round number, patient identification code, hash value of the current height block header, and a temporary challenge random number; after receiving the signature invitation, the external medical institution nodes complete the signature response within the specified time window, otherwise the signature of this round fails and triggers the backup node strategy, and the backup node is randomly selected from the remaining unassigned identity codes in the same round; after each round of signature is completed, the signature fragments obtained in each round are written into the signature buffer pool in the order of rounds; in the signature buffer pool, an elliptic curve point addition operation is performed on the signature fragments of two consecutive rounds to generate an intermediate aggregated signature; the intermediate aggregated signature is added to the signature fragment of the next round again, and the iteration is performed step by step until all signature fragments are consumed, and finally a unique aggregated signature is obtained.

[0054] In the cross - regional and cross - institutional health care data security sharing method based on blockchain, the core idea of the above - mentioned access authorization process is to transform the consent threshold set by the patient into a mechanically verifiable decentralized vote, using the elliptic curve point addition aggregate signature as the consensus hammer. This not only avoids centralized trust but also ensures that each participating external medical institution leaves an undeniable trace cryptographically. The on - chain smart contract first performs a set intersection operation on the identity codes of external medical institutions and the patient consent whitelist. This step is not just simple screening but a deterministic mapping in the blockchain global state tree, precisely mapping the vague concept of "who is allowed" at the business layer to the count of elements in the identity code set. Only when the number of intersection elements reaches or exceeds the consent threshold set by the patient, the threshold - satisfied state will be marked. Once marked, this state along with the candidate consent set is written into a read - only memory slot, converting it from a mutable state to an immutable state and blocking any subsequent attempt to revoke or append consent. This is equivalent to generating a "snapshot" on the chain to ensure that the subsequent signature process will not be disrupted by dynamic member changes. The random polling algorithm further introduces unpredictability and fairness, dividing the candidate consent set into multiple rounds, with the size of each round not exceeding one - third of the total. This ensures that any single - round failure will not bring the system to a complete halt. At the same time, the random polling sequence is derived jointly from a temporary challenge random number generated within the contract and the hash value of the current block header, making it difficult for external observers to predict in advance which nodes will be invited in the next round, thus weakening the effect of premeditated refusal to sign or Sybil attacks.

[0055] The on - chain smart contract broadcasts signature invitations to nodes round by round. If a node does not respond within the given time window, the backup node strategy is triggered. This timeout expulsion mechanism encapsulates the uncertainty of the off - chain network with an on - chain state machine, maintaining the real - time nature and eventual certainty of the authorization process. All successfully returned signature fragments are written into the signature buffer pool in round - by - round order, and then the elliptic curve point addition operation is performed in the same trusted execution environment. The mathematical essence of point addition is to regard each signature fragment as a vector in the same elliptic curve group and sum them up. The resulting aggregate signature contains the information of all fragments and has a fixed - length output. After each point addition, it immediately continues to aggregate with the signature fragments of the next round until all signature fragments are consumed, generating a unique aggregate signature. The advantage of this is to prove with a constant - level value that several independent medical institutions make authorization decisions for the same patient identification code at the same block height. Any subsequent tampering of a single - piece signature will destroy the aggregate result, causing the on - chain verification to fail immediately.

[0056] Furthermore, after obtaining the unique aggregated signature, the on-chain smart contract writes the patient identification code, candidate consent set, chain-writing timestamp, current height block header hash value, and unique aggregated signature into a variable-length byte buffer in the form of key-value pairs in sequence, and then performs a hash operation once to obtain a 512-bit access authorization token fingerprint; the access authorization token fingerprint is made readable by using Base64URL encoding to form an access authorization token, and a unique index key is assigned to the access authorization token in the storage area of the on-chain smart contract.

[0057] In the authorization generation stage of the cross-regional and cross-institutional healthcare data security sharing method based on blockchain, the unique aggregated signature only completes the cryptographic proof of the fact that "enough subjects have consented". To transform this fact into an access credential that can be directly referenced for on-chain access, is easy to carry in off-chain systems, and can be uniformly recognized by cross-institutional nodes, it must go through a serialization-hashing-encoding-indexing pipeline process again. The smart contract first fills the patient identification code, candidate consent set, chain-writing timestamp, current height block header hash value, and unique aggregated signature into a variable-length byte buffer item by item according to the predefined key names. The reason for using the key-value pair form instead of simple concatenation is to prevent old nodes from being difficult to correctly parse due to field insertion or order adjustment during the evolution of future protocol versions; the key names themselves become field delimiters, loading an independent meaning space for each segment, and no attacker can deceive the hash verification by deleting or repeatedly inserting a certain segment of content while keeping the overall binary length consistent. After the five key pieces of information are filled, the buffer already contains the complete authorization context, and each field itself is locked by the previous process and there is no possibility of being changed again. The smart contract then performs a single-round hash operation on this buffer to compress the variable-length business context into a fixed-length 512-bit access authorization token fingerprint; the one-step hash operation avoids the combined attack surface brought by segment-by-segment hashing of fields, and also ensures that completely uncorrelated output values will be obtained for different patients, different rounds, or different block heights, thus achieving strong entropy separation.

[0058] After obtaining the fingerprint, the system converts it into a readable string using Base64URL encoding. The reason for choosing this encoding instead of Base58Check is that the authorization token is usually passed through HTTP headers or JSON fields at the business layer, and Base64URL is designed for URL-safe character sets, which can reduce the probability of cross-platform transcoding errors while still retaining the detectability of single-character mistypes. The access authorization token finally generated is not only short and unambiguous, but can also be directly embedded in existing WebAPIs. In order to ensure fast on-chain retrieval, the smart contract assigns a unique index key to the access authorization token in its own key-value mapping storage. The index key is still calculated by a collision-resistant hash function and merged with the block number, so that any node only needs to query the mapping once to obtain the full context of the authorization token and the real-time status of whether it has been revoked. Since writing the key-value mapping occurs in the same transaction, once the access authorization token is generated, it is immediately within the complete governance track of "verifiable-freezable-traceable". Subsequently, external medical institutions only need to submit the token with the transaction, and the on-chain logic can complete the authenticity verification in a constant time and decide whether the data channel is open, realizing seamless connection between authorization generation and authorization use, no central intermediary, and immediate effectiveness under the consensus of the entire network.

[0059] The access authorization token is: ; in, For the The identification code of the external medical institution; The number of external medical institutions applied for; For patients Patient consent whitelisting; is the consent threshold; For the collection The generated BLS threshold signature; The expiration time of the access authorization token; , 1 means authorization is successful; otherwise it is rejected.

[0060] The following is an electronic health record of size The system sets the minimum I / O threshold to , the preset division coefficient is . 6 diagnosis and treatment data elements are parsed, and their byte length sequence is . Sensitivity label sequence Mapping coefficients in sequence . Content weight ; Total weight . Initial target fragment capacity .

[0061] because ,Keep Unidirectional streaming traversal, cumulative weight register Gradually accumulate: ; Thus, the first content fragment is generated (including elements ), capacity Reset , continue ; The remaining two elements ; The situation of insufficient tail section does not occur, so no merging is done. Three fragments are obtained: The capacity variance ; No further merging is required. Derive a one-time fragment key for each fragment. Take

[0062] as an example ; ; The hash of the previous height block header .

[0063] Salted ciphertext ; Similarly generate .

[0064] For Parallel computing ; Since the number of nodes is odd, copy the end: Leaf layer Parent layer ; Merkle root ; Generate the fragment index token body ; The final fragment index token .

[0065] Call .

[0066] Set the patient consent threshold . The external medical institution submits the set of identity codes ; Intersection .

[0067] Candidate consent set . Randomly divide into two rounds.

[0068] Round 1: , Round 2: . Aggregate .

[0069] Access authorization token fingerprint .

[0070] Access authorization token 。

[0071] Contract storage mapping 。

[0072] Set the number of valid blocks in the blockchain for this cycle ; Number of patient consent events ; Weight update 。

[0073] Audit window Event: ; Violation indication 。

[0074] 。

[0075] If the fuse threshold is , immediately trigger the freezing of the access authorization token 。

[0076] Figure 2 Fully demonstrates the result analysis of the fragmentation of electronic health records based on the content-balanced fragmentation processing algorithm. The abscissa represents 8 content fragments sorted by content fragment numbers, with the numbers increasing from 1, and each number is the unique fragment serial number. The ordinate represents the numerical value of the target fragment capacity, in bytes, with a value range from 500 bytes to 2500 bytes.

[0077] The bar chart clearly shows the serious imbalance of the capacity of each content fragment before processing. The capacity of the first content fragment reaches 2630 bytes, far exceeding the target fragment capacity baseline of 2000 bytes, reflecting the uneven distribution of diagnosis and treatment data elements in the original electronic health record. The capacity of the second content fragment is only 980 bytes, far below the target benchmark, while the third content fragment surges to 2150 bytes. The fourth content fragment drops to 650 bytes, the fifth content fragment rebounds to 2380 bytes, the sixth content fragment drops sharply to 480 bytes, the seventh content fragment is 1720 bytes, and the eighth content fragment is 750 bytes. This drastic capacity fluctuation reflects the technical defect that the traditional sequential segmentation method cannot guarantee the control of capacity differences between fragments. It can be seen from the calculation that the capacity variance before processing is as high as 845236, which seriously exceeds the set smoothing threshold, indicating that the capacity distribution between fragments is extremely uneven. In this case, the present invention starts the bidirectional neighbor merging algorithm to preferentially merge the adjacent smallest content fragments and the second smallest content fragments. The algorithm first identifies the sixth content fragment (480 bytes) as the smallest fragment and the second content fragment (980 bytes) as the second smallest fragment. Since the two are not adjacent, the system further analyzes the adjacent fragment pairs and finally determines the merging strategy.

[0078] After the two-way adjacent merging process, the target fragment capacity distribution of all content fragments showed a significant balanced feature, as shown by the thick solid line. The capacities of the eight content fragments after processing were stabilized at around 1980 bytes, 1950 bytes, 2020 bytes, 1890 bytes, 1950 bytes, 2020 bytes, 1980 bytes and 1950 bytes, respectively, and fluctuated slightly around the target fragment capacity baseline of 2000 bytes. The capacity variance was significantly reduced from 845236 before processing to 152, a decrease of 99.98%, which fully verified the excellent effect of the two-way adjacent merging algorithm in achieving balanced content fragmentation.

[0079] The difference in the capacity of the processed fragments is controlled within the range of ±50 bytes, which is much smaller than the design requirement of ±50%, ensuring that each content fragment has similar data processing complexity and storage overhead. This balanced processing lays a stable technical foundation for the subsequent one-time fragment key generation, salted ciphertext fragment encryption, and Merkle root calculation, effectively avoiding system performance bottlenecks and security risks caused by excessive differences in fragment capacity.

[0080] Figure 3The performance optimization effect of using thread pool parallel processing technology during Merkle root generation compared to traditional single-threaded serial processing is analyzed in detail. The abscissa represents the number of salted ciphertext fragments participating in the hash operation, marked on a logarithmic scale, covering the complete test range from 10 fragments to 2000 fragments. The ordinate represents the time required to complete all hash operations, in milliseconds, with a value range from 50 milliseconds to 250 milliseconds.

[0081] The dashed line represents the performance of the traditional single-threaded serial processing method. When processing 10 salted ciphertext fragments, the single-threaded method takes 45 milliseconds to complete all hash operations. As the number of fragments increases to 50, the processing time rises to 115 milliseconds. When the number of fragments reaches 100, the single-threaded processing time further extends to 165 milliseconds. In the test scenario with 200 fragments, the single-threaded method requires 205 milliseconds. When processing 500 fragments, the time consumption surges to 238 milliseconds. Facing 1000 fragments, the single-threaded processing time reaches 248 milliseconds. In the large-scale scenario of processing 2000 fragments, the processing time of the single-threaded method reaches a peak of 252 milliseconds, showing obvious performance bottleneck characteristics. The thick solid line demonstrates the performance advantage of the thread pool parallel processing technology adopted in the present invention. The thread pool configuration follows the design principle of binding a single salted ciphertext fragment to each thread, ensuring load balancing and resource isolation among threads. When processing 10 salted ciphertext fragments, the thread pool method only needs 38 milliseconds, which is 18.4% faster than the single-threaded method. When processing 50 fragments, the thread pool time consumption drops to 32 milliseconds, and the performance improvement rate reaches 72.2%. Facing 100 fragments, the thread pool processing time is only 39 milliseconds, achieving a 4.2-fold performance improvement compared to 165 milliseconds of the single-threaded method.

[0082] In larger-scale test scenarios, the performance advantages of the thread pool become even more evident. When processing 200 fragments, the thread pool takes 42 milliseconds, with a 4.9-fold performance improvement. When processing 500 fragments, the thread pool takes 48 milliseconds, with a 5.0-fold performance improvement. When processing 1000 fragments, the thread pool only takes 52 milliseconds, achieving a significant 8.7-fold improvement compared to the 248 milliseconds of a single thread. In the largest-scale test of 2000 fragments, the processing time of the thread pool is controlled within 58 milliseconds, achieving a 12.3-fold performance improvement compared to the 252 milliseconds of a single thread, fully verifying the technical superiority of the parallel processing architecture in large-scale data scenarios. The thread pool adopts a restricted memory buffer management mechanism. By establishing a mapping table from fragment sequence numbers to memory pointers, it realizes efficient access to salted ciphertext fragments and precise control of memory resources. Each thread outputs a fixed-length 512-bit digest during a single round of hash operation, ensuring the consistency and integrity of the hash sequence. When the last thread in the thread pool completes the hash operation, the system calculates the completion flag of the thread pool's operation result. If any thread returns an error code, the entire processing flow is immediately terminated, ensuring the robustness and reliability of the system.

[0083] Figure 4 The statistical characteristics of the verification success rate of access authorization tokens generated using the elliptic curve point addition aggregation signature technique under different consent threshold settings are analyzed in depth. The abscissa represents the consent threshold configuration set by the patient, covering various authorization scenarios that may occur in practical applications, from the loosest one-third threshold to the strictest unanimous threshold. The ordinate represents the success rate of access authorization token verification, with a value range from 0.5 to 1.0, reflecting the impact degree of different threshold settings on the system's reliability.

[0084] The thick solid line shows the verification success rate performance of the present invention using the elliptic curve point addition aggregation signature technology. When the consent threshold is set to one-third, the system exhibits the optimal verification success rate, reaching a high level of 0.98. At this time, the smart contract on the chain only needs one-third of the external medical institution identification codes to meet the patient consent whitelist requirements. The size of the candidate consent set is relatively small, the number of identification codes included in each round of the random polling algorithm is moderate, and the complexity of the elliptic curve point addition operation is in the optimal state. The gradual iterative process of the intermediate aggregation signature is stable and controllable, and the final unique aggregation signature has extremely high verification reliability. When the consent threshold is increased to one-half, the verification success rate slightly drops to 0.96, but still remains in the high level range. At this time, the size of the candidate consent set increases, the random polling algorithm needs to process more external medical institution nodes, and the signature fragment generation and aggregation process faces greater network latency and node response uncertainty challenges. Nevertheless, the mathematical stability of the elliptic curve point addition ensures the overall reliability of the aggregation signature. Under the two-thirds threshold configuration, the verification success rate drops to 0.93. At this time, the candidate consent set covers most of the external medical institution identification codes, the number of rounds of the random polling algorithm increases, and the number of signature fragments after each round of signature completion increases significantly. The elliptic curve point addition operation needs to process more intermediate aggregation signature iteration steps, and the accumulated calculation errors and network transmission delays have an observable impact on the final verification result.

[0085] When the consent threshold reaches three-fourths, the verification success rate further drops to 0.89. The high threshold setting requires almost all external medical institutions to participate in the signature process, and the system faces greater coordination complexity. The triggering frequency of the substitute node strategy increases, and some external medical institution nodes cannot complete the signature response within the specified time window, resulting in the failure of this round of signature and the need to start the substitute mechanism. Under the strict threshold settings of four-fifths and nine-tenths, the verification success rates drop to 0.82 and 0.71 respectively. At this time, the system is close to the state of full participation, and the response delay or signature failure of any single external medical institution node may affect the overall verification result. When the consent threshold reaches the strictest requirement of unanimity, the verification success rate drops to 0.58, reflecting the technical challenges faced by the system under extreme consent requirements. The dotted line represents the performance benchmark of the traditional signature verification method. The verification success rate of the traditional method is significantly lower than that of the elliptic curve point addition aggregation signature technology of the present invention under various threshold settings, verifying the technical superiority and practical value of the new technical solution.

[0086] The present invention has been described in detail above. Specific examples are used herein to illustrate the principles and implementation manners of the present invention. The description of the above embodiments is only for helping to understand the method and its core idea of the present invention. It should be noted that for those of ordinary skill in the art in this technical field, without departing from the principle of the present invention, several improvements and modifications can be made to the present invention, and these improvements and modifications also fall within the protection scope of the claims of the present invention.

Claims

1. A method for secure sharing of cross - regional and cross - institutional health care data based on blockchain, characterized in that, The method includes: Step 1: Perform content balanced fragmentation on the electronic health record to obtain multiple content fragments, each content fragment having a fragment serial number; generate a one-time fragment key based on the patient's public key, fragment serial number, and write chain timestamp; encrypt each content fragment using the random salt value generated by the previous height block header hash value to obtain a salted ciphertext fragment; Step 2: Calculate the hash sequence for all salted ciphertext fragments of the same patient and generate a Merkle root; concatenate the Merkle root, the current height block header hash value, and the governance layer smart contract address to form a fragment index token; mint and write it to the main blockchain network according to the non-fungible token standard, making it an immutable cross-institutional index asset; Step 3: When an external medical institution submits an access application, the on-chain smart contract compares the set of identity codes of the applying external medical institution with the patient's consent whitelist; when the consent threshold set by the patient is met, use the signature mechanism to generate and verify the access authorization token, and write the authorization result to the blockchain audit side chain.

2. The cross-regional and cross-institutional health care data security sharing method based on blockchain according to claim 1, wherein In Step 1, call the structured parsing algorithm to scan the electronic health record byte by byte, identify and extract medical data elements; attach three types of metadata to each data element: byte length, sensitivity label, and timestamp label; write the data element and its metadata to the temporary element table; In the temporary element table, calculate the content weight for each data element, sum up the content weights of all data elements, divide the total content weight by the preset segmentation coefficient to obtain the target fragment capacity; If the target fragment capacity is less than the minimum I / O threshold, automatically adjust the preset segmentation coefficient to a smaller value until the target fragment capacity meets the minimum I / O threshold requirement.

3. The method for secure sharing of cross-regional and cross-institutional health care data based on blockchain according to claim 2, wherein In Step 1, perform a one-way streaming traversal on the temporary element table in the original occurrence order in the electronic health record, including: maintaining an accumulative weight register, starting from 0 and accumulating the content weight of the current data element; when the value of the accumulative weight register first reaches or exceeds the target fragment capacity, immediately insert a boundary mark at the end of this data element, encapsulate all data elements before the boundary into a content fragment; reset the accumulative weight register to 0 and continue to traverse the unprocessed data elements, repeating the above steps until all data elements are divided; if the value of the accumulative weight register of the last remaining data element is less than 50% of the target fragment capacity, merge it with the previous content fragment to ensure that the capacity difference between fragments does not exceed ±50%.

4. The method for secure sharing of cross-regional and cross-institutional health care data based on blockchain according to claim 3, wherein, In Step 1, count the target fragment capacities of all content fragments and calculate the capacity variance; if the capacity variance is greater than the set smoothing threshold, perform two-way adjacent merging: preferentially merge the adjacent smallest content fragment and the second smallest content fragment; Update the capacity variance in real time after each merge until the capacity variance does not exceed the smoothing threshold; Number all the finally obtained content fragments in logical order, starting from 0 and incrementing, and each number is the unique fragment serial number; calculate a separate pre-encryption hash check code for each content fragment and write it to the integrity field at the end of the content fragment; Combine the fragment serial number, hash verification code, and sensitivity label into a structured metadata header, and embed it at the beginning of the corresponding content fragment to form a content fragment containing the metadata header and integrity field.

5. The method for secure sharing of cross-regional and cross-institutional health care data based on blockchain according to claim 4, characterized in that, The process of calculating the hash sequence in Step 2 includes: retrieving all salted ciphertext fragments of the same patient in ascending order of fragment serial numbers; loading the salted ciphertext fragments into a restricted memory buffer and establishing a mapping table from fragment serial numbers to memory pointers; starting a thread pool with the same number of threads as the number of salted ciphertext fragments, and binding each thread to a single salted ciphertext fragment; performing a single-round hash operation on the bound salted ciphertext fragments within the thread pool to output a 512-bit fixed-length digest; writing the fixed-length digest and the corresponding fragment serial number together to the specified index position in the hash sequence array to form an ordered hash sequence; when the last thread in the thread pool completes the hash operation, calculate the completion flag of the thread pool operation result, and if any thread returns an error code, terminate immediately.

6. The method for secure sharing of cross-regional and cross-institutional health care data based on blockchain according to claim 5, characterized in that, The process of generating the Merkle root in Step 2 includes: initializing the Merkle level list according to the length of the hash sequence array, and copying the hash sequence array as the first layer node list; if the length of the hash sequence array is odd, copy the last hash digest and append it to the end of the Merkle level list to ensure the number of nodes is even; record the number of nodes at the current level and enter an iterative loop with the condition that the number of nodes at the current level is greater than 1; in each loop, take two adjacent hash digests in order from left to right by node, perform string concatenation to get a 1024-bit intermediate string; calculate the hash digest of a new 512-bit parent node for the 1024-bit intermediate string again; write the hash digests of all parent nodes to the next layer node list in the order of generation; if the length of the next layer node list is odd, copy the hash digest of the last parent node and append it to maintain evenness; update the number of nodes at the current level to the length of the next layer node list; repeat the above process until the number of nodes at the current level is equal to 1, and this unique hash digest is the Merkle root.

7. The method for secure sharing of cross-regional and cross-institutional health care data based on blockchain according to claim 6, characterized in that In Step 2, within the same thread context, perform binary concatenation of the Merkle root, the current height block header hash value, and the governance layer smart contract address in a fixed order to generate a 1600-bit zero-redundancy data block; perform an anti-hash operation on the zero-redundancy data block to obtain a 512-bit fragment index token body; perform a readable processing on the fragment index token body using Base58Check encoding to generate the final fragment index token string; call the mint interface in the governance layer smart contract on the blockchain to mint the fragment index token string into a non-fungible token and bind it to the patient's unique address; after the governance layer smart contract returns the transaction hash, write the transaction hash, the fragment index token string, the Merkle root, and the current height block header hash value together to the on-chain event log to achieve an immutable cross-institutional index asset registration.

8. The method for secure sharing of cross-regional and cross-institutional health care data based on blockchain according to claim 7, characterized in that In step 3, after the on-chain smart contract receives the access application from an external medical institution, it first performs a set intersection operation on the identity codes of all external medical institutions listed in this application and the patient consent whitelist; if the number of intersection elements reaches or exceeds the consent threshold set by the patient, it immediately locks the intersection result, generates a candidate consent set, and marks the threshold satisfaction status in the same transaction; once in the threshold satisfaction status, the candidate consent set is written into a read-only memory slot and cannot be changed due to subsequent revocation or addition of consents, ensuring that the parties involved in the subsequent signature process remain fixed; perform a random polling algorithm on the candidate consent set, divide the identity codes of external medical institutions into multiple rounds in a pseudo-random order, and each round contains no more than one-third of the identity codes of external medical institutions; at the beginning of each round, the on-chain smart contract sends a signature invitation to the external medical institution node corresponding to the identity codes of this round, and the invitation message includes the random polling round number, patient identification code, current height block header hash value, and a temporary challenge random number; after receiving the signature invitation, the external medical institution node completes the signature response within the specified time window, otherwise the signature of this round fails and triggers the backup node strategy, and the backup node is randomly selected from the remaining unassigned identity codes in the same round; after each round of signature is completed, the signature fragments obtained in each round are written into the signature buffer pool in the order of rounds; in the signature buffer pool, perform an elliptic curve point addition operation on the signature fragments of two consecutive rounds to generate an intermediate aggregated signature; perform point addition again on the intermediate aggregated signature and the signature fragment of the next round, and iterate step by step until all signature fragments are consumed, and finally obtain a unique aggregated signature.

9. The method for cross-regional and cross-institutional secure sharing of health care data based on blockchain according to claim 8, wherein, After obtaining the unique aggregated signature, the on-chain smart contract writes the patient identification code, candidate consent set, write-chain timestamp, current height block header hash value, and unique aggregated signature into a variable-length byte buffer in the form of key-value pairs in sequence, and then performs a hash operation once to obtain a 512-bit access authorization token fingerprint; perform a readable processing on the access authorization token fingerprint using Base64URL encoding to form an access authorization token, and allocate a unique index key for this access authorization token in the storage area of the on-chain smart contract.

Images