A blockchain-based method for secure sharing of cross-regional and cross-institutional health and medical data

Abstract

The present invention discloses a blockchain-based method for securely sharing cross-regional and cross-institutional health and medical data, relating to the field of data security technology. The method comprises the following steps: Step 1: performing balanced content fragmentation on electronic health records to obtain multiple content fragments, encrypting each content fragment using a random salt value generated by the hash value of the previous block header to obtain a salted ciphertext fragment; Step 2: calculating a hash sequence for all salted ciphertext fragments of the same patient and generating a Merkle root; Step 3: when an external medical institution submits an access request, an on-chain smart contract compares the identity code set of the requested 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 to the blockchain audit sidechain. The present invention solves the problems of low data sharing efficiency, high trust dependence, and audit difficulties under the traditional model.

Description

Technical Field

[0001] The present invention relates to the field of data security technology, and in particular to a method for securely sharing cross-regional and cross-institutional health and medical data based on blockchain. Background Art

[0002] Against the backdrop of the rapid development of digital healthcare, health and medical data has become a core resource of immense strategic importance. Medical institutions, regional health platforms, third-party research institutes, and public health management departments are continuously accumulating vast amounts of critical medical data, including electronic health records, medical histories, test results, imaging data, and individualized intervention feedback. Sharing this data securely, efficiently, and in compliance across regions and institutions will not only facilitate collaborative clinical diagnosis and treatment, the prevention and control of major diseases, and the development of personalized treatment pathways, but will also significantly improve the efficiency of medical resource utilization and public health governance. However, due to multiple factors, including extremely high data sensitivity, complex data ownership structures, and the urgent need for privacy protection, cross-institutional health and medical data sharing currently faces numerous technical barriers and trust bottlenecks in practice.

[0003] In the existing technology system, the main data sharing models include centralized data exchange platforms, interconnection interface standards, entrusted data hosting, and encrypted transmission protocols. In the centralized platform model, multiple medical institutions upload part or all of a patient's data to a unified platform managed by the government or an authoritative agency, which is responsible for unified storage, indexing, access authorization, and auditing. However, in terms of technical implementation, this model often leads to the problem of information islands being transformed into "centralized risk centers." Once the central platform is attacked or a vulnerability occurs in any of its permission management links, the trust mechanism of the entire data sharing system is seriously threatened. In addition, patients' control over their personal health data is very limited in this model, making it difficult to achieve refined access control based on individual wishes.

[0004] Interoperability interface standards, such as HL7 and FHIR, provide standardized data formats and communication protocols, but they primarily address the issue of "understanding" rather than "trust." In actual deployments, different medical institutions interpret the standards differently, resulting in inconsistent versions and poor interface compatibility. This leads to frequent semantic inconsistencies and interoperability failures during data sharing. Furthermore, in multi-institutional collaboration, data lacks tamper-proofing during transmission and storage. Any compromise or malicious data tampering at any node can lead to unclear accountability and even medical accidents. Summary of the Invention

[0005] The purpose of this invention is to provide a blockchain-based cross-regional and cross-institutional health and medical data security sharing method. This method has strong data integrity verification capabilities, a flexible patient-led access control mechanism, and a decentralized data governance structure. It significantly improves the security, credibility, and compliance of medical data during cross-domain circulation, and solves the problems of low data sharing efficiency, high trust dependence, and audit difficulties under the traditional model.

[0006] To solve the above technical problems, the present invention provides a blockchain-based cross-regional and cross-institutional health and medical data security sharing method, which includes:

[0007] Step 1: Perform balanced content fragmentation on the electronic health record to obtain multiple content fragments, each with a fragment serial number; generate a one-time fragment key based on the patient's public key, the fragment serial number, and the write chain timestamp; encrypt each content fragment using a random salt value generated by the hash value of the previous height block header to obtain a salted ciphertext fragment;

[0008] 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 it according to the non-fungible token standard and write it to the blockchain mainnet, making it an immutable cross-institutional index asset;

[0009] Step 3: When an external medical institution submits an access request, the on-chain smart contract compares the identity code set of the 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 the access authorization token, and the authorization result is written to the blockchain audit sidechain.

[0010] Furthermore, in step 1, a structured parsing algorithm is called to scan the electronic health record byte by byte to identify and extract the diagnosis and treatment data elements; three types of metadata are attached to each data element: byte length, sensitivity label and timestamp label; the data element and its metadata are written into a temporary element table; in the temporary element table, the content weight is calculated for each data element, the sum of the content weights of all data elements is counted, and the sum of the content weights is divided by the preset split coefficient to obtain the target fragment capacity; if the target fragment capacity is less than the minimum I / O threshold, the preset split coefficient is automatically adjusted to a smaller value until the target fragment capacity meets the minimum I / O threshold requirement.

[0011] Furthermore, in step 1, a one-way streaming traversal is performed on the temporary element table according to the original order of appearance in the electronic health record, including: maintaining a cumulative weight register to accumulate the content weight of the current data element starting from 0; when the value of the cumulative weight register reaches or exceeds the target fragment capacity for the first time, immediately inserting a boundary marker at the end of the data element, and encapsulating all data elements before the boundary into a content fragment; resetting the cumulative weight register to 0, and continuing to traverse the unprocessed data elements, repeating the above steps until all data elements are divided; if the value of the cumulative 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%.

[0012] Furthermore, in step 1, the target fragment capacity of all content fragments is counted and the capacity variance is calculated; if the capacity variance is greater than the set smoothing threshold, a two-way adjacent merge is performed: the adjacent smallest content fragment and the second smallest content fragment are merged first; the capacity variance is updated in real time after each merge until the capacity variance does not exceed the smoothing threshold; all content fragments finally obtained are numbered in a logical order, starting from 0 and increasing, and each number is a 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, which is embedded in the beginning of the corresponding content fragment to form a content fragment containing a metadata header and an integrity field.

[0013] Furthermore, 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 salted ciphertext fragments, with each thread bound to a single salted ciphertext fragment; performing a single-round hash operation on the bound salted ciphertext fragments in the thread pool, and outputting a 512-bit fixed-length summary; writing the fixed-length summary together with 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, calculating the completion flag of the thread pool operation result, and if any thread returns an error code, it terminates immediately.

[0014] Furthermore, 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, copying the hash digest at the end and appending it to the end of the Merkle level list to ensure that the number of nodes is even; recording the number of nodes at the current level and entering an iterative loop, with the condition that the number of nodes at the current level is greater than 1; in each loop, taking two adjacent hash digests from left to right in node order, performing string concatenation to obtain a 1024-bit intermediate string; calculating the new 512-bit parent node hash digest for the 1024-bit intermediate string again; writing the hash digests of all parent nodes to the next-level node list in the order of generation; if the length of the next-level node list is odd, copying the hash digest of the last parent node and appending it to maintain an even number; updating the number of nodes at the current level to the length of the next-level node list; repeating the above process until the number of nodes at the current level is equal to 1, and the unique hash digest is the Merkle root.

[0015] Furthermore, in step 2, within the same thread context, the Merkle root, the current height block header hash value, and the governance layer smart contract address are binary concatenated in a fixed order to generate a 1600-bit zero-redundancy data block; an anti-hash operation is performed on the zero-redundancy data block to obtain a 512-bit shard index token body; the shard index token body is readable using Base58Check encoding to generate the final shard index token string; the mint interface in the governance layer smart contract is called on the blockchain to mint the shard 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, the transaction hash, shard index token string, Merkle root, and the current height block header hash value are written together into the on-chain event log to achieve tamper-proof cross-institutional index asset registration.

[0016] Furthermore, in step 3, after receiving the access application from the external medical institution, the on-chain smart contract 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, the intersection result is immediately locked, a candidate consent set is generated, and the threshold satisfaction state is marked in the same transaction; once the threshold satisfaction state is reached, the candidate consent set is written into the read-only memory slot and cannot be changed due to subsequent revocation or addition of consent, ensuring that the participants in the subsequent signing process remain unchanged; a random polling algorithm is executed on the candidate consent set, and the identity codes of the external medical institutions are divided into multiple rounds in a pseudo-random order, and each round contains no more than one-third of the identity codes of the external medical institutions; at the beginning of each round, the on-chain The smart contract sends a signature invitation to the external medical institution node corresponding to the identity code of this round. The invitation message contains the random polling round number, patient identification code, current height block header hash value and 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 substitute node strategy. The substitute node is randomly selected from the remaining unassigned identity codes of 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 the rounds; in the signature buffer pool, the elliptic curve point addition operation is performed on the signature fragments of two consecutive rounds to generate an intermediate aggregate signature; the intermediate aggregate signature is point-added with the signature fragment of the next round again, and it is iterated step by step until all signature fragments are consumed, and finally a unique aggregate signature is obtained.

[0017] Furthermore, after obtaining the unique aggregate signature, the on-chain smart contract writes the patient identification code, candidate consent set, chain write timestamp, current height block header hash value and unique aggregate signature into a variable-length byte buffer in the form of a key-value pair, and then performs a hash operation to obtain a 512-bit access authorization token fingerprint; uses Base64URL encoding to make the access authorization token fingerprint readable to form an access authorization token, and assigns a unique index key to the access authorization token in the storage area of ​​the on-chain smart contract.

[0018] The present invention's blockchain-based method for securely sharing health and medical data across regions and institutions offers the following benefits: it effectively addresses key challenges in existing data sharing technologies, such as lack of trust, crude access control, and difficulty verifying data integrity. By introducing a balanced content fragmentation mechanism, the present invention achieves load balancing and efficient encryption while preserving the semantic integrity of original electronic health records. A combined encryption strategy, combining one-time fragment keys with a high-height blockchain hash salt, effectively prevents the security risk of replay or reverse engineering of repeatedly encrypted content. Through hash sequence generation and Merkle root calculation, the present invention establishes a verifiable data integrity structure. The Merkle root, combined with the block header hash value and the governance contract address, forms a fragment index token, which is minted into a non-fungible token. This ensures on-chain uniqueness, immutability, and cross-institutional identifiability of the index information. Regarding the authorization mechanism, the present invention incorporates technologies such as consent thresholds, candidate consent sets, randomized polling signatures, a multi-round backup mechanism, and elliptic curve aggregate signatures to enable patient-led, multi-institutional collaborative authorization, ensuring both trustworthy and traceable authorization results. The resulting access authorization token is hash-compressed and readable, enabling rapid verification of authenticity while also ensuring cross-chain usability and auditability. The overall solution closes the entire process, from data fragmentation generation to on-chain authorization, ensuring highly secure, controllable, and available data sharing throughout its lifecycle. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 A schematic diagram of a method flow for a cross-regional and cross-institutional health and medical data security sharing method based on blockchain provided by an embodiment of the present invention;

[0020] Figure 2 Schematic diagram of an experiment analyzing the effect of content balancing and fragmentation processing provided by an embodiment of the present invention;

[0021] Figure 3 Schematic diagram of a thread pool performance analysis experiment for the Merkle root generation process provided by an embodiment of the present invention;

[0022] Figure 4 A schematic diagram of a statistical experiment on the success rate of access authorization token verification provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0023] refer to Figure 1 :A method for securely sharing cross-regional and cross-institutional health and medical data based on blockchain, the method comprising:

[0024] Step 1: Perform balanced content fragmentation on the electronic health record to obtain multiple content fragments, each with a fragment serial number; generate a one-time fragment key based on the patient's public key, the fragment serial number, and the write chain timestamp; encrypt each content fragment using a random salt value generated by the hash value of the previous height block header to obtain a salted ciphertext fragment;

[0025] 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 it according to the non-fungible token standard and write it to the blockchain mainnet, making it an immutable cross-institutional index asset;

[0026] Step 3: When an external medical institution submits an access request, the on-chain smart contract compares the identity code set of the 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 the access authorization token, and the authorization result is written to the blockchain audit sidechain.

[0027] During the off-chain processing phase, the same electronic health record is broken down into several fragments through balanced content fragmentation, each of which is assigned a fragment sequence number. This design goes beyond data segmentation; its essence is to reduce the sensitivity entropy density of a single fragment in an information-theoretic sense, making it difficult for any single fragment to fully reconstruct the patient's image. At the same time, all fragments are approximately balanced in terms of byte size and sensitivity labels, thereby controlling the probability of successful reconstruction. Subsequently, the process of synchronously generating a one-time fragment key uses the patient's public key, the fragment sequence number, and the write-chain timestamp as inputs to a key derivation function, ensuring that the key cannot be reused horizontally or vertically, preventing attacks such as "same-secret cross-fragment" and "cross-time replay." This embodies the principles of forward and backward security. The random salt is derived from the hash value of the previous block header rather than a local random number because the blockchain consensus layer has already verified the distributed randomness of this hash value. This introduces a network-wide unpredictability from the perspective of the entropy pool. This salted ciphertext fragment is therefore resistant to rainbow table and dictionary attacks, and does not compromise security due to flaws in the terminal random number generator.

[0028] Salted ciphertext fragments are written to a decentralized storage network similar to the InterPlanetary File System, storing only their addressing hash and minimal metadata on the main chain. This architecturally implements a "fat chain index, thin chain data" tiered access model, preventing high-throughput medical files from directly impacting on-chain capacity while ensuring index-level immutability. On-chain, the one-way hash outputs of all salted ciphertext fragments are linked into a Merkle tree structure using a hash sequence as a bridge. The Merkle root compresses the overall integrity proof to a single constant size. Any change to a single fragment's content will result in a hash mismatch from the leaf to the root, enabling global invariance verification in a zero-knowledge manner. The Merkle root is concatenated with the current block header hash and the governance smart contract address, and further encapsulated into a fragment index token. This token is then issued through a non-fungible token protocol, making the index inherently transactional and unique, enabling traceability and query access across regions and institutions without revealing details of the underlying data structure. At the access control level, when an external medical institution makes an application, the on-chain smart contract compares the identity code set of the external medical institution with the patient consent whitelist through set operations, 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.

[0029] This signature mechanism does not rely on a traditional centralized authorization server. Instead, it uses multiple rounds of random polling and segmented aggregation to generate an aggregate signature. This 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 aggregation result, ultimately constructing an access authorization token. The off-chain decryption channel will only be opened after the access authorization token is successfully verified, and any branches that fail verification are written to the blockchain audit sidechain in real time. The blockchain audit sidechain records each successful, failed, or abnormal termination of authorization in the form of an unalterable event log, combining the access authorization token fingerprint, the current height block header hash value, and the write chain timestamp to form a ternary time lock. Any subsequent audit entity only needs to replay the event sequence and hash path to fully reconstruct the decision trajectory, thereby meeting the forensic needs of electronic health records in a multi-jurisdictional compliance environment.

[0030] Furthermore, in step 1, a structured parsing algorithm is called to scan the electronic health record byte by byte to identify and extract the diagnosis and treatment data elements; three types of metadata are attached to each data element: byte length, sensitivity label and timestamp label; the data element and its metadata are written into a temporary element table; in the temporary element table, the content weight is calculated for each data element, the sum of the content weights of all data elements is counted, and the sum of the content weights is divided by the preset split coefficient to obtain the target fragment capacity; if the target fragment capacity is less than the minimum I / O threshold, the preset split coefficient is automatically adjusted to a smaller value until the target fragment capacity meets the minimum I / O threshold requirement.

[0031] The structured parsing algorithm first uses a character-level state machine combined with a natural language rule base to decompose heterogeneous fields such as diagnostic conclusions, image binary blocks, test results, and prescription details into independent diagnosis and treatment data elements. Subsequently, to maintain data measurability and sensitivity grading traceability, the system synchronously generates three types of metadata for each data element: byte length, sensitivity label, and timestamp label. The byte length is measured instantly by the parsing thread in the memory buffer, the sensitivity label is automatically mapped based on the preset medical information classification standard, and the timestamp label references the high-precision clock value at the moment the parsing is started. Before writing the data element and its metadata to the temporary element table, the parsing thread performs a hash check on the original text to ensure that no garbled characters or encoding drift occur during the reading process. The temporary element table is essentially a compact structure array located in restricted memory, which not only maintains the order in which elements are inserted but also facilitates subsequent traversal.

[0032] The system then enters the content weight calculation phase based on information-theoretic metrics. Content weights are calculated by multiplying the byte length by the coefficient corresponding to the sensitivity label. This weight reflects the combined importance of a single medical data element in terms of patient privacy risk and data processing cost. After the algorithm completes the content weight calculation for all elements, it immediately aggregates the weights to provide a constant reference for subsequent shard capacity determination. To prevent off-chain storage efficiency degradation caused by undersized shards, the system divides the total content weight by a preset split coefficient to determine the target shard capacity. For highly sensitive medical records or extremely long images, the target shard capacity may fall below the minimum I / O threshold of the storage medium. Therefore, the parsing module automatically adjusts the preset split coefficient to a smaller value, increasing the capacity of each shard by reducing the split ratio, ensuring that the target shard capacity gradually increases until the minimum I / O threshold is met. This adaptive parameter adjustment logic is simultaneously updated in the parsing thread's shared configuration area and broadcast to the parallel encryption threads to prevent drift in the sequence number base during key derivation and salt generation.

[0033] Data elements include: diagnostic entries, imaging files, test results, prescription information, nursing notes, and expense statements.

[0034] Furthermore, in step 1, a one-way streaming traversal is performed on the temporary element table according to the original order of appearance in the electronic health record, including: maintaining a cumulative weight register to accumulate the content weight of the current data element starting from 0; when the value of the cumulative weight register reaches or exceeds the target fragment capacity for the first time, immediately inserting a boundary marker at the end of the data element, and encapsulating all data elements before the boundary into a content fragment; resetting the cumulative weight register to 0, and continuing to traverse the unprocessed data elements, repeating the above steps until all data elements are divided; if the value of the cumulative 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%.

[0035] The temporary element table preserves the original order of appearance in the electronic health record, meaning any out-of-order splitting operation will disrupt the location mapping during subsequent reconstruction, introducing additional indexing overhead in cross-institutional environments. A unidirectional stream traversal solidifies the order constraint into a linear scan. Each forward step requires only reading the content weight of the current data element and accumulating it into a cumulative weight register, keeping the time complexity strictly linear and eliminating cache jitter caused by random addressing. The cumulative weight register starts at zero, effectively imposing a sliding window on the data stream, with the window threshold being the target fragment capacity. When the register value first reaches or exceeds the target fragment capacity, the algorithm identifies the stream pointer's predecessor position at that moment as a slice boundary and writes a boundary marker at the end of the corresponding data element. The resulting content fragments naturally inherit the contiguous subsequence property of the window coverage, with a manageable error between their capacity and the target fragment capacity. Each boundary marker records the exact time point and sequential position, providing an irrefutable anchor for subsequent hash sequence generation.

[0036] The core principle of this design is to use the cumulative information between consecutive data elements as a metric. Slicing is triggered only when this information reaches a specified threshold. This ensures a near-equilibrium distribution of sensitive information within each content shard, mitigating the risk of single-shard leakage from an information-theoretic perspective. Furthermore, because the target shard capacity is dynamically derived from the minimum I / O threshold and the sum of the content weights, the register threshold naturally adapts to the block write granularity of the underlying storage medium, avoiding write amplification issues caused by large sub-block writes. After the streaming traversal, if the tail segment capacity is less than half the target shard capacity, the system uses a merge strategy to merge the tail segment into the previous content shard, limiting the final inter-shard capacity difference to within ±50%. The theoretical basis for this step is the statistical variance constraint—by limiting the occurrence of extremely small fragments, the overall distribution is closer to the mean. This not only ensures consistent block sizes within the same data batch during encryption batching, reducing the performance loss of the encryption algorithm due to short block padding, but also ensures that the size of individual records in subsequent blockchain metadata writes remains predictable, thereby maintaining stability in network bandwidth and on-chain gas costs. Boundary marker insertion and merging operations are performed entirely in memory, using immutable segment pointers to point to the original data buffer to avoid redundant copies. This not only increases slicing speed but also ensures that no external process can observe the fragmentation of unencrypted data at the disk level, further narrowing the potential attack surface. After merging, the updated content fragments maintain their original order and continuity, so the temporary element table can be directly passed to the next stage to generate the one-time fragment key without reshuffling.

[0037] Furthermore, in step 1, the target fragment capacity of all content fragments is counted and the capacity variance is calculated; if the capacity variance is greater than the set smoothing threshold, a two-way adjacent merge is performed: the adjacent smallest content fragment and the second smallest content fragment are merged first; the capacity variance is updated in real time after each merge until the capacity variance does not exceed the smoothing threshold; all content fragments finally obtained are numbered in a logical order, starting from 0 and increasing, and each number is a 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, which is embedded in the beginning of the corresponding content fragment to form a content fragment containing a metadata header and an integrity field.

[0038] Capacity rebalancing utilizes a bidirectional neighbor merging algorithm. Unlike a simple "global sort followed by pairwise merging," the bidirectional neighbor merging algorithm first locates the current smallest content fragment in the logically ordered list and then checks the capacities of its left and right neighbors. If the left neighbor has a smaller capacity, the system merges the smallest content fragment with it; otherwise, it merges with the right neighbor. This strategy prioritizes eliminating capacity troughs without disrupting the original order, thereby narrowing the tail region of the capacity distribution curve. When the smallest content fragment and its preferred neighbor merge to form a new content fragment, the algorithm immediately recalculates the capacity variance and writes the updated capacity to the runtime metric register. If the updated capacity variance remains greater than the smoothing threshold, the algorithm continues to locate a new smallest content fragment and executes the next round of merging. Because each merge reduces the list length by one and simultaneously increases the minimum capacity, the capacity variance gradually decreases. The algorithm terminates when the capacity variance does not exceed the smoothing threshold. Through multiple rounds of adaptive merging, the system achieves optimal capacity balance with minimal boundary adjustments, without introducing any additional padding bytes or redundant data, thereby maintaining off-chain storage efficiency.

[0039] After capacity balancing is complete, the system immediately numbers all the resulting content fragments in logical order, starting at 0 and incrementing. Each number is a unique fragment sequence number. The fragment sequence number serves as a unique order identifier throughout the entire slicing phase and will be repeatedly referenced during subsequent one-time fragment key derivation, hash sequence splicing, and blockchain metadata writing. Therefore, it must remain monotonically increasing and non-repeatable. To prevent concurrent threads from creating race conditions in extreme situations, the numbering process is completed in single-threaded write mode. An atomic counter that only increases and never decreases is written at runtime to ensure that the maximum fragment sequence number read at any time is the most current globally.

[0040] In the same batch processing cycle where numbering is completed, the system calculates a separate pre-encryption hash checksum for each content fragment and writes this hash checksum into the integrity field at the end of the content fragment. Unlike hashing salted ciphertext fragments after they are generated, pre-encryption hash checksums measure data integrity directly in the plaintext context. This allows for early detection of issues in the event of off-chain storage corruption or disk degradation, preventing wasteful cryptographic computations caused by erroneous data entering the encryption pipeline. Furthermore, the pre-encryption hash checksum uses the same quantum-resistant hash function as the blockchain, ensuring full semantic alignment between on-chain and off-chain computations, facilitating fine-grained comparisons on the audit sidechain.

[0041] The system then combines the fragment sequence number, hash checksum, and sensitivity label into a structured metadata header and embeds it at the beginning of the corresponding content fragment. This structured metadata header uses a TLV (Type-Length-Value) format: the Type field indicates the labels for the three metadata segments, the Length field records the byte length of each field, and the Value field contains the fragment sequence number, hash checksum, and sensitivity label, respectively. Because the sensitivity label comes from the previous parsing stage, it can be directly read by the on-chain smart contract after embedding without decrypting the main text, thus enabling fine-grained pre-filtering for access control. The content fragment maintains the integrity field at the end and adds the structured metadata header at the beginning, while preserving the sequential continuity of the original medical data. This "injection at both ends without altering the main text" packaging method ensures that the medical data is not interspersed or fragmented by any additional fields, reducing cache fragmentation during data alignment in the encryption algorithm. Capacity variance smoothing, bidirectional neighbor merging, unique fragment sequence numbering, pre-encryption hash checksum, and structured metadata header jointly achieve a seamless transition from the slicing phase to the encryption phase. Capacity smoothing ensures load balancing of subsequent encryption threads, fragment serial numbers provide the mapping basis for encryption key derivation and on-chain indexes, hash check codes are embedded in advance in the plaintext stage to ensure storage integrity, and structured metadata headers bind key access control indicators directly to the data itself, providing plug-and-play fields for authorization judgment on the blockchain side.

[0042] The salted ciphertext fragments are:

[0043] ;

[0044] in, For the generated patients No. Salted ciphertext shards are written to IPFS+metadata on-chain; For patients Electronic health records (HL7FHIR format); For content balance Content fragments (≤10MB); is a one-time fragment key; Derivation, The patient's public key; Timestamp for writing the chain; Patient identification code; The medical institution's license number; A random salt value generated from the hash value of the previous block header; It is a bitwise exclusive OR operation; For hash operation.

[0045] Furthermore, 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 salted ciphertext fragments, with each thread bound to a single salted ciphertext fragment; performing a single-round hash operation on the bound salted ciphertext fragments in the thread pool, and outputting a 512-bit fixed-length summary; writing the fixed-length summary together with 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, calculating the completion flag of the thread pool operation result, and if any thread returns an error code, it terminates immediately.

[0046] First, all salted ciphertext fragments of the same patient are retrieved in ascending order of fragment serial numbers. This step ensures that the path index and the fragment serial number correspond one-to-one when the Merkle tree is subsequently constructed, avoiding the risk of mismatch between on-chain index and off-chain data in cross-institutional scenarios. After the retrieval is completed, all salted ciphertext fragments are loaded into a restricted memory buffer, which runs in a hardware-isolated trusted execution environment and can block side-channel detection at the operating system level. In order to eliminate the performance bottleneck caused by traversal pointers, the system also establishes a mapping table from fragment serial numbers to memory pointers, so that any subsequent algorithm can access the specified salted ciphertext fragment in a constant time. The system then dynamically configures the thread pool size based on the number of salted ciphertext fragments. Each thread in the thread pool is fixedly bound to a physical core and locks its cache affinity, reducing context switching and cross-core cache consistency overhead.

[0047] Each thread reads the bound salted ciphertext fragment from its own private register, calls a cryptographic hash function to complete a single round of hashing, and outputs a fixed-length digest of 512 bits. This digest length was chosen to provide sufficient secondary collision safety margin against quantum attack models while maintaining uniform field width at the blockchain index level to facilitate subsequent serialization. Once the fixed-length digest is generated, the thread maintains a local copy of the fragment sequence number and writes the digest and fragment sequence number together to the specified index of the hash sequence array using an atomic write instruction, ensuring lock-free multi-threaded writes. The hash sequence array itself is pre-allocated at an offset based on the fragment sequence number during initialization, so any thread only needs to write once to complete the mapping, without triggering expansion or fragment movement.

[0048] After the thread completes writing, it returns a completion signal to the thread pool scheduler; the scheduler uses a bitmap to record the thread completion status to avoid giant locks. Only when all flags in the bitmap are set to completion, the system updates the completion flag of the calculation thread pool operation result to success and triggers the downstream Merkle tree construction process. If any thread encounters a memory read exception, hash function failure, or output length discrepancy during the hash operation, an error code will be returned immediately; 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 fault audit log, and block further execution to prevent the damaged hash sequence from being pushed onto the chain.

[0049] Furthermore, 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, copying the hash digest at the end and appending it to the end of the Merkle level list to ensure that the number of nodes is even; recording the number of nodes at the current level and entering an iterative loop, with the condition that the number of nodes at the current level is greater than 1; in each loop, taking two adjacent hash digests from left to right in node order, performing string concatenation to obtain a 1024-bit intermediate string; calculating the new 512-bit parent node hash digest for the 1024-bit intermediate string again; writing the hash digests of all parent nodes to the next-level node list in the order of generation; if the length of the next-level node list is odd, copying the hash digest of the last parent node and appending it to maintain an even number; updating the number of nodes at the current level to the length of the next-level node list; repeating the above process until the number of nodes at the current level is equal to 1, and the unique hash digest is the Merkle root.

[0050] Generating a Merkle root is essentially a cryptographic compression process that maps massive amounts of local integrity into constant-level global credentials. To explain this core principle, we must first understand the three properties of hash functions: one-wayness, collision resistance, and avalanche resistance. One-wayness ensures that anyone can only compute a hash digest from salted ciphertext fragments, and cannot deconstruct 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. Avalanche resistance means that changing any one bit in the input will exponentially change the output binary string. These properties together ensure that the hash digest can be used as an "unalterable fingerprint." However, a single fingerprint is not sufficient to cover the entire set of salted ciphertext fragments, as changing any one fragment only changes the digest for that fragment. Storing only a single fingerprint on the blockchain cannot prove the status of all other fragments. The Merkle tree, through the recursive operation of "hashing two adjacent fingerprints," elevates this locally unalterable fingerprint into a globally unalterable fingerprint, the Merkle root. Once the Merkle root is embedded in the blockchain header, the integrity of all underlying fragments is tied to the immutable nature of the blockchain itself.

[0051] When initializing the Merkle hierarchy, the system losslessly copies each 512-bit hash digest in the hash sequence array to the leaf level. To ensure a perfectly closed binary pairing structure, the number of leaf nodes must be even, which is why the trailing hash digest is copied and appended when the sequence length is odd. This does not compromise security, as the copied node shares the same hash value as the original node, but still independently participates in the parent node calculation in left-to-right order within the tree. Therefore, any attempt to delete the trailing fragment will disrupt the pairing structure, immediately revealing itself when recalculating the Merkle root.

[0052] After entering the iteration loop, the operation of "taking two adjacent 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 obfuscation property of the hash function to entropy merge the information of the two child nodes. If an attacker only tampers with one of the child nodes, even if the hash length remains unchanged, they cannot create a new parent node digest that matches the old value, because they must also reverse-infer the value of the other child node, which is almost impossible under the collision resistance assumption. Using 1024-bit concatenation instead of byte-by-byte interleaving or other serialization methods is to simplify implementation: concatenation ensures a fixed input permutation 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 unified into a 512-bit fixed-length digest, so that the width of nodes at all levels of the tree remains consistent, which not only facilitates storage alignment but also ensures a constant log space budget.

[0053] After the parent node is generated, it is written into the node list of the next layer in order. The reason why the order remains unchanged is that the fragment serial number originally corresponds to the logical position of the real medical information in the medical record. If the order of the nodes is disrupted at a certain layer, even if the Merkle root can still be calculated correctly, the future on-chain retrieval path will be offset, resulting in the inability to search for leaves based on the root during cross-institutional verification. At the end of each layer, the number of nodes must be checked again to see if it is an odd number and filled in, in order to keep the tree shape balanced at all levels. A balanced tree brings two important results: first, the verification path length from any leaf node to the Merkle root is consistent, and the network transmission overhead is predictable; second, the blockchain side does not need to pay attention to the node distribution when making a static estimate of the verification proof size. The "worst case" and the "average case" are the same, which facilitates the consensus protocol to package and price gas billing or transaction size limits at one time.

[0054] When the iteration loop stops when only one node remains, the resulting unique hash digest becomes the Merkle root. While the Merkle root is still 512 bits long, it contains the integrity information for all fragments. The blockchain only needs to store this constant value to provide immutable proof of massive amounts of data. To verify individual salted ciphertext fragments, any medical institution simply needs to request the hash values ​​of the siblings along the path from the fragment to the root node. This path length is logarithmic, making verification much less complex than recalculating the entire tree. A deeper principle lies in "separability": in a Merkle tree structure, deleting or adding any fragment changes the chain of hash outputs from its parent node, grandparent node, and ultimately the root node. Therefore, the Merkle root can be viewed as a commitment to the set of fragments, while the path proof is a disclosure between that commitment and a specific fragment. This commitment-disclosure model allows the blockchain to maintain a small fingerprint while supporting external data integrity verification for an unlimited number of fragments, ideally suited to bandwidth and storage constraints in cross-regional and cross-institutional scenarios.

[0055] Furthermore, the Merkle root ensures sequential integrity. Because the leaf layers are arranged in ascending order by fragment number, any attempt to swap two fragments would simultaneously alter the generation sequence of their parent nodes, causing the entire path to the root to be misaligned and ultimately causing the Merkle root to fail verification. Therefore, the Merkle tree not only detects content tampering but also prevents sequence tampering, which is crucial for the temporal integrity of medical records. The blockchain binds the Merkle root to the block header hash and, supplemented by an on-chain timestamp, creates a dual time attribution: while the block generation time cannot be later altered, the root value and time together establish the fact that the system actually held these fragments at a certain moment in time, in the specified order. This provides strong technical support for subsequent evidence in medical disputes.

[0056] Finally, the Merkle Root can be further encapsulated into the shard index token by the governance layer smart contract address because the index token must not only express integrity but also the semantics of "belonging to a patient and subject to a certain governance policy." The Merkle Root provides the integrity coordinate, the current height block header hash provides the full chain synchronization coordinate, and the governance layer smart contract address provides the governance and access control coordinate. The combined three create an index token that can be retrieved across institutions and triple-locks any subsequent attempts to tamper with the shard or misappropriate the token. In other words, the Merkle Root in this approach is not an isolated tree root, but the cryptographic backbone of the entire cross-regional and cross-institutional shared chain, fulfilling a one-stop proof role from data security and sequence consistency to audit and accountability.

[0057] Furthermore, in step 2, within the same thread context, the Merkle root, the current height block header hash value, and the governance layer smart contract address are binary concatenated in a fixed order to generate a 1600-bit zero-redundancy data block; an anti-hash operation is performed on the zero-redundancy data block to obtain a 512-bit shard index token body; the shard index token body is readable using Base58Check encoding to generate the final shard index token string; the mint interface in the governance layer smart contract is called on the blockchain to mint the shard 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, the transaction hash, shard index token string, Merkle root, and the current height block header hash value are written together into the on-chain event log to achieve tamper-proof cross-institutional index asset registration.

[0058] During the index construction phase of a blockchain-based approach for secure cross-regional and cross-institutional health and medical data sharing, the system must implement the previously generated Merkle root into a unique symbol that can be quickly retrieved across different chain nodes while also possessing asset attributes. To achieve this, the Merkle root, the hash value of the current block header, and the address of the governance layer smart contract are first binary concatenated in a strictly fixed order within the same thread context to produce a 1600-bit zero-redundancy data block. The primary motivation for using "binary hard concatenation" rather than label-value sequences or variable-length fields is to eliminate 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 an identical zero-redundancy data block, thus eliminating hashing bias introduced by cross-implementation differences. A secondary significance of zero-redundancy is the "entropy merging" of the three already independently immutable pieces of information into a single, higher-information carrier. This allows the subsequent hash function to focus 100% on business-critical information without wasting computation on blank bits or delimiters.

[0059] A 512-bit anti-hash operation is performed on the zero-redundancy data block, outputting a fragment index token body with a constant length of 512 bits. The choice of an anti-hash algorithm over a traditional hash function ensures that the quadratic collision complexity remains above 2 to the power of 256 under quantum threat models, which is particularly critical for medical data that spans multiple years of storage. The 512-bit output ensures a safety margin while remaining consistent with the previous leaf and parent hash bit widths, avoiding parsing branches caused by varying lengths of on-chain evidence fields.

[0060] Once the fragment index token body is complete, it needs to be converted into a representation that can be unambiguously read and written by both humans and systems. Therefore, Base58Check encoding is used to generate the fragment index token string. Compared to the more common Base64, Base32, or hexadecimal representations, Base58Check encoding eliminates easily confused characters such as zeros, uppercase and lowercase Os, and lowercase Is, reducing the error rate during manual entry or visual verification. It also includes a built-in checksum bit that automatically detects single-character errors when copied between nodes or transmitted via QR codes, which meets the low error tolerance requirements of medical scenarios. The resulting fragment index token string possesses the dual robustness of being "machine-parseable and human-verifiable."

[0061] Once the index is generated and locally verified, 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. This non-fungible token is then directly bound to the patient's unique address via contract parameters. There are three reasons for using non-fungible tokens instead of ordinary key-value pairs: First, non-fungible tokens inherently guarantee uniqueness and transferability at the protocol level, preventing duplicate minting or malicious tampering; second, the ownership and transfer history of non-fungible tokens are fully documented in an immutable on-chain ledger, facilitating real-time tracking by subsequent regulators or data subjects; and third, existing decentralized custodial wallets and multi-signature libraries already support comprehensive permission models for non-fungible tokens, eliminating the need for additional governance layer code maintenance costs.

[0062] Once the governance smart contract returns the transaction hash, the system immediately writes the transaction hash, shard index token string, Merkle root, and the current block header hash to the on-chain event log, enabling an immutable, cross-institutional indexed asset registry. As an append-only, non-deletable data structure, the on-chain event log naturally meets audit traceability requirements. Simultaneously, the event log is broadcast to all blockchain nodes at the subscription level, ensuring that newly minted non-fungible tokens are synchronized to cross-regional query gateways with minimal latency. This allows any external medical institution holding a patient's authorization to simply fetch the shard index token string and reverse-parse it through the contract query interface to the corresponding Merkle root and the block height at which the chain was written. This allows verification of the integrity of the salted ciphertext shard set without accessing the plaintext. In the event of a future chain fork or cross-chain verification, the current block header hash recorded in the event log will provide a unique anchor for consensus backtracking.

[0063] Merkel root for:

[0064] ;

[0065] in, For patients of Merkelgen; For patients The number of content fragments; The data element to which the content fragment belongs; A random salt value generated from the hash value of the block header at the current height; It is the smart contract address of the governance layer.

[0066] Furthermore, in step 3, after receiving the access application from the external medical institution, the on-chain smart contract 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, the intersection result is immediately locked, a candidate consent set is generated, and the threshold satisfaction state is marked in the same transaction; once the threshold satisfaction state is reached, the candidate consent set is written into the read-only memory slot and cannot be changed due to subsequent revocation or addition of consent, ensuring that the participants in the subsequent signing process remain unchanged; a random polling algorithm is executed on the candidate consent set, and the identity codes of the external medical institutions are divided into multiple rounds in a pseudo-random order, and each round contains no more than one-third of the identity codes of the external medical institutions; at the beginning of each round, the on-chain The smart contract sends a signature invitation to the external medical institution node corresponding to the identity code of this round. The invitation message contains the random polling round number, patient identification code, current height block header hash value and 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 substitute node strategy. The substitute node is randomly selected from the remaining unassigned identity codes of 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 the rounds; in the signature buffer pool, the elliptic curve point addition operation is performed on the signature fragments of two consecutive rounds to generate an intermediate aggregate signature; the intermediate aggregate signature is point-added with the signature fragment of the next round again, and it is iterated step by step until all signature fragments are consumed, and finally a unique aggregate signature is obtained.

[0067] In this blockchain-based approach to securely sharing health and medical data across regions and institutions, the core concept behind the access authorization process is to transform the patient's consent threshold into a mechanically verifiable decentralized vote, using elliptic curve point-addition aggregate signatures as the consensus hammer. This approach avoids centralized trust while ensuring that each participating external medical institution leaves a cryptographically irrefutable trace of consent. The on-chain smart contract first performs a set intersection operation on the external medical institution's identity code and the patient's consent whitelist. This step is not simply a screening operation, but rather a deterministic mapping within the blockchain's global state tree, pinpointing the fuzzy concept of "who is allowed" at the business level to a count of elements in the identity code set. Only when the number of elements in the intersection reaches or exceeds the patient's consent threshold is the threshold-satisfied state marked. Once marked, the state, along with the candidate consent set, is written to a read-only memory slot, transforming it from a mutable state to an immutable state, blocking any subsequent attempts to withdraw or add consent. This effectively creates a "snapshot" on the chain, ensuring that subsequent signing processes are not disrupted by dynamic membership changes. The random polling algorithm further introduces unpredictability and fairness by dividing the candidate consent set into multiple rounds, with each round size not exceeding one-third of the total, ensuring that any failure in a single round will not cause the system to completely shut down. At the same time, the random polling sequence is derived from a temporary challenge random number generated within the contract and the hash value of the current height block header, making it difficult for external observers to predict in advance which nodes will be invited in the next round, thereby weakening the effect of premeditated signature rejection or Sybil attacks.

[0068] The on-chain smart contract broadcasts signature invitations to nodes in rounds. If a node fails to respond within a given time window, a replacement node strategy is triggered. This timeout eviction mechanism encapsulates the uncertainty of the off-chain network with the on-chain state machine, ensuring the real-time and finality of the authorization process. All successfully returned signature fragments are written to the signature buffer pool in round order, and then an elliptic curve point addition operation is performed within the same trusted execution environment. The mathematical essence of point addition is to treat each signature fragment as a vector in the same elliptic curve group and sum them. The resulting aggregate signature contains the information of all fragments while maintaining a fixed-length output. Each point addition is immediately aggregated with the signature fragment of the next round until all signature fragments are consumed to generate a unique aggregate signature. The advantage of this approach is that a constant value can be used to prove that multiple independent medical institutions made authorization decisions for the same patient identification code at the same block height. Any subsequent tampering with the individual signature fragments will destroy the aggregate result, causing on-chain verification to immediately fail.

[0069] Furthermore, after obtaining the unique aggregate signature, the on-chain smart contract writes the patient identification code, candidate consent set, chain write timestamp, current height block header hash value and unique aggregate signature into a variable-length byte buffer in the form of a key-value pair, and then performs a hash operation to obtain a 512-bit access authorization token fingerprint; uses Base64URL encoding to make the access authorization token fingerprint readable to form an access authorization token, and assigns a unique index key to the access authorization token in the storage area of ​​the on-chain smart contract.

[0070] During the authorization generation phase of a blockchain-based approach for secure cross-regional and cross-institutional health and medical data sharing, the unique aggregate signature merely cryptographically proves that "sufficient parties have consented." To convert this fact into a credential that can be directly referenced on-chain, easily portable across off-chain systems, and uniformly recognized by nodes across institutions, a further serialization-hashing-encoding-indexing pipeline is required. The smart contract first populates a variable-length byte buffer with predefined keys, one by one, by inserting the patient identifier, the candidate consent set, the write timestamp, the hash of the current block header, and the unique aggregate signature. This is done by using key-value pairs rather than simple concatenation to prevent future protocol version evolutions from causing errors in parsing by older nodes due to field insertions or reordering. The key itself acts as a field separator, providing independent meaning for each segment. This prevents attackers from deleting or re-inserting segments to maintain the overall binary length consistency and defeat the hash verification. Once these five key pieces of information are populated, the buffer contains the complete authorization context, and each field is locked by the previous process, making further modifications impossible. The smart contract then performs a single round of hashing on the buffer, compressing the variable-length business context into a fixed-length 512-bit access authorization token fingerprint; hashing in one step avoids the combinatorial attack surface brought by field-by-field segmented hashing, and also ensures that different patients, different rounds or different block heights will obtain completely unrelated output values, thereby achieving strong entropy separation.

[0071] 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 transmitted 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 final generated access authorization token is not only short and unambiguous, but can also be directly embedded in existing WebAPIs. 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, the access authorization token is immediately within the complete governance track of "verifiable, freezable, and traceable" once it is generated. Subsequently, external medical institutions only need to submit the token with the transaction, and the on-chain logic can complete the authenticity verification and decide whether the data channel is open in a constant time. This achieves seamless connection between authorization generation and authorization use, no central intermediary, and immediate effectiveness under the consensus of the entire network.

[0072] The access authorization token is:

[0073] ;

[0074] 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 Generated BLS threshold signature; The expiration time of the access authorization token; , 1 means authorization is successful; otherwise it is rejected.

[0075] 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 out, and their byte length sequence is . Sensitivity label sequence Mapping coefficients in sequence Content weight ; Total weight Initial target fragment capacity .

[0076] because ,Keep One-way flow traversal, cumulative weight register Gradually accumulate: ; Thus the first content fragment is generated (including elements ),capacity Reset ,continue ;

[0077] The remaining two elements ; Insufficient tail section The situation did not occur, so it was not merged. 3 pieces were obtained: Capacity variance ; No further merging is required.

[0078] A one-time shard key is derived for each shard. For example

[0079] ;

[0080] Previous height block header hash .

[0081] Salted ciphertext ;

[0082] Empathy Generation .

[0083] right parallel computing ;

[0084] Since the number of nodes is odd, copy the end: Leaf layer . Parent layer ;

[0085] Merkelgen ;

[0086] Generate shard index token body ;

[0087] Final Shard Index Token .

[0088] Call .

[0089] Set patient consent threshold . External medical institutions submit identity code collection ; intersection .

[0090] Candidate consent set . Randomly divided into two rounds.

[0091] Round 1: , Round 2: .polymerization .

[0092] Access authorization token fingerprint .

[0093] Access authorization token .

[0094] Contract storage mapping .

[0095] Assume that the number of valid blocks in the regional chain in this cycle is ;

[0096] Number of patient consent events ;

[0097] Weight Update .

[0098] Audit Window event:

[0099] ;

[0100] Illegal instructions .

[0101] .

[0102] If the fuse threshold is , immediately triggering the freezing of the access authorization token .

[0103] Figure 2 This comprehensive analysis demonstrates the effectiveness of fragmenting electronic health records using a content-balanced fragmentation algorithm. The horizontal axis represents eight content fragments, sorted by content fragment number, starting at 1 and increasing in increments. Each fragment number represents a unique fragment sequence. The vertical axis represents the target fragment capacity in bytes, ranging from 500 to 2500 bytes.

[0104] The bar chart clearly shows the serious imbalance in 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 medical 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 of the traditional sequential segmentation method that cannot guarantee the control of capacity differences between fragments. Calculation shows 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, which preferentially merges 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 ultimately determines the merging strategy.

[0105] After bidirectional neighbor merging, the target fragment capacity distribution of all content fragments exhibits a significantly balanced distribution, as shown by the thick solid line. The capacities of the eight processed content fragments stabilized around 1980 bytes, 1950 bytes, 2020 bytes, 1890 bytes, 1950 bytes, 2020 bytes, 1980 bytes, and 1950 bytes, respectively, fluctuating slightly around the target fragment capacity baseline of 2000 bytes. The capacity variance decreased significantly from 845,236 before processing to 152, a decrease of 99.98%, fully demonstrating the excellent effectiveness of the bidirectional neighbor merging algorithm in achieving balanced content fragmentation.

[0106] The processed fragment capacity variance is controlled within a ±50-byte range, far less than the ±50% design requirement, ensuring that each content fragment has similar data processing complexity and storage overhead. This balanced processing lays a stable technical foundation for subsequent one-time fragment key generation, salted ciphertext fragment encryption, and Merkle root calculations, effectively avoiding system performance bottlenecks and security risks caused by excessive fragment capacity variance.

[0107] Figure 3This article analyzes the performance improvements achieved by using thread pool parallel processing compared to traditional single-threaded serial processing during Merkle root generation. The horizontal axis represents the number of salted ciphertext fragments involved in the hash operation, using a logarithmic scale and covering the full range of tests, from 10 to 2000 fragments. The vertical axis represents the time required to complete the entire hash operation, in milliseconds, ranging from 50 to 250 milliseconds.

[0108] The dotted line represents the performance of the traditional single-thread serial processing method. When processing 10 salted ciphertext fragments, the single-thread method requires 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-thread processing time is further extended to 165 milliseconds. In the test scenario of 200 fragments, the single-thread method requires 205 milliseconds. When processing 500 fragments, the time consumption surges to 238 milliseconds. When facing 1000 fragments, the single-thread processing time reaches 248 milliseconds. In the large-scale scenario of processing 2000 fragments, the processing time of the single-thread method reaches a peak of 252 milliseconds, reflecting a clear performance bottleneck feature. The thick solid line shows the performance advantage of the thread pool parallel processing technology used in the present invention. The thread pool configuration follows the design principle of binding a single salted ciphertext fragment to each thread to ensure load balancing and resource isolation between threads. When processing 10 salted ciphertext fragments, the thread pool method only takes 38 milliseconds, an improvement of 18.4% compared to the single-thread method. When processing 50 fragments, the thread pool processing time dropped to 32 milliseconds, a performance improvement of 72.2%. When processing 100 fragments, the thread pool processing time was only 39 milliseconds, a 4.2-fold performance improvement compared to the 165 milliseconds of a single thread.

[0109] In larger-scale testing scenarios, the performance advantage of the thread pool becomes increasingly evident. When processing 200 fragments, the thread pool took 42 milliseconds, a 4.9-fold performance improvement. When processing 500 fragments, the thread pool took 48 milliseconds, a 5.0-fold performance improvement. When processing 1,000 fragments, the thread pool took only 52 milliseconds, a significant 8.7-fold improvement compared to the 248 milliseconds of a single thread. In the largest test, with 2,000 fragments, the thread pool kept processing time under 58 milliseconds, a 12.3-fold performance improvement compared to the 252 milliseconds of a single thread, fully demonstrating the technical superiority of the parallel processing architecture in large-scale data scenarios. The thread pool utilizes a constrained memory buffer management mechanism. By establishing a mapping table from fragment sequence numbers to memory pointers, it enables efficient access to salted ciphertext fragments and precise control of memory resources. Each thread outputs a 512-bit fixed-length digest during a single hashing round, 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 operation result. If any thread returns an error code, the entire processing flow is terminated immediately, ensuring the robustness and reliability of the system.

[0110] Figure 4 This study analyzes the statistical characteristics of the verification success rates of access authorization tokens generated using elliptic curve point addition aggregate signature technology under different consent threshold settings. The horizontal axis represents the consent threshold configuration set by the patient, ranging from the most lenient one-third threshold to the most stringent unanimous threshold, covering various authorization scenarios that may arise in real-world applications. The vertical axis represents the access authorization token verification success rate, ranging from 0.5 to 1.0, reflecting the impact of different threshold settings on system reliability.

[0111] The thick solid line shows the verification success rate of the elliptic curve point addition aggregate signature technology used in this invention. When the consent threshold is set to one-third, the system achieves the optimal verification success rate, reaching a high of 0.98. At this point, the on-chain smart contract only requires one-third of the external medical institution ID codes to meet the patient consent whitelist requirement. The candidate consent set is relatively small, and the random polling algorithm includes a moderate number of ID codes in each round, optimizing the complexity of the elliptic curve point addition operation. The gradual iteration process of the intermediate aggregate signature is stable and controllable, resulting in a unique aggregate signature with extremely high verification reliability. When the consent threshold is increased to one-half, the verification success rate drops slightly to 0.96, but remains high. At this point, the size of the candidate consent set increases, and the random polling algorithm must process more external medical institution nodes. The signature fragment generation and aggregation process face greater challenges from network latency and node response uncertainty. Nevertheless, the mathematical stability of elliptic curve point addition ensures the overall reliability of the aggregate signature. At the two-thirds threshold configuration, the verification success rate drops to 0.93. At this point, the candidate consent set covers the majority of external medical institution identity codes. As the number of rounds of the random polling algorithm increases, the number of signature fragments after each signature round significantly increases. The elliptic curve point addition operation requires more intermediate aggregate signature iterations, and the accumulated computational errors and network transmission delays have a measurable impact on the final verification result.

[0112] When the consent threshold reaches three-quarters, the verification success rate drops further to 0.89. The high threshold setting requires that almost all external medical institutions participate in the signing process, which increases the coordination complexity of the system. The triggering frequency of the substitute node strategy increases, and some external medical institution nodes are unable to complete the signature response within the specified time window, resulting in the failure of the current signature round and the need to activate the substitute mechanism. Under the strict threshold settings of four-fifths and nine-tenths, the verification success rate drops to 0.82 and 0.71, respectively. At this point, the system is close to a 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 most stringent unanimous requirement, 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 at each threshold setting is significantly lower than that of the elliptic curve point addition aggregate signature technology of the present invention, verifying the technical superiority and practical value of the new technology solution.

[0113] The present invention has been described in detail above. Specific examples are used herein to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only intended to help understand the method and core ideas of the present invention. It should be noted that, for those skilled in the art, without departing from the principles of the present invention, several improvements and modifications may be made to the present invention, and such improvements and modifications also fall within the scope of protection of the claims of the present invention.

Claims

1. A blockchain-based cross-regional and cross-institutional health and medical data security sharing method, characterized by: The method comprises: Step 1: Perform balanced content fragmentation on the electronic health record to obtain multiple content fragments, each with a fragment serial number; generate a one-time fragment key based on the patient's public key, the fragment serial number, and the write chain timestamp; encrypt each content fragment using a 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 current height block header hash value, 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 a request for access, the on-chain smart contract compares the identity code set of the 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 the access authorization token, and the authorization result is written to the blockchain audit sidechain; In step 1, a structured parsing algorithm is invoked to scan the electronic health record byte by byte, identifying and extracting medical data elements. Three types of metadata are attached to each data element: byte length, sensitivity label, and timestamp label. The data element and its metadata are written to a temporary element table. In the temporary element table, a content weight is calculated for each data element, the sum of the content weights of all data elements is calculated, and the sum of the content weights is divided by the preset split coefficient to obtain the target fragment capacity. If the target fragment capacity is less than the minimum I / O threshold, the preset split coefficient is automatically adjusted to a smaller value until the target fragment capacity meets the minimum I / O threshold requirement. In step 1, a one-way streaming traversal is performed on the temporary element table according to the original order of appearance in the electronic health record, including: maintaining a cumulative weight register to accumulate the content weight of the current data element starting from 0; when the value of the cumulative weight register reaches or exceeds the target fragment capacity for the first time, a boundary marker is immediately inserted at the end of the data element, and all data elements before the boundary are encapsulated into a content fragment; the cumulative weight register is reset to 0, and the unprocessed data elements are continued to be traversed, and the above steps are repeated until all data elements are divided; if the value of the cumulative 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%.

2. The cross-regional and cross-institutional health and medical data security sharing method based on blockchain as claimed in claim 1 is characterized in that: In step 1, the target fragment capacity of all content fragments is counted and the capacity variance is calculated. If the capacity variance is greater than the set smoothing threshold, a two-way neighbor merge is performed: the smallest content fragment and the second smallest content fragment are merged first. After each merger, the capacity variance is updated in real time until the capacity variance does not exceed the smoothing threshold; All content fragments obtained are numbered in logical order, starting from 0 and increasing in number. Each number is a 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 sequence number, hash check code and sensitivity label are combined into a structured metadata header and embedded into the beginning of the corresponding content fragment to form a content fragment containing a metadata header and an integrity field.

3. The cross-regional and cross-institutional health and medical data security sharing method based on blockchain as claimed in claim 2 is 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 sequence numbers; loading the salted ciphertext fragments into a restricted memory buffer and establishing a mapping table from fragment sequence numbers to memory pointers; starting a thread pool with the same number of salted ciphertext fragments, with each thread bound to a single salted ciphertext fragment; performing a single round of hash operation on the bound salted ciphertext fragments in the thread pool, and outputting a 512-bit fixed-length digest; writing the fixed-length digest together with the corresponding fragment sequence 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, calculating the completion flag of the thread pool operation result, and if any thread returns an error code, it terminates immediately.

4. The cross-regional and cross-institutional health and medical data security sharing method based on blockchain as claimed in claim 3 is 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-level node list; if the length of the hash sequence array is odd, copying the hash digest at the end and appending it to the end of the Merkle level list to ensure that the number of nodes is even; recording the number of nodes in the current level, and entering an iterative loop, with the condition that the number of nodes in the current level is greater than 1; in each loop, taking two adjacent hash digests from left to right in node order, performing string concatenation to obtain a 1024-bit intermediate string; calculating the new 512-bit parent node hash digest for the 1024-bit intermediate string again; writing the hash digests of all parent nodes to the next-level node list in the order of generation; if the length of the next-level node list is odd, copying the hash digest of the last parent node and appending it to maintain an even number; updating the number of nodes in the current level to the length of the next-level node list; repeating the above process until the number of nodes in the current level is equal to 1, and the unique hash digest is the Merkle root.

5. The cross-regional and cross-institutional health and medical data security sharing method based on blockchain as claimed in claim 4 is characterized in that: In step 2, within the same thread context, the Merkle root, the current height block header hash value, and the governance layer smart contract address are binary concatenated in a fixed order to generate a 1600-bit zero-redundancy data block; an anti-hash operation is performed on the zero-redundancy data block to obtain a 512-bit shard index token body; the shard index token body is readable using Base58Check encoding to generate the final shard index token string; the mint interface in the governance layer smart contract is called on the blockchain to mint the shard 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, the transaction hash, shard index token string, Merkle root, and the current height block header hash value are written into the on-chain event log to achieve tamper-proof cross-institutional index asset registration.

6. The cross-regional and cross-institutional health and medical data security sharing method based on blockchain as claimed in claim 5 is characterized in that: In step 3, after receiving the access application from the external medical institution, the on-chain smart contract 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, the intersection result is immediately locked, a candidate consent set is generated, and the threshold satisfaction state is marked in the same transaction; once the threshold satisfaction state is reached, the candidate consent set is written into the read-only memory slot and cannot be changed due to subsequent revocation or addition of consent, ensuring that the participants in the subsequent signing process remain unchanged; a random polling algorithm is executed on the candidate consent set, and the identity codes of the external medical institutions are divided into multiple rounds in a pseudo-random order, and each round contains no more than one-third of the identity codes of the external medical institutions; at the beginning of each round, the on-chain smart contract A signature invitation is sent to the external medical institution node corresponding to the identity code of this round. The invitation message contains the random polling round number, patient identification code, current height block header hash value and 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 substitute node strategy. The substitute node is randomly selected from the remaining unassigned identity codes of 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 the rounds; in the signature buffer pool, the elliptic curve point addition operation is performed on the signature fragments of two consecutive rounds to generate an intermediate aggregate signature; the intermediate aggregate signature is point-added with the signature fragment of the next round again, and it is iterated step by step until all signature fragments are consumed, and finally a unique aggregate signature is obtained.

7. The cross-regional and cross-institutional health and medical data security sharing method based on blockchain as claimed in claim 6 is characterized in that: After obtaining the unique aggregate signature, the on-chain smart contract writes the patient identification code, candidate consent set, chain write timestamp, current height block header hash value and unique aggregate signature into a variable-length byte buffer in the form of a key-value pair, and then performs a hash operation to obtain a 512-bit access authorization token fingerprint; uses Base64URL encoding to make the access authorization token fingerprint readable to form an access authorization token, and assigns a unique index key to the access authorization token in the storage area of ​​the on-chain smart contract.

Images