A medical scientific research information sharing method and system based on a key and a blockchain

Abstract

The application discloses a medical scientific research information sharing method and system based on a key and a block chain, relates to the technical field of data processing, and comprises the following steps: generating equal-length record quantity change sequences and limit level record proportion change sequences according to a sharing request; taking the median of each sequence as a benchmark, and only counting the positions of the two sequences that are both above the median and rising as the original position common rising maximum continuous length; fixing the previous sequence, performing all non-zero cyclic shifts on the latter sequence, taking the maximum value of the maximum continuous length of the shift as a reference, blocking the sharing when the original position length is greater than the reference, and otherwise allowing the sharing; the block chain verification node independently recalculate and consensus confirmation, and only when the confirmation is allowed and the sharing request digest review is consistent, a one-time data encryption key is generated by a hardware security module. The application solves the problem that continuous common rising is difficult to determine the calculation and identification, makes the sharing judgment obtain the same dimension reference, and directly controls the key generation by the verification result.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, specifically to a method and system for sharing medical research information based on keys and blockchain. Background Technology

[0002] When medical institutions share medical research data with research institutions, they typically need to determine whether the sharing request meets the key generation conditions before data encryption. Current processing generally focuses on request permissions, certificate validity, field integrity, or individual data indicator verification. It lacks a repeatable verification mechanism for the continuous, shared changes in the number of records to be shared and the proportion of restricted medical research data records at their original time points. The main problem is that the key generation conditions are difficult to deterministically bind to the original time correspondence between the two changing data sequences, making it difficult to distinguish between a continuous, shared increase at the original time point and a localized correspondence formed by chance in the data distribution.

[0003] First, medical research data is written unevenly; different research projects, treatment stages, or data acquisition devices may have different write frequencies. When using a fixed time window, the same continuous write may be divided into multiple windows, and independent write processes may be merged into the same window. Second, if fixed thresholds are used to judge changes in the number of records and changes in the proportion of restricted records, the thresholds are difficult to adapt to different request scales; if the two changes are summed or weighted, a larger change on one side may compensate for a situation where the other side does not change. Even if two indicators rise simultaneously at a certain position, it is impossible to determine whether this correspondence is significantly different from a simultaneous rise that may still occur after changing the time position based solely on that single position.

[0004] For example, a single sharing request creates five consecutive time-series record segments with record counts of 10, 20, 40, 40, and 40 respectively, and restricted record ratios of 0.1, 0.4, 0.4, 0.4, and 0.4 respectively. There are positions in the original time sequence where both the number of records and the restricted record ratio increase simultaneously. However, even if the numerical distributions of the two changing sequences remain unchanged, and only the positional correspondence is altered, a simultaneous increase of the same length may still occur. If the processing system only checks whether a simultaneous increase occurs in the original position, or if the central node directly provides the judgment result, it cannot determine whether the result comes from the original time correspondence or from a chance correspondence that may occur under the current data distribution. When this judgment result triggers the generation of a one-time data encryption key without deterministic recalculation by the blockchain verification node, it is difficult to establish a continuous and verifiable technical control relationship between data judgment, node verification, and key generation. Summary of the Invention

[0005] This invention provides a method and system for sharing medical research information based on keys and blockchain. It solves the technical problem of how to deterministically and recalculately identify the continuous and common increase of the number of records and the proportion of restricted records at the original time position, and to form a reference of the same dimension by using the non-zero cyclic shift result of the current request itself, so that the result confirmed by the blockchain verification node can directly control the generation of one-time data encryption keys.

[0006] A method for sharing medical research information based on keys and blockchain, characterized by the following steps: acquiring sharing request data; generating a sharing request summary, and generating a sequence of record quantity changes and a sequence of restricted record proportion changes of equal length, each containing at least two elements, with each element containing a change amplitude value and an increase indicator value; subtracting the median of each change amplitude value from the median of the sequence, setting negative differences to 0; when both differences at the same position are greater than 0 and both increase indicator values ​​are 1, the common median increase indicator value is 1, otherwise it is 0, linearly calculating the maximum continuous length of the common increase at the original position; fixing the record quantity change sequence, and restricting... All non-zero cyclic shifts in the sequence of proportional changes at each level are recorded. The maximum value is taken as the maximum continuous length of the non-zero cyclic shifts. If the maximum continuous length of the non-zero cyclic shifts is greater than this length, the shared control code to be confirmed is 0; otherwise, it is 1. Blockchain verification nodes independently recalculate based on the same shared request data. When the number of nodes with the same complete recalculation result reaches the number of consensus confirmation nodes, the shared control code to be confirmed among them is taken as the final shared control code; otherwise, it is 0. Only when the final shared control code is 1 and the shared request digest is consistent, the hardware security module generates a one-time data encryption key.

[0007] Optionally, obtaining standardized sharing request data includes: receiving a sharing request containing a set of medical research data records to be shared and the identifier of the receiving research institution; reading the public key certificate byte sequence of the receiving research institution from the permissioned consortium blockchain based on the receiving research institution identifier, without using the public key certificate byte sequence carried in the external request; parsing the unique identifier, timestamp, identity binding byte sequence, and research content byte sequence of each record according to the medical research data exchange protocol; if the research content byte sequence is empty or the field parsing fails, setting the final sharing control code to 0 and terminating the processing; if the identity binding byte sequence is not empty, identifying the corresponding record as a restricted record; and forming standardized sharing request data from the verified records and the read public key certificate byte sequence.

[0008] Optionally, generating a share request digest includes: arranging records in the normalized share request data in ascending order of timestamps, and arranging them in unsigned byte order of the unique identifiers of the records if the timestamps are the same; concatenating the number of records, the encoding length and full byte encoding of each record, and the encoding length and byte content of the public key certificate byte sequence of the receiving research institution in sequence according to deterministic length encoding rules; performing a cryptographic digest operation on the concatenation result to obtain the share request digest, and writing the share request digest and the number of elements into the sequence header of the two transformed sequences.

[0009] Optionally, generating a sequence of record quantity changes and a sequence of record proportion changes of equal length, each containing at least two elements, includes: arranging records in the shared request data according to timestamps and unique record identifiers to obtain ordered records; calculating adjacent time intervals of the ordered records; if adjacent time intervals cannot be formed, setting the final shared control code to 0 and terminating the process; determining the median of adjacent time intervals and the median absolute deviation of each adjacent time interval from the median, using the sum of the two as the data-driven discontinuity boundary; segmenting the ordered records at positions where adjacent time intervals are strictly greater than the boundary, and not segmenting at positions where the two are equal, to obtain time-continuous record segments; if there are fewer than three time-continuous record segments, setting the final shared control code to 0 and terminating the process.

[0010] Optionally, generating a sequence of record quantity changes and a sequence of restricted-level record proportion changes of equal length, each containing at least two elements, includes: counting the number of records and the number of restricted-level records in each consecutive time segment; dividing the number of restricted-level records by the total number of records to obtain the restricted-level record proportion; dividing the absolute value of the difference between the number of adjacent records by the larger of the two record quantities to obtain the record quantity change amplitude value; using the absolute value of the difference between the proportions of adjacent restricted-level records as the proportion change amplitude value; when the number of records in the later segment is greater than the number of records in the earlier segment, the quantity increase flag value is 1, otherwise it is 0; when the proportion of restricted-level records in the later segment is greater than the proportion of restricted-level records in the earlier segment, the proportion increase flag value is 1, otherwise it is 0; encoding the change amplitude value according to the fixed-point precision and rounding rules of the protocol, and forming two change sequences in chronological order with the corresponding increase flag values.

[0011] Optionally, subtract the median of each change value from the sequence median, and set the negative difference to 0. This includes: copying and arranging the change values ​​of the two change sequences in ascending order; taking the median as the middle value when the number of elements is odd, and taking the arithmetic mean of the two median values ​​as the median when the number of elements is even; subtracting the corresponding median from each change value and setting the negative difference to 0 to obtain the non-negative median difference; when both non-negative median differences at the same position are greater than 0 and the corresponding rising indicator values ​​are both 1, the common median rising indicator value is 1, otherwise it is 0; fixed-point integer arithmetic and rational number arithmetic are used, and binary floating-point arithmetic is not used.

[0012] Optionally, the linear statistical method for the maximum continuous length of the common rise at the original position includes: reading the common super-median rise indicator value sequentially according to the element position; incrementing the current continuous count by 1 when the read value is 1, setting the current continuous count to 0 when the read value is 0, and saving the maximum value of the current continuous count during the reading period; after the reading is completed, using the saved maximum value as the maximum continuous length of the common rise at the original position, and not connecting the end of the sequence with the beginning of the sequence for statistical purposes.

[0013] Optionally, the entire non-zero cyclic shift of the limit level record ratio change sequence is performed, including: forming an indivisible element with each ratio change amplitude value and the corresponding rising flag value, keeping the sequence header and record number change sequence of the two change sequences unchanged; performing left cyclic shifts from shifting 1 element to shifting 1 element less than the number of elements in turn, moving the starting element to the end each time; processing the byte content of different shift results separately if they are the same; obtaining the maximum continuous length of the common rise of a single shift according to the same rule after each shift, and taking the maximum value as the maximum continuous length of the common rise of the non-zero cyclic shift.

[0014] Optionally, the blockchain verification nodes independently recalculate based on the same shared request data, including: each blockchain verification node regenerates the shared request digest and two change sequences, and independently performs median difference processing, in-place linear statistics, all non-zero cyclic shift statistics, and generation of the shared control code to be confirmed; the two independently generated change sequences are checked against the two change sequences submitted by the shared gateway; after the check is consistent, the complete byte encodings of the two change sequences are concatenated according to a fixed sequence order and cryptographic digest operation is performed to obtain the input sequence digest; the shared request digest, the input sequence digest, the two maximum consecutive lengths, and the shared control code to be confirmed are combined to form the complete recalculation result of the node, and the corresponding blockchain verification node generates the node digital signature.

[0015] Optionally, when the number of nodes with identical complete recalculation results reaches the consensus confirmation node count, the unconfirmed shared control code among them is used as the final shared control code; otherwise, it is 0. This includes: reading the total number of blockchain verification nodes, the number of fault-tolerant nodes, and the number of consensus confirmation nodes from the same consensus protocol configuration; verifying the identity of the blockchain verification node and the node digital signature, and deduplicating the complete recalculation results of the node according to the blockchain verification node identifier; treating the complete recalculation results of the node as an indivisible data whole, and grouping them according to whether all fields are identical; confirming the unconfirmed shared control code of the group when the number of valid nodes in the same group reaches the consensus confirmation node count; otherwise, setting the final shared control code to 0.

[0016] Optionally, the hardware security module generates a one-time data encryption key only when the final sharing control code is 1 and the sharing request digest verification is consistent. This includes: re-encoding the sharing request data according to the arrangement and length encoding rules when generating the sharing request digest and calculating and verifying the sharing request digest; when the verification is consistent and the final sharing control code is 1, generating a non-derivative one-time data encryption key within the hardware security module, using this key to authenticate and encrypt the plaintext packet of medical research data, and encrypting the key using the public key in the public key certificate of the receiving research institution and randomization padding; destroying the key and its key handle when key encryption is completed or any encryption failure occurs; and not outputting encrypted delivery data and key ciphertext when any precondition is not met.

[0017] A medical research information sharing system based on keys and blockchain is also provided, comprising: a change sequence generation module for acquiring sharing request data and generating a sharing request summary, a record quantity change sequence, and a restriction level record ratio change sequence; a common rise statistics module for determining the common supermedian rise identifier value and the maximum continuous length of the common rise at the original position; a non-zero cyclic shift statistics module for performing all non-zero cyclic shifts and determining the maximum continuous length of the common rise of non-zero cyclic shifts; a shared control code generation module for comparing two maximum continuous lengths and generating a shared control code to be confirmed; a blockchain recalculation confirmation module for enabling blockchain verification nodes to independently recalculate and determine the final shared control code; and a key generation and encrypted delivery module, including a hardware security module, for generating a one-time data encryption key only when the final shared control code is 1 and the shared request summary is consistent, and completing the encrypted delivery process.

[0018] The beneficial effects of this invention are reflected in:

[0019] This invention uses the sequence of changes in the number of records and the sequence of changes in the proportion of records at the restriction level as deterministic inputs for positional correspondence. It uses the median of the change amplitude values ​​of the two change sequences as internal benchmarks, and obtains the maximum continuous length of the common rise at the original position through non-negative median difference, two rising indicator values, and linear continuous statistics. This process ensures that the common rise position must simultaneously satisfy the condition that both change amplitude values ​​exceed their respective medians and that the change direction is upward, avoiding situations where a large change on one side compensates for no change on the other. Using the median as the internal benchmark for the current request also reduces the direct impact of different request sizes and a small number of extreme change values ​​on the judgment benchmark.

[0020] Based on this, the present invention keeps the sequence of changes in the number of records unchanged, performs all non-zero cyclic shifts on the sequence of changes in the proportion of records at the restriction level, and uses the maximum value among the maximum continuous lengths of the common rise of all single shifts as the maximum continuous length of the common rise of the non-zero cyclic shift. The cyclic shift keeps the numerical distribution and element content of the two change sequences unchanged, only disrupting the original time position correspondence. Therefore, the obtained reference length and the maximum continuous length of the common rise at the original position have the same data source, the same statistical rules, and the same unit of element quantity. The two can be directly compared as integers without the need to introduce artificial risk thresholds, fixed weights, or training models, thereby distinguishing whether the continuous common rise formed at the original time position exceeds the reference result that the current data can form under the non-original position correspondence.

[0021] Furthermore, blockchain verification nodes independently recalculate from the same shared request data, and consensus confirmation is only performed on the complete recalculation results of nodes with identical fields. If consensus is insufficient or recalculation results are inconsistent, the final shared control code is set to 0. The one-time data encryption key is generated by the hardware security module only when the final shared control code is 1 and the shared request digest verification is consistent. Thus, the shared request data, two changing sequences, two consecutive lengths, the final shared control code, and the one-time data encryption key form a recalculated continuous control chain, preventing intermediate results without consistent verification from prematurely triggering key generation, and enabling different verification nodes to reproduce the same results for the same input. Attached Figure Description

[0022] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the accompanying drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. In all the drawings, similar elements or parts are generally identified by similar reference numerals. In the drawings, the elements or parts are not necessarily drawn to scale.

[0023] Figure 1 This is a schematic diagram illustrating the steps of the medical research information sharing method based on keys and blockchain of the present invention;

[0024] Figure 2 This is a schematic diagram of some steps in S1 of the medical research information sharing method based on keys and blockchain of the present invention;

[0025] Figure 3 This is a schematic diagram of some steps in step S2 of the medical research information sharing method based on keys and blockchain of the present invention;

[0026] Figure 4 This is a schematic diagram of the data flow sequence in S3 of the medical research information sharing method based on keys and blockchain of the present invention;

[0027] Figure 5This is a schematic diagram of some steps in S3 of the medical research information sharing method based on keys and blockchain of the present invention;

[0028] Figure 6 This is a schematic diagram of some steps in step S4 of the medical research information sharing method based on keys and blockchain of the present invention;

[0029] Figure 7 This is a schematic diagram of the module structure and data flow of the medical research information sharing system based on keys and blockchain of the present invention. Detailed Implementation

[0030] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0031] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.

[0032] It should be noted that similar labels and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, the terms "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0033] This invention provides a method for sharing medical research information based on keys and blockchain, such as... Figure 1 As shown, in one embodiment, the method includes:

[0034] S1. Receive external sharing request data consisting of a set of medical research data records to be shared and the identifier of the receiving research institution; read the byte sequence of the public key certificate of the receiving research institution from the fixed block state that has been finally confirmed in the permissioned consortium blockchain; complete record verification, certificate verification, normalization encoding and sharing request digest generation; generate no less than 3 time-continuous record segments according to adjacent time intervals; and generate a record quantity change sequence and a restricted record ratio change sequence with the same number of elements and no less than 2 according to adjacent time-continuous record segments.

[0035] S2. Obtain the non-negative median difference from the median of the change amplitude values ​​of the two change sequences respectively. Generate a common super-median rising indicator value based on the two non-negative median differences and two rising indicator values ​​at the same element position. Linearly calculate the maximum continuous length of the common rising at the original position from the first element position to the last element position.

[0036] S3. Keep the sequence of changes in the number of records unchanged, perform all non-zero left circular shifts on the sequence of changes in the proportion of records at the restriction level, linearly calculate the maximum continuous length of the common rise of each shift, and determine the maximum value of the common rise of the non-zero circular shift as the maximum continuous length of the common rise of the non-zero circular shift; if the maximum continuous length of the common rise of the original position is greater than the maximum continuous length of the common rise of the non-zero circular shift, set the value of the shared control code to be confirmed to 0; otherwise, set the value of the shared control code to be confirmed to 1.

[0037] S4. Enable blockchain verification nodes to independently recalculate from the same shared request data; when the number of consensus confirmation nodes reaches the number of complete recalculation results of the same nodes, determine the final shared control code as the same unconfirmed shared control code and generate blockchain verification data; otherwise, set the final shared control code to 0 and generate blockchain abnormal verification data; only when the final shared control code is 1 and the shared request digest verification is consistent, enable the hardware security module to generate a one-time data encryption key, complete the medical research data authentication encryption and one-time data encryption key public key encryption, and publish the encrypted delivery data and key ciphertext after the transaction registration on the permissioned consortium blockchain reaches the final confirmation state.

[0038] In this embodiment, the external sharing request data is the input data submitted by the sharing initiator to the sharing gateway, consisting of a set of medical research data records to be shared and an identifier of the receiving research institution. The external sharing request data does not contain a trusted public key certificate byte sequence of the receiving research institution; when the external payload is accompanied by a public key certificate, the sharing gateway does not use that public key certificate.

[0039] Furthermore, the shared request data is structured data generated after the shared gateway completes field verification, certificate reading, and certificate verification. It includes the medical research data exchange protocol version, certificate status reference block height, recipient research institution identifier, ordered set of medical research data records to be shared, certificate registration version, certificate serial number, and the recipient research institution's public key certificate byte sequence. The certificate status reference block height is the latest available block height that has reached the final confirmation state, read from the permissioned consortium blockchain when the shared gateway accepts external shared request data. The normalized shared request byte sequence is a unique byte sequence obtained by encoding the shared request data according to a fixed field order, length prefix, and byte order.

[0040] Furthermore, the identity association field byte sequence is used to store field content that can directly identify the research subject or restore the identity relationship through controlled mapping. The research content field byte sequence is used to store the medical research content to be delivered in this research sharing. Medical research data records to be shared that have a non-empty identity association field byte sequence are identified as restricted-level medical research data records; medical research data records to be shared that have an empty identity association field byte sequence are identified as medical research data records without an identity association field. A medical research data record without an identity association field only indicates that the identity association field specified in the protocol is empty, and does not indicate that the research content field has undergone substantial anonymization processing beyond the scope of the protocol's field checks.

[0041] Furthermore, the time interval segmentation boundary is the record segmentation boundary obtained by adding the median of adjacent time intervals to the median of the absolute deviation of the time intervals. A time-continuous recording segment is a recording segment formed after segmenting an ordered set of medical research data records to be shared at positions where adjacent time intervals are strictly greater than the time interval segmentation boundary. The aforementioned names directly reflect the processing object and the processing result, avoiding the use of names that are prone to different interpretations, such as "data-driven discontinuous boundary" or "continuous update segment."

[0042] Furthermore, the sequence of changes in the number of records is arranged in chronological order according to the consecutive record segments at adjacent times, with the integer value of the change in the number of records and the value of the increase in the number of records. The sequence of changes in the proportion of records at the restriction level is arranged in the same order with the integer value of the change in the proportion of records at the restriction level and the value of the increase in the proportion of records at the restriction level. The same element position in the two sequences always corresponds to the same pair of consecutive record segments at adjacent times.

[0043] Furthermore, the common supermedian difference is the smaller of the non-negative median difference in the number of records at the same element position and the non-negative median difference in the proportion of records in the restricted level. A common supermedian rise indicator value of 1 indicates that the common supermedian difference is greater than 0, and both the record number rise indicator value and the restricted level record proportion rise indicator value are 1; otherwise, the common supermedian rise indicator value is 0.

[0044] Furthermore, the maximum consecutive length of the common rise at the original position is the maximum number of elements whose common midpoint rise flag value is consecutively 1, given the original positional correspondence of the two changed sequences without cyclic shifting. The maximum consecutive length of the common rise at a single shift is the maximum number of elements whose common midpoint rise flag value is consecutively 1, given the positional correspondence formed by a single non-zero left cyclic shift. The maximum consecutive length of the common rise at a non-zero cyclic shift is the maximum value among all the maximum consecutive lengths of the common rise at a single shift. All the aforementioned consecutive lengths are in units of the number of elements in the changed sequence, and do not represent time length or byte length.

[0045] Furthermore, the pending shared control code is binary control data generated based on the comparison results of two consecutive lengths before blockchain consensus confirmation. The final shared control code is binary control data formed after the blockchain verification nodes complete recalculation and consensus confirmation. When both the pending and final shared control codes are 0, it indicates that the one-time data encryption key generation process is prohibited; when they are 1, it indicates that the digest verification process before the one-time data encryption key generation is allowed. A value of 1 does not directly replace shared request digest verification, certificate verification, or encryption process verification.

[0046] Furthermore, the complete recalculation result of a node consists of the shared request digest, input sequence digest, maximum consecutive length of common increase at the original position, maximum consecutive length of common increase with non-zero cyclic shift, the shared control code to be confirmed, and the consensus configuration version, all independently obtained by the blockchain verification node. Blockchain verification data is normalized data consisting of the complete recalculation result of the same node that has reached the required number of consensus confirmation nodes, along with the confirmation node identifier and node signature. Blockchain anomaly verification data is normalized data consisting of the failure reason code, relevant input digest, consensus configuration version, verified node signature, and the final shared control code with a value of 0, generated when input verification fails or the required number of consensus confirmation nodes is not reached.

[0047] Furthermore, the time interval segmentation boundary is directly calculated from adjacent time intervals in the current shared request data, the maximum continuous length of the non-zero cyclic shift common rise is directly calculated from all non-zero left cyclic shift results of the current two change sequences, and the unconfirmed shared control code is generated by a deterministic comparison of two continuous lengths. The same shared request data, protocol version, certificate status reference block height, and consensus configuration version can produce the same intermediate data and final results.

[0048] In this embodiment, it should be noted that in S1, the external sharing request data may have issues such as missing fields, inconsistencies between the length field and the actual number of bytes, duplicate record unique identifiers, empty research content fields, incorrect certificate pointers, or replaced external certificates. The sharing gateway converts the external sharing request data into shared request data that can be repeatedly processed by different computing nodes through deterministic parsing, on-chain trusted certificate reading, and normalized encoding.

[0049] Furthermore, the shared gateway calculates the time interval segmentation boundary based on adjacent time intervals in the ordered set of medical research data records to be shared, and segments records only where adjacent time intervals are strictly greater than the time interval segmentation boundary. The resulting continuous time record segment depends on the timestamp distribution in the current request and does not rely on manually set business time thresholds.

[0050] In S2, the system uses the median of the change in the number of records and the median of the change in the proportion of records at the limit level as its respective internal benchmarks. The common median rise indicator is set to 1 only when both change values ​​at the same element position exceed their respective medians and both changes are in an upward direction. This process avoids any single-sided change directly determining the continuous statistical results.

[0051] Furthermore, the system performs a linear scan from the beginning to the end according to the element positions. The scan stops immediately upon reaching the end of the sequence, without connecting the beginning and end into a circular continuous interval. The resulting maximum continuous length of the original positions rising together has a clear meaning regarding the number of elements.

[0052] In S3, the system keeps the sequence of record quantity changes unchanged, and only performs a full non-zero left circular shift on the element area of ​​the sequence of limit-level record proportion changes. The full non-zero left circular shift keeps the byte content and circular arrangement order of each data sequence element unchanged, and only changes the element position correspondence between the two changed sequences.

[0053] Furthermore, the maximum value among all single-shift common-rise maximum consecutive lengths is used to form a non-original position reference for the current request itself. This reference has the same data unit as the original position common-rise maximum consecutive length, thus enabling direct integer comparisons without the need to set additional risk thresholds, weighting coefficients, or expert scores.

[0054] In S4, blockchain validator nodes do not directly trust the two consecutive lengths and the unconfirmed shared control code submitted by the shared gateway. Instead, they perform end-to-end independent recalculation starting from the shared request data. Consensus processing only counts the complete recalculation results from nodes that are from different valid nodes, have passed signature verification, and have all result fields identical.

[0055] Furthermore, the final shared control code and the verification shared request digest jointly control the key generation authorization of the hardware security module. The encrypted delivery data and key ciphertext remain unpublishable until the transaction registered on the permissioned consortium blockchain reaches final confirmation, establishing a continuous control relationship between shared judgment, consensus confirmation, key generation, and delivery publication.

[0056] In summary, the entire key-based and blockchain-based medical research information sharing method firstly generates shared request data through field verification, on-chain certificate reading, deterministic sorting, and normalized encoding. Simultaneously, it generates time interval segmentation boundaries and continuous time record segments based on adjacent time intervals in the current request, and generates two position-to-position corresponding change sequences from these adjacent continuous time record segments. Further, it generates a common supermedian rising identifier value and the maximum continuous length of the common rise at the original position using the median of each of the two change sequences as internal benchmarks, and then obtains the maximum continuous length of the common rise with non-zero cyclic shifts through all non-zero left cyclic shifts. Based on these two continuous lengths, it generates a shared control code to be confirmed, which is then recalculated end-to-end by the blockchain verification nodes to form the final shared control code. Finally, only when the final shared control code is 1 and the shared request digest verification is consistent is the hardware security module allowed to generate a one-time data encryption key, and the encrypted delivery result is formed through authentication encryption, public key encryption, digest registration, and delayed release after final confirmation.

[0057] In one implementation, such as Figure 2 As shown, S1 includes:

[0058] S11. Receive external sharing request data, parse and verify the medical research data record to be shared according to the medical research data exchange protocol, determine the restricted medical research data record, and read and verify the public key certificate byte sequence of the receiving research institution from the fixed block state of the permissioned consortium blockchain.

[0059] S12. Arrange the medical research data records to be shared in a deterministic order, perform normalized encoding on the records, the identifier of the receiving research institution, and the fixed certificate information, and generate a normalized sharing request byte sequence and a sharing request digest.

[0060] S13. Generate time interval segmentation boundaries based on adjacent time intervals in the ordered set of medical research data records to be shared, and segment the records at positions where adjacent time intervals are strictly greater than the time interval segmentation boundaries to obtain continuous time record segments.

[0061] S14. Calculate the number of records in each continuous recording segment and the number of restricted medical research data records, and generate a sequence of changes in the number of records and a sequence of changes in the proportion of restricted records.

[0062] In this embodiment, it should be noted that in S11, the external sharing request data consists of a set of medical research data records to be shared and the identifier of the receiving research institution. The identifier of the receiving research institution is assigned by the permissioned consortium blockchain member registration process and remains unique in the member registration status, and is not temporarily generated by the sharing request initiator. The sharing gateway first verifies the member status and medical research data receiving permissions corresponding to the identifier of the receiving research institution, and then reads the corresponding certificate. For example, if the permissioned consortium blockchain registers 4 research institutions and each research institution has a different identifier, and the external sharing request data specifies the identifier of the second research institution, it can only read the valid certificate under that institution's name; if the identifier does not exist, points to multiple members, or the member status is invalid, the system enters an abnormal blocking branch.

[0063] Each record of medical research data to be shared contains, in sequence, a unique record identifier, a timestamp, the length of the identity-related field encoding, the byte sequence of the identity-related field, the length of the research content field encoding, and the byte sequence of the research content field. The unique record identifier occupies 16 bytes, while the timestamp and the lengths of each variable-length field each occupy 8 bytes. The timestamp uses unsigned big-endian order and records the cumulative number of seconds since Coordinated Universal Time (UTC) on January 1, 1970, with a time resolution of 1 second.

[0064] The timestamp epoch, time resolution, and field length are fixed by the version of the medical research data exchange protocol. Each shared gateway and blockchain verification node reads the same version of the protocol configuration from the permissioned consortium blockchain and does not adjust it based on a single request. Coordinated Universal Time (UTC) seconds are used to avoid differences in local time zones and calendar formats. For example, if two records have the same timestamp field value, the adjacent time interval is directly determined to be 0 seconds, and the system does not artificially add a time difference. When an unknown protocol version or a field length that does not conform to the current protocol version is received, the system enters an abnormal blocking branch.

[0065] The parser moves the parsing cursor sequentially by field, starting from the first byte of each record. For fixed-length fields, the parser must retrieve the full specified number of bytes. Before reading variable-length fields, the parser first interprets the corresponding 8-byte length field as an unsigned big-endian integer, checks that the length does not exceed the remaining number of bytes in the record, and then reads the equal-length bytes. After all fields have been read, the parsing cursor must be exactly at the end of the record. Record parsing fails if there is a length arithmetic overflow, field out-of-bounds error, a discrepancy between the actual number of bytes and the length field, or the presence of unresolved trailing bytes.

[0066] The identity-related field byte sequence is extracted by the parser according to the field directory of the medical research data exchange protocol. The field directory lists patient identifiers, medical record identifiers, and reversible mapping tokens that can directly identify a natural person or restore identity relationships through controlled mapping as identity-related fields. The parser extracts fields based on field type identifiers, without using keyword matching or manual judgment. For example, if a record contains one medical record identifier field and three research observation fields, the medical record identifier field enters the identity-related field byte sequence, and the three research observation fields enter the research content field byte sequence.

[0067] The byte sequence of the research content field is composed of fields from the protocol field directory that are permitted for research analysis, including diagnostic observations, test results, and research indicators, arranged in a fixed order. The non-empty check verifies both that the research content field's encoded length is greater than 0 and that at least one research field within that encoded length exists and can be parsed according to the protocol. Data containing only padding bytes, unknown fields, or unparseable fields will fail the non-empty check. For example, a research content field with an encoded length of 8 bytes that can be parsed to yield one valid test field passes the check; a field with an encoded length of 8 bytes but entirely composed of undefined padding bytes will enter an anomaly blocking branch.

[0068] Whether the encoding length of the identity-associated field is greater than 0 is a binary condition formed by the protocol field structure, not a business threshold set based on historical samples. When the encoding length of the identity-associated field is greater than 0, the corresponding record is identified as a restricted-level medical research data record; when the encoding length of the identity-associated field is equal to 0, it is also necessary to check whether the identity-associated field listed in the field directory does not exist in the research content field area. If the check passes, it is identified as a medical research data record without an identity-associated field. For example, if the encoding length of the identity-associated field is 2 bytes, it is identified as a restricted-level medical research data record; if the encoding length is 0 but a medical record identifier field appears in the research content field area, the system will still enter the abnormal blocking branch.

[0069] The system checks whether the unique identifier of the record is duplicated, whether the research content field is empty, whether the field type conforms to the protocol directory, and whether the externally shared request data contains undefined fields. If any record fails the check, the system does not retain part of the parsing results, does not generate two change sequences, and terminates subsequent calculations. This failure status is then written to the blockchain anomaly verification data, and the final shared control code value is 0.

[0070] When accepting external data sharing requests, the shared gateway reads the latest available block in the permissioned consortium blockchain that has reached the final confirmation state and fixes the corresponding block height to the certificate status reference block height. Based on the recipient's research institution identifier, the shared gateway reads the certificate registration version, certificate serial number, certificate status, and the recipient's research institution's public key certificate byte sequence from this fixed block status. Subsequent digest verification and public key encryption continue to use this fixed certificate, without selecting a new certificate added during processing.

[0071] The receiving research institution's public key certificate uses DER encoding of the X.509 certificate. The shared gateway verifies the certificate signature chain, the trust root registered in the consortium blockchain, the certificate validity period corresponding to the fixed block time, the revocation status, the institution identifier binding relationship, the purpose of key encryption, the public key algorithm, and the public key modulus length. The basic processing structure of X.509 certificates and revocation information is consistent with the certificate and revocation list model described in RFC 5280.

[0072] When multiple certificates are valid simultaneously, the shared gateway first excludes certificates that are not active on the blockchain, and then arranges them in order of their effective time from latest to earliest. If the effective times are the same, the first certificate is selected according to the dictionary order of the unsigned bytes of the certificate sequence number. For example, if a research institution has registered two certificates, one of which has been revoked and the other is active, only the active certificate is fixed; if both certificates are active but have different effective times, the certificate with the later effective time is fixed.

[0073] The certificate public key algorithm and modulus length are fixed by the versioned cryptographic algorithm suite configuration. Before the configuration is released, interoperability tests are performed on the cryptographic libraries, hardware security modules, and receiver decryption implementations supported by participating organizations to perform certificate parsing, public key encryption, and private key decryption. This implementation uses a 3072-bit RSA public key, which is longer than the minimum acceptable length commonly used in current key transmission schemes; the corresponding choice is consistent with the NIST SP800-131A Revision 2 guidelines regarding the acceptability of RSA key transmission schemes with a length of not less than 2048 bits. For example, if Algorithm Suite Version 1 only allows 3072-bit RSA public keys, a certificate containing a 2048-bit public key does not meet the configuration requirements of that version, and the system will not automatically reduce the public key parameters.

[0074] The fixed field parameters of the medical research data exchange protocol are jointly published by the participating institutions of the permissioned consortium blockchain and locked through the protocol version number. Before publication, interoperability tests are performed using no fewer than two independent parsing implementations, covering minimum record size, maximum allowed record size, empty identity association field, non-empty research content field, identical timestamps, illegal trailing bytes, and length overflow scenarios. For example, protocol version 1 has a fixed record unique identifier of 16 bytes, timestamp and length fields of 8 bytes, and ascending flag field of 1 byte. Only when all implementations produce the same parsing result for the same valid input and the same blocking result for the same illegal input will the protocol version be written into the permissioned consortium blockchain and take effect.

[0075] To prevent the amount of data that the length field can represent from exceeding the actual processing capacity of the device, the protocol configuration also includes a request resource reception limit. This limit is determined through a limited number of load tests and is not involved in the shared control code calculation. The tests progressively increase the number of records, the length of a single record, and the total plaintext packet length from the expected business load, recording the peak memory usage during parsing, encryption time, and the processing results of the hardware security module. Then, an upper limit that can stably complete the processing with sufficient resource margin is selected. For example, if the tests confirm that the system can stably process 1000 records, with a single record not exceeding 1 MiB and a plaintext packet for medical research data not exceeding 1 GiB, the aforementioned values ​​can be written into the protocol version configuration; if the current request exceeds any of the upper limits, it will directly enter the abnormal blocking branch.

[0076] Furthermore, in S12, the shared gateway arranges the medical research data records to be shared in chronological order according to their timestamps. When timestamps are the same, they are arranged according to the dictionary order of the unsigned bytes of the record's unique identifier. The comparison of the record's unique identifier starts from the first byte, with each byte interpreted as an unsigned integer from 0 to 255; when the first different byte is encountered, the record with the smaller byte value is listed first. The system does not interpret the record's unique identifier as a signed integer, text string, or local byte order value.

[0077] For example, if two records have the same first three bytes and their fourth bytes are 2 and 3 respectively, the record with the fourth byte being 2 will be listed first. Since duplicate records are prevented from having unique identifiers before sorting, there are no situations where identical complete identifiers necessitate further order determination. The sorting process only changes the position of record references within the ordered set; it does not rewrite the record field content.

[0078] The normalized encoder regenerates a unique byte representation for fields that pass verification, without directly copying external payloads that may contain extra padding or non-normalized length representations. The encoder sequentially writes the protocol version, certificate status reference block height, recipient research institution identifier encoding length and identifier bytes, number of records, encoding length of each record and complete normalized record bytes, certificate registration version, certificate serial number encoding length and certificate serial number bytes, certificate encoding length, and the recipient research institution public key certificate byte sequence. Integer and length fields use unsigned big-endian order, and no spaces, newlines, or memory alignment bytes are added between fields.

[0079] For example, when the shared request data contains two records, the encoder first writes the protocol version, certificate status reference block height, recipient research institution identifier, and number of records. Then, it sequentially writes the encoded length and normalized bytes of the first and second records. Finally, it writes the certificate registration version, certificate serial number, and certificate bytes. If any length cannot be represented by a protocol field, the system does not perform truncation, modulo operation, or local object serialization.

[0080] The shared request digest uses the SHA-256 digest algorithm specified in the protocol's cryptographic algorithm suite to process the normalized shared request byte sequence, and the output is saved as a 32-byte raw digest. The system does not convert the digest to hexadecimal text, add a salt or newline, or perform character encoding again on the normalized shared request byte sequence. The shared request digest also binds the record content, record order, recipient research institution identifier, certificate status reference block height, certificate version, and protocol version.

[0081] The digest algorithm is fixed by the version of the cryptographic algorithm suite and undergoes known answer testing, empty input testing, long and short input testing, single-byte modification testing, and multi-implementation interoperability testing before release. For example, when the same normalized shared request byte sequence is processed by a shared gateway implementation and two blockchain verification nodes, the corresponding algorithm suite is only allowed to enter the enabled state if all three implementations output the same 32-byte digest. If the algorithm suite is unsupported or the digest output length is not 32 bytes, the system enters an abnormal blocking branch.

[0082] In S13, the shared gateway calculates the timestamp difference between two adjacent records sequentially according to their original positions in the ordered set of medical research data records to be shared, thus obtaining the adjacent time interval. Adjacent time intervals of 0s with the same timestamp are considered valid values. Since the timestamps are already arranged in ascending order, adjacent time intervals will not be negative; if an integer overflow or wraparound occurs during subtraction, the system enters an abnormal blocking branch.

[0083] Forming adjacent time intervals requires at least two records, and forming a change sequence capable of performing non-zero cyclic shifts requires at least three consecutive time record segments, ensuring that each change sequence has at least two elements. These quantities are directly determined by the adjacency relationship and the structural requirements of non-zero cyclic shifts, and are not empirical thresholds. For example, if a request contains four records, but only two consecutive time record segments are obtained after segmentation, only one change sequence element can be formed, and the system will not proceed to the common supermedian rise calculation.

[0084] The shared gateway replicates all adjacent time intervals and sorts the numerical copies in ascending order, while maintaining the original correspondence between adjacent time intervals and record boundaries. When the number of adjacent time intervals is odd, the median value in the ascending copy is selected as the median of the adjacent time intervals; when the number of adjacent time intervals is even, the arithmetic mean of the paired median values ​​is selected as the median of the adjacent time intervals.

[0085] The shared gateway calculates the absolute deviation of each adjacent time interval from the median of those adjacent time intervals, and determines the median of the absolute deviations according to the same median rule. The median of adjacent time intervals, the absolute deviation of time intervals, and the time interval splitting boundaries are all stored as integers or rational numbers consisting of an integer numerator and a positive integer denominator; they are not converted to binary floating-point numbers, nor are intermediate rounding performed. The comparator performs rational number comparisons by cross-multiplying integers.

[0086] For example, when adjacent time intervals are 10s, 11s, 30s, and 31s, the median of adjacent time intervals is 20.5s, the median absolute deviation of the time intervals is 10s, and the time interval split boundary is 30.5s. The system only performs splitting at the original record boundary corresponding to 31s. All decimals in this example do not exceed one decimal place.

[0087] The shared gateway returns to the original adjacent time interval position and segments records only when the adjacent time interval is strictly greater than the time interval segmentation boundary; it does not segment when the adjacent time interval is equal to the time interval segmentation boundary. When the segmentation condition is met between the j-th record and the next record, the previous continuous time record segment ends at the j-th record, and the next continuous time record segment begins at the next record. Each record belongs to only one continuous time record segment, with no repetition and no omission.

[0088] The time interval segmentation boundary is calculated entirely from adjacent time intervals within the current request; there is no time threshold that needs to be set using historical data. The median of adjacent time intervals reflects the central write interval within the current request, while the median absolute deviation of time intervals reflects the degree of deviation of adjacent time intervals from the median. Both values ​​have the same time unit and can be directly added and compared to adjacent time intervals.

[0089] In S14, the shared gateway counts records one by one according to their position in the continuous time recording segment, with each record counted only once in its respective continuous time recording segment. Records whose identity association field byte sequence is not empty and whose field directory verification passes are counted in the number of restricted-level medical research data records in the corresponding continuous time recording segment. Each continuous time recording segment contains at least one record, therefore, there is no case where the divisor is zero when the number of restricted-level medical research data records is divided by the number of records in the same segment.

[0090] The proportion of restricted-level records is precisely stored using the number of restricted-level medical research data records in a continuous time segment as the numerator and the number of records in that continuous time segment as the positive integer denominator. The absolute difference between adjacent restricted-level record proportions and the range of change in the number of records are also stored as integer numerators and positive integer denominators before final quantization, without binary floating-point conversion or intermediate rounding.

[0091] For each pair of consecutive recording segments at adjacent times, the shared gateway obtains the absolute difference between the two record counts and divides this absolute difference by the larger of the two record counts to obtain the quantified change in the record count. When the record count of the later consecutive recording segment is significantly greater than the record count of the earlier consecutive recording segment, the record count increase flag is set to 1; otherwise, it is set to 0.

[0092] For example, if two consecutive time segments contain 2 and 4 records respectively, the absolute difference in the number of records is 2, the larger number of records is 4, the quantization range of the number of records is 0.5, and the record count increase indicator is 1. If both consecutive time segments contain 4 records, both the quantization range of the number of records and the record count increase indicator are 0.

[0093] The shared gateway obtains the absolute value of the difference between the two restriction level recording ratios of consecutive recording segments in adjacent time periods, thus obtaining the quantified change range value of the restriction level recording ratio. When the restriction level recording ratio of the later consecutive recording segment is significantly greater than that of the earlier consecutive recording segment, the restriction level recording ratio increase flag is set to 1; otherwise, it is set to 0. The ratio comparison uses integer cross-multiplication results, without setting any tolerance for approximate equality.

[0094] For example, when the restricted recording ratios of consecutive recording segments in adjacent time periods are 0.25 and 0.5 respectively, the unquantized change value of the restricted recording ratio is 0.25, and the value of the increase indicator of the restricted recording ratio is 1; when both restricted recording ratios are 0.5, the change value and the increase indicator value are both 0.

[0095] The decimal fixed-point precision and rounding rules are fixed by the protocol version and undergo deterministic and sensitivity testing using limited representative data before the protocol is released. The tests use candidate precisions of 1 and 2 decimal places to process the same precision ratio, comparing the integer variation amplitude, median, common supermedian rising indicator value, and continuous length generated by each implementation. Under the premise that the uniform integer width can accommodate this, the candidate precision that reduces quantization errors and ensures complete consistency across implementations is selected. This implementation selects 2 decimal places and a decimal rounding rule. For example, when the precision value is obtained by dividing 1 by 3, the quantization result is 0.33; when the precision value is obtained by dividing 21 by 40, the quantization result is 0.53. All the aforementioned decimals do not exceed 2 decimal places.

[0096] The quantized logical values ​​are called the record quantity change range value and the limit level record ratio change range value. The stored integers obtained by converting the logical values ​​according to the decimal scaling scale of 100 are called the record quantity change range integer and the limit level record ratio change range integer, respectively. For example, the record quantity change range value of 0.5 is encoded as the integer 50, and the limit level record ratio change range value of 0.3 is encoded as the integer 30. During the calculation process, they are interpreted into corresponding logical values ​​according to the same scale.

[0097] Each data sequence element of the record quantity change sequence contains an 8-byte integer representing the change in record quantity and a 1-byte record quantity increase flag. Each data sequence element of the limit-level record ratio change sequence contains an 8-byte integer representing the change in limit-level record ratio and a 1-byte limit-level record ratio increase flag. The increase flag field can only be 0 or 1.

[0098] Both variant sequences have a 32-byte shared request digest and an 8-byte element count in their sequence headers, with no padding bytes. The element count field must match the actual number of bytes in the element area. For example, if the element count is 4, each variant sequence contains a 40-byte sequence header and a 36-byte element area, totaling 76 bytes; if the element count field is 4 but there are only 3 data sequence elements, the entire variant sequence is invalid.

[0099] In one implementation, such as Figure 3 As shown, S2 includes:

[0100] S21. Determine the median of the change in the number of records and the median of the change in the proportion of records at the restricted level, and determine the non-negative median difference of the number of records, the non-negative median difference of the proportion of records at the restricted level, and the common over-median difference for each element position.

[0101] S22. Generate a common supermedian rise indicator value based on the common supermedian difference value of the same element position, the record number rise indicator value, and the restriction level record proportion rise indicator value.

[0102] S23. Based on the element position, linearly scan the common super-median rising indicator value from the beginning to the end to determine the maximum continuous length of the common rising at the original position.

[0103] In this embodiment, it should be noted that in S21, the system first compares the shared request digest and the number of elements in the headers of the two change sequences, and checks that the number of elements is not less than 2. The system calculates the number of bytes that the element area should have based on the number of elements, and checks that the complete change sequence does not have any missing fields, out-of-bounds errors, or trailing bytes; each change amplitude integer must be interpretable as a logical value not less than 0 and not greater than 1 according to the scaling scale of 100, and each rising flag field can only take the value 0 or 1.

[0104] The system copies the change range values ​​for the number of records and the change range values ​​for the proportion of records at the limit level, respectively. The copies are then sorted in ascending order without altering the element positions or ascending flags in the original change sequence. When the number of elements is odd, the median is selected from the middle value of the ascending copies; when the number of elements is even, the arithmetic mean of the paired medians is selected. Even-numbered medians are stored using an integer numerator and a positive integer denominator, without performing binary floating-point operations.

[0105] The system subtracts the median of the change in the number of records from the change in the number of records for each value, obtaining the median difference in the change in the number of records. Negative median differences in the change in the number of records are replaced with 0 to obtain a non-negative median difference in the number of records. Similarly, the system subtracts the median of the change in the proportion of records at each restriction level from the change in the proportion of records at that restriction level, obtaining the median difference in the proportion of records at that restriction level. Negative median differences in the proportion of records at that restriction level are replaced with 0 to obtain a non-negative median difference in the proportion of records at that restriction level.

[0106] The smaller of the non-negative median difference in the number of records at the same element position and the non-negative median difference in the proportion of records at the restriction level is determined as the common supermedian difference. The common supermedian difference can be expressed as:

[0107]

[0108] In the above expression, Indicates the first The common supermedian difference of each element position; This indicates the positional index of elements in two consecutive record segments at adjacent times that correspond to each other in the time sequence of two change sequences. Indicates the first The integer value representing the change in the number of records at each element position, interpreted according to a unified decimal fixed-point scale. Indicates the first The integer value of the limit level record ratio change range for each element position is interpreted according to the unified decimal fixed point scale. This represents a sequence of all record quantity variation values ​​arranged in order of element position; This represents a sequence of all limit level records showing proportional changes in value, arranged in the order of their element positions. This represents median operations; This indicates that the larger of the two input values ​​is selected; This indicates selecting the smaller of the two input values; 0 indicates the lower boundary of the non-negative median difference; subscript Indicates the position of the current element.

[0109] In this embodiment, the calculation logic of the expression is as follows: First, determine the median of the change amplitude values ​​of the two change sequences respectively; then, subtract the corresponding median from each change amplitude value, and replace negative median differences with 0; finally, select the smaller value from the two non-negative median differences at the same element position. The change amplitude values ​​in the expression are all deterministic logical values ​​after quantization, and the original division results before quantization are no longer read.

[0110] The reason for using this expression is that the smaller of the two non-negative median differences is selected so that when neither side exceeds its own median, the common median difference is 0, and a larger change on one side cannot compensate for the situation where the other side does not exceed the median.

[0111] For example, the change in record count values ​​are 0.5, 0.5, 0, and 0 respectively, and the change in ascending copy values ​​is 0, 0, 0.5, and 0.5 respectively, with a median of 0.25. The change in the proportion of restricted records is 0.3, 0, 0, and 0 respectively, and the change in ascending copy values ​​is 0, 0, 0, and 0.3 respectively, with a median of 0. The non-negative median difference in record count at the first element position is 0.25, the non-negative median difference in the proportion of restricted records is 0.3, and the common median difference is 0.25; the common median difference at all other element positions is 0.

[0112] Furthermore, in S22, when the common supermedian difference is greater than 0, and both the record quantity increase flag and the limit level record proportion increase flag are 1, the common supermedian increase flag is set to 1; otherwise, the common supermedian increase flag is set to 0. The system does not set intermediate direction parameters with redundant meanings.

[0113] In the example above, the common supermedian difference at the first element position is 0.25, and both rising indicator values ​​are 1, therefore the first common supermedian rising indicator value is 1. The common supermedian difference at the second element position is 0, so even though the record count rising indicator value is 1, the common supermedian rising indicator value is still 0. The final common supermedian rising indicator values ​​are 1, 0, 0, and 0, respectively.

[0114] In S23, the system initializes the current consecutive count and the maximum recorded consecutive count to 0, and then linearly reads the common super-median rising flag value starting from the first element position. When the read value is 1, the current consecutive count is incremented by 1; when the read value is 0, the current consecutive count is reset to zero. After each update, the system retains the larger of the current consecutive count and the maximum recorded consecutive count. The scan terminates after reading the last element, and the position of the last element is not concatenated with the position of the first element for statistical analysis.

[0115] For example, when the common supermedian rising indicator values ​​are 1, 0, and 1 in sequence, the maximum continuous length of the common rising at the original position is 1. The two values ​​of 1 at the beginning and end cannot be combined into a continuous length of 2. In the aforementioned 4-element example, the common supermedian rising indicator values ​​are 1, 0, 0, and 0 in sequence, therefore the maximum continuous length of the common rising at the original position is 1.

[0116] In one implementation, such as Figure 4 and Figure 5 As shown, S3 includes:

[0117] S31. Keeping the sequence heads of the record quantity change sequence and the two change sequences unchanged, treat each data sequence element in the limit level record ratio change sequence as a whole, and generate all non-zero left circular shifted arrangements in a determined direction.

[0118] S32. Arrange each non-zero left circular shift and record the sequence of changes in the number of records according to the corresponding element positions, determine the common super-median difference and the common super-median rise indicator value in sequence, and obtain the maximum continuous length of the single shift common rise corresponding to each shift through linear scanning.

[0119] S33. Select the maximum value from all single shift common rise maximum continuous lengths as the non-zero cyclic shift common rise maximum continuous length, and generate the unconfirmed shared control code based on the comparison result of the two continuous lengths.

[0120] In this embodiment, it should be noted that in S31, the integer representing the change in the restriction level record ratio and the immediately following 1-byte restriction level record ratio increase flag are always moved as a whole as the same data sequence element. The shared request digest and element number in the sequence header do not participate in the movement, and the sequence header and element area of ​​the record number change sequence remain unchanged.

[0121] The direction and order of the cyclic shifts are fixed by the version of the medical research data exchange protocol and are not temporarily selected by the shared gateway or verification node. Each time the left cyclic shift moves one element position, the first element of the current data sequence is moved to the end, and the remaining elements of the data sequence are moved towards the beginning in sequence. The system generates permutations with one element position shifted, two element positions shifted, and so on, until all permutations have been shifted by one fewer element position than the total number of elements in the data sequence.

[0122] Each data sequence element retains its original position number, and the circular shift amount is not merged or prematurely terminated because different elements have the same byte content. For example, when there are 4 elements, regardless of whether there are data sequence elements with the same content, 3 non-zero left circular shifts are performed; the original first data sequence element is moved 1 element position and is now at the fourth element position.

[0123] Furthermore, in S32, each non-zero left circular shift performs the same median difference processing, common supermedian rising flag value generation, and linear continuous length statistics as the original position calculation. The circular shift does not change the set of limit-level record proportion change values, therefore the median of the limit-level record proportion change values ​​remains unchanged; the shared gateway and each blockchain verification node still read the median verified by consistency according to the same processing stage.

[0124] The consecutive length after each shift is still counted according to the linear sequence. When the common super-median rising indicator value is 1, the current consecutive count is incremented by 1; when it is 0, the current consecutive count is reset to zero. Scanning stops when the last element is reached, and the end and beginning of the sequence are not connected. When all common super-median rising indicators are 0, the maximum valid consecutive length of the corresponding single shift common rise is 0.

[0125] In S33, the system selects the maximum value among all single shifts with the largest continuous length of common rise as the maximum continuous length of common rise of non-zero cyclic shifts. If a shift fails input validation or is not completed, the corresponding result is marked as not generated and enters the abnormal blocking branch. The not-generated state cannot be replaced by a valid value of 0.

[0126] The system sets the value of the shared control code to 0 only when the maximum continuous length of the common rise at the original position is strictly greater than the maximum continuous length of the common rise at the non-zero cyclic shift; otherwise, it sets the value of the shared control code to 1. For example, when the two continuous lengths are 2 and 1 respectively, the value of the shared control code to be confirmed is 0; when the two continuous lengths are both 1, the value of the shared control code to be confirmed is 1.

[0127] In one implementation, such as Figure 6 As shown, S4 includes:

[0128] S41. Enable each blockchain verification node to read shared request data, certificate status reference block height, protocol version, and consensus configuration version, independently verify inputs, and generate complete node recalculation results.

[0129] S42. Verify the node identity, digital signature, consensus configuration version, and all result fields of the complete recalculation results of each node, deduplicate the complete recalculation results of the same node according to the node identifier, and generate blockchain verification data or blockchain anomaly verification data.

[0130] S43. Re-encode the sharing request data and generate a verification sharing request digest. When the verification sharing request digest is consistent with the sharing request digest in the blockchain verification data and the final sharing control code is 1, enable the hardware security module to generate a one-time data encryption key and encrypt the plaintext package of medical research data.

[0131] S44. Within the hardware security module, the one-time data encryption key is encrypted using the public key of the receiving research institution to generate the key ciphertext. The encrypted delivery data digest, key ciphertext digest, and blockchain verification data are written into the permissioned consortium blockchain. The encrypted delivery data and key ciphertext are published after the registered transaction reaches the final confirmation state. If any necessary processing fails, the publication is blocked and the clearing process is executed.

[0132] In this embodiment, it should be noted that in S41, each blockchain verification node receives the same normalized sharing request byte sequence, certificate status reference block height, medical research data exchange protocol version, consensus configuration version, and two change sequences submitted by the shared gateway. The blockchain verification node independently reads the certificate registration information from the fixed block state of the permissioned consortium blockchain and verifies the certificate registration version, certificate serial number, and the public key certificate byte sequence of the receiving research institution.

[0133] Each blockchain verification node sequentially performs the following steps: record field checking, record sorting, normalized encoding, shared request digest generation, time-continuous record segmentation, generation of two change sequences, calculation of the maximum consecutive length of the original position's common rising sequence, all non-zero left cyclic shifts, calculation of the maximum consecutive length of the non-zero cyclic shifts' common rising sequence, and determination of the pending shared control code. The node compares its two self-generated change sequences byte-by-byte with the two change sequences submitted by the shared gateway, and does not accept the two consecutive lengths or the pending shared control code provided by the shared gateway as the recalculation result.

[0134] The input sequence digest is fixed as follows: the complete byte encoding of the sequence with varying record counts comes first, followed by the complete byte encoding of the sequence with varying restriction level record proportions. Both complete byte encodings include the sequence header and all data sequence elements. No text delimiters are added between fields, and no implementation-specific object serialization format is used. The concatenated raw bytes are processed using SHA-256 to obtain a 32-byte input sequence digest.

[0135] The complete recalculation result of a node is encoded in a fixed order: protocol version, consensus configuration version, shared request digest, input sequence digest, maximum consecutive length of the original position's common increasing sequence, maximum consecutive length of the non-zero cyclic shift's common increasing sequence, and the shared control code to be confirmed. Each blockchain validator node generates a digital signature using the node signing private key registered in the permissioned consortium blockchain consensus configuration and submits the result along with its node identifier.

[0136] Furthermore, in S42, the consensus configuration is published via a permissioned consortium blockchain governance transaction, including the configuration version, the block height at which the configuration takes effect, member node identifiers, member node signing public keys, the number of fault-tolerant nodes, and the number of consensus confirmation nodes. Each blockchain validator node only uses the same consensus configuration version that has taken effect and received final confirmation at the certificate status reference block height.

[0137] The total number of blockchain verification nodes, the number of fault-tolerant nodes, and the number of consensus confirmation nodes are not calculated based on medical research data. Before configuration release, the fault tolerance target is determined based on the number of participating institutions and the number of nodes allowed to fail simultaneously or submit erroneous results. The configuration is then verified through tests involving node offline, erroneous result injection, duplicate submissions, and network recovery. For example, in this implementation, when configuring 4 blockchain verification nodes and allowing 1 node to fail, the number of consensus confirmation nodes is configured to 3. After testing confirms that any 3 normal nodes can reach a consistent result and that a single abnormal node cannot change the final shared control code, the configuration is then released through a governance transaction.

[0138] The consensus process verifies the node identifier, node signature, consensus configuration version, and field integrity item by item. It deduplicates by node identifier and then groups all fields of the node's complete recalculation result. Repeated submissions of the same result by the same node are counted only once. When a conflicting result is submitted by the same node, the node's conflict status is recorded; different submissions cannot be counted separately in the consensus count.

[0139] When the number of nodes that have reached consensus confirmation reaches the number of complete recalculation results for the same node, the final shared control code adopts the unconfirmed shared control code from that set of results, and blockchain verification data is generated. The blockchain verification data sequentially records the data structure version, shared request digest, input sequence digest, maximum consecutive length of common increasing position at the original position, maximum consecutive length of common increasing position with non-zero cyclic shift, unconfirmed shared control code, final shared control code, consensus configuration version, confirmation node identifier, and node signature.

[0140] When input validation fails or no consensus confirmation nodes are found, the final shared control code is set to 0, and blockchain anomaly verification data is generated. This data records a fixed-width failure reason code, relevant input digest, failure handling stage, consensus configuration version, the final shared control code (valued at 0), and the signatures of verified nodes. Continuous lengths that do not exist due to incomplete calculations are marked as not generated and are not entered as fictitious values.

[0141] The final confirmation status of transactions registered on a permissioned consortium blockchain is defined by the blockchain's consensus configuration, and is not replaced by an arbitrarily set block waiting number. For permissioned consortium blockchains with deterministic finality, a transaction is considered final after it has been confirmed by a valid node and written into the irreversible ledger state. Before the configuration is released, the final state identification results are verified through tests on a normal network, a delayed network, and a number of allowed node failures. For example, in a configuration with 4 nodes and allowing 1 node failure, a transaction is considered final only after it is submitted by a valid node that meets the consensus conditions and enters the irreversible ledger state; merely entering the node's pending queue or being received by only one node does not constitute final confirmation.

[0142] In S43, the system uses the same protocol version, certificate status reference block height, recipient research institution identifier, certificate registration version, certificate serial number, and certificate bytes locked during the initial generation of the share request digest. It then regenerates the review share request digest according to the same record arrangement order, field order, length encoding, byte order, and digest algorithm. No new certificates are selected during the review process.

[0143] The system concatenates the records in the shared request data according to their order, including the number of records, the encoded length of each record, and the complete normalized bytes of each record, to form a plaintext packet of medical research data. The byte sequence of the receiving research institution's public key certificate is not written into the plaintext packet. Only when the shared request digest matches byte-by-byte with the shared request digest in the blockchain verification data, and the final shared control code is 1, does the system submit a key generation authorization request to the hardware security module.

[0144] The hardware security module uses an internal cryptographic random number generator, which undergoes startup checks and continuous health checks, to generate a 256-bit one-time data encryption key and creates a key object with permissions that only allow authentication encryption and public key encryption for the current request, and prohibit plaintext export. The hardware security module returns a key handle that references the internal key object; the key handle does not contain the plaintext one-time data encryption key. For example, when processing two shared requests simultaneously, two different key objects and different key handles should be generated; if the random number generator health check fails or the key object permission setting fails, no ciphertext is output.

[0145] The hardware security module uses AES-256-GCM to process plaintext packets of medical research data, generating encrypted medical research data, a 96-bit random initialization vector, and a 128-bit authentication tag. Additional authentication data is formed by concatenating a shared request digest, an input sequence digest, and a final shared control code in a fixed order, binding the encrypted medical research data to the blockchain verification result.

[0146] The 256-bit AES key is the standard key length specified by NIST FIPS 197, and the GCM authentication encryption structure and 96-bit initialization vector processing conform to the processing method described in NIST SP800-38D. This implementation uses a fixed 128-bit authentication tag and does not employ shortened authentication tags.

[0147] Before release, the cryptographic algorithm suite parameters undergo known answer testing, incorrect authentication label testing, random initialization vector generation testing, maximum plaintext packet length testing for medical research data, and receiver interoperability testing. For example, the tests use both 1 MiB and 1 GiB plaintext packets for medical research data. Only when both lengths can be encrypted successfully, the correct authentication label can be decrypted, and any modification to the authentication label results in decryption failure, will the corresponding hardware security module be included in the allowed devices. The maximum number of plaintext packets for medical research data configured in the protocol must not exceed the verified maximum limit of the hardware security module.

[0148] The encrypted delivery data sequentially includes the cryptographic algorithm suite version, the length of the ciphertext for the medical research data, the ciphertext for the medical research data, a random initialization vector, and an authentication tag. The encrypted delivery data is first written to a temporary storage area that is unreadable by the recipient, and the temporary storage state is initialized to unpublishable. If authentication encryption fails, the authentication tag length is incorrect, or the temporary storage is incomplete, the system deletes the temporary storage data and enters the exception blocking branch.

[0149] Furthermore, in S44, the hardware security module references the internal one-time data encryption key through the key handle and performs RSAES-OAEP public key encryption using the 3072-bit RSA public key from the recipient's research institution certificate. The master digest algorithm uses SHA-256, the mask generation function uses MGF1 based on SHA-256, and the padding tags use a sequence of empty bytes of length 0 bytes. The aforementioned parameters correspond to the RSAES-OAEP parameter structure described in RFC8017.

[0150] The one-time data encryption key is 256 bits long, corresponding to a 32-byte public key encryption input; when using a 3072-bit RSA public key, the key ciphertext length is 384 bytes. The 32-byte input falls within the range that this public key length and the SHA-256 padding parameters can accommodate. This compatibility was verified before the release of the cryptographic algorithm suite through public key encryption, private key decryption, erroneous key ciphertext rejection, and output length tests.

[0151] Public-key encryption is performed internally within the hardware security module, preventing external processors from accessing the one-time data encryption key plaintext. After generating the key ciphertext, the hardware security module deletes the one-time data encryption key object and invalidates the key handle. The system reads the deletion result, confirms that the key object cannot be used again, and clears the plaintext medical research data packet and intermediate authentication status from the external processor.

[0152] The system uses SHA-256 to process the encrypted delivery data and key ciphertext, respectively, to obtain encrypted delivery data digest and key ciphertext digest. The system will then use the shared request digest, input sequence digest, encrypted delivery data digest, key ciphertext digest, blockchain verification data digest, protocol version, and certificate serial number to form a permitted consortium blockchain registration transaction.

[0153] Before the registration transaction reaches the final confirmation state as stipulated in the consensus configuration of the permissioned consortium blockchain, the encrypted delivery data and key ciphertext remain unpublishable. After the registration transaction is finally confirmed, the system recalculates the digests of the two temporarily stored data items and compares them byte-by-byte with the on-chain registration digest. Only after the comparison is consistent is the temporary storage state changed to publishable, and the encrypted delivery data and key ciphertext are provided through an authentication channel bound to the identifier of the recipient's research institution.

[0154] When a registration transaction fails to submit temporarily, the system can perform an idempotent retry using the same transaction content and transaction identifier, without regenerating the one-time data encryption key or encrypted delivery data. When a registration transaction is permanently rejected, the temporary write fails, the digest verification fails, or the authentication delivery channel fails to be established, the system keeps the temporary data unpublishable and deletes the encrypted delivery data, key ciphertext, and corresponding temporary index.

[0155] This invention also provides a medical research information sharing system based on keys and blockchain, such as... Figure 7As shown, the system includes the following physical and logical modules: a change sequence generation module, used to generate a record quantity change sequence and a limit-level record ratio change sequence with the same number of elements and no less than 2, each element containing a change amplitude value and an increase flag value; an original position common increase statistics module, used to obtain the non-negative median difference based on the median of the change amplitude values ​​of the two change sequences, generate a common super-median increase flag value based on the two non-negative median differences and two increase flag values ​​at the same element position, and linearly calculate the maximum continuous length of the original position common increase; a non-zero cyclic shift statistics module, used to keep the record quantity change sequence unchanged, perform all non-zero left cyclic shifts on the limit-level record ratio change sequence, and linearly calculate and obtain the maximum continuous length of the non-zero cyclic shift common increase; sharing The control code generation module sets the value of the unconfirmed shared control code to 0 when the maximum continuous length of the common rise at the original position is greater than the maximum continuous length of the common rise of the non-zero cyclic shift; otherwise, it sets the value to 1. The blockchain recalculation and confirmation module enables blockchain verification nodes to independently recalculate from the same shared request data, and uses the unconfirmed shared control code as the final shared control code when the number of consensus confirmation nodes reaches the number of complete recalculation results of the same nodes; otherwise, the final shared control code is set to 0. The key generation and encrypted delivery module includes a hardware security module, which generates a one-time data encryption key only when the final shared control code is 1 and the shared request digest verification is consistent, and performs medical research data authentication encryption, one-time data encryption key public key encryption, digest registration, final confirmation of registration transactions, and encrypted delivery and release.

[0156] In one implementation, the system further includes a request parsing and certificate verification module, a time-continuous record segment generation module, an on-chain evidence storage and publication control module, and an anomaly blocking module. The request parsing and certificate verification module receives external shared request data and performs record field parsing, identity association field checking, research content field checking, recipient research institution permission checking, and on-chain certificate reading and verification. The time-continuous record segment generation module calculates adjacent time intervals, the median of adjacent time intervals, the median absolute deviation of time intervals, and the time interval splitting boundary. The on-chain evidence storage and publication control module temporarily stores encrypted delivery data and key ciphertext, submits registration transactions, and opens delivery after the registration transaction reaches final confirmation. The anomaly blocking module sets the final shared control code to 0, clears the temporary data, and records blockchain anomaly verification data when parsing, certificate, digest, recalculation, consensus, key generation, authentication encryption, public key encryption, on-chain registration, or publication processing fails.

[0157] In one implementation, the change sequence generation module, the original position common rise statistics module, the non-zero cyclic shift statistics module, and the shared control code generation module are implemented by at least one processor in the shared gateway executing program instructions stored in memory. The shared gateway is configured with an external request receiving interface, a permissioned consortium blockchain communication interface, a blockchain verification node communication interface, a hardware security module calling interface, and a temporary storage area access interface.

[0158] The blockchain recalculation and confirmation module is distributed across multiple independent blockchain verification nodes. Each blockchain verification node includes a processor, memory, a permissioned consortium connection port, and a node signature component. It reads the same version of the certificate, medical research data exchange protocol configuration, and consensus configuration based on the certificate status and reference block height.

[0159] The key generation and encrypted delivery module connects to the hardware security module via a local controlled bus or a dedicated network interface with bidirectional authentication. The interface only transmits key generation instructions, authentication encryption inputs, public key encryption instructions, key deletion instructions, and key handles; it does not transmit the plaintext of the one-time data encryption key.

[0160] The number of processors, memory capacity, network bandwidth, buffer size, and concurrent processing capacity of the hardware security module are deployment capacity parameters and are not involved in the calculation of the pending or final shared control code. Before deployment, request logs can be collected for 30 consecutive days. The number of requests, the number of records per request, the length of a single record, and the total data volume are statistically analyzed in 5-minute time intervals. Then, record parsing, all non-zero cyclic shifts, node communication, authentication encryption, and public key encryption tests are performed sequentially for 1, 2, and 4 concurrent requests. For example, if the tests confirm that all 4 concurrent requests can be completed within the target processing time, and the processor, memory, and hardware security module do not reach a denial-of-service state, the corresponding device configuration can be determined as the deployment baseline; changes to the device configuration must not alter any algorithm results.

[0161] The following uses a specific application scenario to integrate and verify the calculation logic and data flow process of each step in the above implementation method.

[0162] Suppose that at a certain moment, the shared gateway receives an external sharing request containing 150 medical research data records to be shared and the identifier of the receiving research institution. The number 150 is derived from the total number of records actually included in this external sharing request, not a preset sample size. The identifier of the receiving research institution is derived from the registration information of the permissioned consortium blockchain member and is not generated temporarily by the shared gateway.

[0163] The shared gateway reads the latest available block that has been finally confirmed in the permissioned consortium blockchain at the time of this request's acceptance, and fixes the corresponding block height to the certificate status reference block height. Within this block status, the shared gateway obtains the public key certificate byte sequence of the receiving research institution. The certificate contains a 3072-bit RSA public key; the 3072 bits are a fixed configuration derived from the cryptographic algorithm suite version and have passed interoperability tests with the sender, hardware security module, and receiver.

[0164] In S1, the shared gateway parses each of the 150 records, including the record unique identifier, timestamp, identity association field byte sequence, and research content field byte sequence. The record unique identifier is 16 bytes, which is the field length specified in the medical research data exchange protocol version; the timestamp is 8 bytes, which is the unsigned big-endian field length specified in the same protocol version. All 150 records undergo checks for field integrity, length boundaries, trailing bytes, duplicate record unique identifiers, and non-empty research content fields.

[0165] The aforementioned 150 records, arranged according to their timestamps and unique identifiers, form 149 pairs of adjacent records, thus creating 149 adjacent time intervals. The number 149 arises because the number of adjacent record pairs in the linear arrangement is one less than the total number of records.

[0166] The example data source consists of five separate consecutive write operations. The first through fifth consecutive write operations produce 10, 20, 40, 40, and 40 records respectively, and the sum of these five record counts yields the 150 records requested in this request. The timestamp difference between adjacent records within each consecutive write operation is 10 seconds, derived from the example data source's actual timestamp setting of writing one record every 10 seconds. The timestamp difference between two consecutive write operations is 300 seconds, derived from the example data source's actual timestamp setting of a 300-second pause between write operations.

[0167] The number of adjacent time intervals within the first to fifth consecutive write processes are 9, 19, 39, 39, and 39, respectively, because the number of adjacent record pairs within each process is one less than the number of records in that process. Adding these internal adjacent time intervals together gives 145. There are four separation positions between the five consecutive write processes, therefore there are four additional 300-second adjacent time intervals. The total of the 145 internal adjacent time intervals and the four adjacent time intervals between processes is 149, consistent with the number of adjacent record pairs formed by 150 records.

[0168] Of the 149 adjacent time intervals, 145 have a value of 10 seconds. Therefore, the median value after ascending sorting is 10 seconds, and the median of adjacent time intervals is 10 seconds. The absolute deviation of each 10-second adjacent time interval from this median is 0 seconds; the absolute deviation of each 300-second adjacent time interval from this median is 290 seconds, where the 290 seconds comes from the difference between 300 seconds and 10 seconds. Since the absolute deviation of all 145 time intervals is 0 seconds, the median of the absolute deviation of the time intervals is 0 seconds, and the time interval division boundary is 10 seconds.

[0169] The intervals between the four processes are all 300 seconds, which is strictly greater than the time interval splitting boundary of 10 seconds. Therefore, the shared gateway performs splitting at these four locations, resulting in five consecutive time record segments. The number of consecutive time record segments of five is due to the fact that the number of record segments into which the ordered record set is divided at the four splitting locations is one more than the number of splitting locations.

[0170] The five consecutive time-series recording segments contain 10, 20, 40, 40, and 40 records respectively, corresponding to the five consecutive write processes in this example. The number of restricted-level medical research data records contained in each segment are 1, 8, 16, 16, and 16 respectively. These values ​​are derived from the statistical results of records within each segment whose identity association field byte sequences are not empty and have passed the field directory check.

[0171] The first consecutive time-series recording segment has a restricted record ratio of 0.1, derived from one restricted medical research data record divided by 10 records in that segment. The second consecutive time-series recording segment has a restricted record ratio of 0.4, derived from eight restricted medical research data records divided by 20 records in that segment. The subsequent three consecutive time-series recording segments all have a restricted record ratio of 0.4, derived from 16 restricted medical research data records in each segment divided by 40 records in that segment. The value 3 is derived from the number of segments in the third through fifth consecutive time-series recording segments.

[0172] The absolute difference in the number of records in the first pair of adjacent consecutive time segments is 10, originating from the difference between 20 and 10; the larger of the two record counts is 20, therefore the change in record count is 0.5. The absolute difference in the number of records in the second pair of adjacent consecutive time segments is 20, originating from the difference between 40 and 20; the larger of the two record counts is 40, therefore the change in record count is 0.5. The subsequent two pairs of adjacent consecutive time segments have the same number of records, therefore the corresponding change in record count is 0. The value 2 originates from the third and fourth pairs of adjacent consecutive time segments.

[0173] The values ​​for the record count increase are 1, 1, 0, and 0, respectively. The first two values ​​of 1 indicate that the record count increased from 10 to 20 and from 20 to 40, respectively; the latter two values ​​of 0 indicate that the record count in consecutive time segments remained at 40, and no strict increase occurred.

[0174] The first pair of consecutive time-series recording segments shows a restriction level recording ratio change of 0.3, derived from the absolute difference between 0.4 and 0.1. The subsequent three pairs of consecutive time-series recording segments all have a restriction level recording ratio of 0.4, therefore their corresponding change values ​​are all 0. The restriction level recording ratio increase indicators are 1, 0, 0, and 0 respectively. The first value of 1 indicates that the restriction level recording ratio increases from 0.1 to 0.4, while the remaining values ​​of 0 indicate that the ratio remains the same.

[0175] Five consecutive time-series recordings form four pairs of adjacent consecutive time-series recordings. Therefore, both the sequence of changes in the number of records and the sequence of changes in the percentage of records at the limit level contain four data sequence elements. The logical value 0.5 is encoded as the integer 50 with two decimal places and a scaling factor of 100; the logical value 0.3 is encoded as the integer 30; and the logical value 0 is encoded as the integer 0. The scaling factor of 100 is derived from the protocol's use of fixed-point precision with two decimal places.

[0176] In S2, the ascending copies of the values ​​recording the magnitude of change in quantity are 0, 0, 0.5, and 0.5. Since the number of elements (4) is even, the median is the arithmetic mean of the two middle values ​​(0 and 0.5), resulting in 0.25. The ascending copies of the values ​​recording the magnitude of change in proportion at the restriction level are 0, 0, 0, and 0.3, with the two middle values ​​both being 0; therefore, the corresponding median is 0.

[0177] The non-negative median difference in the number of records at the first element position is 0.25, derived from the change in record count of 0.5 minus the median of 0.25; the non-negative median difference in the proportion of records in the restricted level is 0.3, derived from the change in the proportion of records in the restricted level of 0.3 minus the median of 0. The smaller of the two non-negative median differences is 0.25, therefore the first common median difference is 0.25. Both rising indicators at this position are 1, therefore the first common median rising indicator is 1.

[0178] The non-negative median difference in the number of records at the second element position is 0.25, derived from the change in the number of records (0.5) minus the median (0.25). The change in the proportion of records in the restricted level is 0, therefore both the non-negative median difference and the common median difference for the proportion of records in the restricted level are 0. Neither of the two change values ​​for the third and fourth element positions exceeds their respective medians, therefore the corresponding common median rise indicator values ​​are both 0.

[0179] The common super-median rising flag values ​​are 1, 0, 0, and 0 respectively. When performing a linear scan from the 1st element position to the 4th element position, only the 1st element position forms a continuous count of 1, so the maximum continuous length of the common rising at the original position is 1.

[0180] In S3, the number of elements in the changed sequence is 4, therefore the number of non-zero left circular shifts is 3. This value comes from the number of circular shifts that need to be processed in addition to the original permutation. The original first data sequence element, which contains the limit level record ratio change value of 0.3 and the limit level record ratio increase flag value of 1, is located at the fourth element position after a left circular shift of 1 element position. The non-negative median difference of the number of records at this position is 0, and the corresponding maximum continuous length of a single shift common increase is 0.

[0181] After shifting left by 2 elements, the aforementioned data sequence element is at the 3rd element position. The non-negative median difference in the number of records at this position is 0, and the maximum consecutive length of a single shift is 0. After shifting left by 3 elements, the aforementioned data sequence element is at the 2nd element position. The non-negative median difference in the number of records at this position is 0.25, and the increase in the number of records is 1. Therefore, the maximum consecutive length of a single shift is 1.

[0182] The maximum consecutive lengths of all single shifts rising together are 0, 0, and 1 respectively, with the maximum value being 1. Therefore, the maximum consecutive length of non-zero cyclic shifts rising together is 1. The maximum consecutive length of the original position rising together is also 1, which is not strictly greater than the maximum consecutive length of non-zero cyclic shifts rising together. Therefore, the value of the shared control code to be confirmed is 1.

[0183] In S4, the consensus configuration includes 4 blockchain verification nodes, allows for the failure of 1 node, and configures the number of consensus confirmation nodes to be 3. The total number of nodes (4), the number of fault-tolerant nodes (1), and the number of consensus confirmation nodes (3) are all derived from the consensus configuration that has passed the node offline and error result injection tests and been published by the permissioned consortium blockchain governance transaction, and are not calculated from the 150 medical research data records in this instance.

[0184] Four blockchain verification nodes recalculate from the same shared request data, certificate status reference block height, and protocol version. Each normal node receives a shared request digest, an input sequence digest, a maximum consecutive length of 1 (in original position), a maximum consecutive length of 1 (non-zero cyclic shift), and a shared control code of 1 to be confirmed. At least three different nodes achieve identical field-by-field recalculation results and pass node signature verification, reaching the consensus configuration's required number of three consensus confirmation nodes. Therefore, the final shared control code value is 1.

[0185] The shared gateway generates a verification shared request digest using the same fields, record order, certificate version, and encoding rules as when the initial shared request digest was generated. The verification result is consistent byte-by-byte with the shared request digest in the blockchain verification data. Finally, the shared control code is set to 1, and the digest verification is consistent; therefore, the hardware security module obtains key generation authorization.

[0186] The hardware security module generates a 256-bit one-time data encryption key, with the value 256 derived from the AES-256-GCM key length used by the cryptographic algorithm suite. The hardware security module also generates a 96-bit random initialization vector and a 128-bit authentication tag, with the values ​​96 and 128 derived from the fixed configuration of the GCM parameters within the same cryptographic algorithm suite, and have been tested for interoperability between the sender and receiver.

[0187] The hardware security module uses the 3072-bit RSA public key from the recipient's research institution certificate to perform RSAES-OAEP public key encryption, resulting in a 384-byte ciphertext key. The 384-byte length of the ciphertext key comes from the 3072-bit RSA modulus, where every 8 bits constitute one byte. After the public key encryption is complete, the hardware security module deletes the one-time data encryption key object and invalidates the key handle.

[0188] The shared gateway generates both the encrypted delivery data digest and the key ciphertext digest, and submits them to the permissioned consortium blockchain for registration, which includes blockchain verification data. Once the registration transaction reaches the irreversible final state defined in the consensus configuration, the shared gateway re-verifies the two digests. Only after they match are the temporarily stored encrypted delivery data and key ciphertext changed to a publishable state. The entire process achieves a complete data and control flow loop, from 150 original records, 149 adjacent time intervals, 5 consecutive time record segments, 4 changing sequence elements, two consecutive lengths, the pending shared control code, the final shared control code, to the encrypted delivery result.

[0189] The preferred embodiments of this disclosure have been described in detail above with reference to the accompanying drawings. However, this disclosure is not limited to the specific details of the above embodiments. Within the scope of the technical concept of this disclosure, various simple modifications can be made to the technical solutions of this disclosure, and these simple modifications all fall within the protection scope of this disclosure.

[0190] It should also be noted that the various specific technical features described in the above embodiments can be combined in any suitable manner without contradiction. To avoid unnecessary repetition, this disclosure will not describe the various possible combinations separately.

[0191] Furthermore, various different embodiments of this disclosure can be combined in any way, as long as they do not violate the spirit of this disclosure, they should also be regarded as the content disclosed in this disclosure.

[0192] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention, and they should all be covered within the scope of the claims and specification of the present invention.

Claims

1. A method for sharing medical research information based on keys and blockchain, characterized in that the method... include: Obtain shared request data; Generate a shared request digest, and generate a sequence of record number changes and a sequence of record proportion changes of equal length, each containing at least two elements, with each element containing a change magnitude value and an increase flag value; Subtract the median of the sequence from each change value, and set the negative difference to 0; when the two differences at the same position are both greater than 0 and the rising indicator value is 1, the rising indicator value of the common median is 1, otherwise it is 0, and the maximum continuous length of the common rising at the original position is linearly counted. For a fixed sequence of record quantity changes, all non-zero cyclic shifts are performed on the sequence of limit level record proportion changes. The maximum value is then taken as the maximum continuous length of the non-zero cyclic shift. If the maximum continuous length of the non-zero cyclic shift is greater than this length, the pending shared control code is 0; otherwise, it is 1. Blockchain verification nodes independently recalculate based on the same shared request data; when the number of nodes with the same complete recalculation result reaches the consensus confirmation node number, the unconfirmed shared control code among them is used as the final shared control code, otherwise it is 0; The hardware security module generates a one-time data encryption key only when the final share control code is 1 and the share request digest verification is consistent.

2. The method for sharing medical research information based on keys and blockchain according to claim 1, characterized in that, The generation of a sequence of equal lengths containing at least two elements for each record number variation and a sequence of variation for the proportion of restricted-level records includes: The records in the shared request data are arranged according to their timestamps and unique identifiers to obtain ordered records. Calculate the adjacent time intervals of the ordered records; if adjacent time intervals cannot be formed, set the final shared control code to 0 and terminate the process; Determine the median of adjacent time intervals and the median of the absolute deviation of each adjacent time interval from the median, and use the sum of the two as the data-driven discontinuity boundary. The ordered records are segmented at positions where the adjacent time interval is strictly greater than the boundary, and no segmentation is performed at positions where the two are equal, resulting in a continuous time record segment; if there are fewer than 3 continuous time record segments, the final shared control code is set to 0 and the processing is terminated.

3. The method for sharing medical research information based on keys and blockchain according to claim 2, characterized in that, The generation of a sequence of equal lengths containing at least two elements for each record number variation and a sequence of variation for the proportion of restricted-level records includes: The number of records and the number of restricted records in each consecutive recording segment are counted, and the proportion of restricted records is obtained by dividing the number of restricted records by the total number of records. The change in the number of records is obtained by dividing the absolute value of the difference between the number of adjacent records by the larger of the two record numbers; the change in the proportion is obtained by taking the absolute value of the difference between the proportions of adjacent restriction level records. When the number of records in the later segment is greater than the number of records in the earlier segment, the count increment flag is 1; otherwise, it is 0. When the proportion of restricted records in the later segment is greater than the proportion of restricted records in the earlier segment, the proportion increment flag is 1; otherwise, it is 0. The change magnitude value is encoded according to the fixed-point precision and rounding rules of the protocol, and then combined with the corresponding rising indicator value in chronological order to form two change sequences.

4. The method for sharing medical research information based on keys and blockchain according to claim 1, characterized in that, The step of subtracting the median of the sequence from each change magnitude value and setting the negative difference to 0 includes: Copy and sort the magnitude values ​​of the two changed sequences in ascending order; when the number of elements is odd, take the median as the middle value, and when the number of elements is even, take the arithmetic mean of the two median values ​​as the median. Subtract the median from each change value and set the negative difference to 0 to obtain the non-negative median difference; When the difference between two non-negative medians at the same position is greater than 0 and the corresponding rising indicator value is 1, the common median rising indicator value is 1; otherwise, it is 0. Fixed-point integer arithmetic and rational number arithmetic are used, but binary floating-point arithmetic is not used.

5. The method for sharing medical research information based on keys and blockchain according to claim 1, characterized in that, The maximum continuous length of the common increase at the original position in the linear statistics includes: Read the common supermedian rising indicator value sequentially according to the element position; When the read value is 1, the current continuous count is incremented by 1; when the read value is 0, the current continuous count is set to 0, and the maximum value of the current continuous count during the reading period is saved. After reading, the maximum value saved is used as the maximum continuous length of the original position, and the end of the sequence is not connected to the beginning for statistical purposes.

6. The method for sharing medical research information based on keys and blockchain according to claim 1, characterized in that, The step of cyclically shifting all non-zero values ​​in the restriction level recording scale change sequence includes: Each percentage change value is combined with the corresponding rising indicator value to form an indivisible element, keeping the sequence heads and record number change sequences of the two change sequences unchanged; Perform a left circular shift sequentially from shifting one element to shifting one element less than the number of elements, moving the starting element to the end each time; Even if the byte content of different shift results is the same, they are still processed separately; After each shift, the maximum continuous length of the single shift is obtained according to the same rule, and the maximum value is taken as the maximum continuous length of the non-zero cyclic shift.

7. The method for sharing medical research information based on keys and blockchain according to claim 1, characterized in that, The blockchain verification nodes independently recalculate based on the same shared request data, including: Each blockchain verification node regenerates the shared request digest and two change sequences, and independently performs median difference processing, original position linear statistics, all non-zero cyclic shift statistics, and generation of the unconfirmed shared control code; Verify the two independently generated change sequences against the two change sequences submitted by the shared gateway; After verification, the complete byte encodings of the two changing sequences are concatenated in a fixed sequence order and cryptographic digest operations are performed to obtain the input sequence digest. The complete recalculation result of the node is composed of the shared request digest, the input sequence digest, two maximum consecutive lengths, and the shared control code to be confirmed, and the corresponding blockchain verification node generates the node digital signature.

8. The method for sharing medical research information based on keys and blockchain according to claim 1, characterized in that, When the number of nodes with identical complete recalculation results reaches the consensus confirmation threshold, the unconfirmed shared control code among them is used as the final shared control code; otherwise, it is 0. This includes: Read the total number of blockchain verification nodes, the number of fault-tolerant nodes, and the number of consensus confirmation nodes from the same consensus protocol configuration; Verify the identity of the blockchain verification node and the node's digital signature, and deduplicate the complete recalculation result of the node according to the blockchain verification node identifier; Treat the complete recalculation results of the nodes as an indivisible data unit, and group them according to whether all fields are the same. When the number of valid nodes in the same group reaches the consensus confirmation number, the unconfirmed shared control code of the group is confirmed; otherwise, the final shared control code is set to 0.

9. The method for sharing medical research information based on keys and blockchain according to claim 1, characterized in that, The hardware security module generates a one-time data encryption key only when the final shared control code is 1 and the shared request digest verification is consistent, including: Re-encode the shared request data according to the arrangement and length encoding rules used when generating the shared request digest, and calculate and verify the shared request digest; When the verification is consistent and the final shared control code is 1, a one-time data encryption key that cannot be exported is generated in the hardware security module. This key is used to authenticate and encrypt the plaintext packet of medical research data, and the public key in the public key certificate of the receiving research institution and randomized padding are used to encrypt the key. Upon successful key encryption or if any encryption failure occurs, the key and its key handle are destroyed; if any precondition is not met, encrypted delivery data and key ciphertext are not output.

10. A medical research information sharing system based on keys and blockchain, characterized in that, The system is used to implement the medical research information sharing method based on keys and blockchain as described in any one of claims 1 to 9, comprising: The change sequence generation module is used to acquire shared request data and generate a shared request summary, a record quantity change sequence, and a restriction level record ratio change sequence. The original position common rise statistics module is used to determine the common super-median rise indicator value and the maximum continuous length of the original position common rise; The non-zero cyclic shift statistics module is used to perform all non-zero cyclic shifts and determine the maximum continuous length of the common rise of non-zero cyclic shifts. The shared control code generation module is used to compare two maximum consecutive lengths and generate a shared control code to be confirmed. The blockchain recalculation and confirmation module is used to enable blockchain verification nodes to independently recalculate and determine the final shared control code; The key generation and encrypted delivery module, including a hardware security module, is used to generate a one-time data encryption key only when the final shared control code is 1 and the shared request digest verification is consistent, and to complete the encrypted delivery process.

Images