Blockchain-based medical information privacy security management method and system

Abstract

This invention discloses a blockchain-based method and system for managing the privacy and security of medical information. The method includes: authenticating institutional nodes and allocating permissions through a multi-chain collaborative mechanism; employing lightweight encryption algorithms to implement layered encryption of medical information with different sensitivity levels; constructing a unified privacy rule adaptation system using a cross-institutional privacy collaborative governance model and smart contracts; distributing the encrypted data to multi-chain nodes after sharding; collecting full-lifecycle operation data through a medical privacy traceability platform to generate tamper-proof traceability logs; and combining privacy and security management parameters with a multi-chain collaborative verification mechanism to analyze the logs in real time, identify abnormal behaviors, and trigger corresponding control responses. This invention integrates multiple technical modules to form a closed-loop management system, achieving compliance and security in cross-institutional sharing of medical information and providing an efficient solution for protecting medical information privacy.

Description

Technical Field

[0001] This invention relates to the field of medical information privacy management technology, and in particular to a blockchain-based method and system for medical information privacy and security management. Background Technology

[0002] In the process of digital transformation of medical information, the demand for cross-institutional sharing of medical information continues to grow, making the privacy and security protection of sensitive data such as core diagnostic and treatment data and basic patient information a critical issue. Medical information involves multi-institutional collaboration and interaction, encompassing the entire lifecycle of data collection, transmission, storage, and access. Its privacy and security are directly related to patient rights and the compliant development of the medical industry. Traditional centralized management models struggle to address challenges such as identity authentication, data encryption, and cross-institutional rule adaptation in distributed scenarios. Blockchain technology, with its characteristics of distributed storage, immutability, and smart contracts, provides technical support for building a full-process, cross-entity medical information privacy and security management system. There is an urgent need to combine multi-chain collaboration, lightweight encryption, and cross-institutional governance technologies to develop a privacy and security management solution adapted to medical scenarios.

[0003] Existing medical information privacy and security management technologies have two significant drawbacks: First, the cross-institutional privacy collaboration mechanism is imperfect. Each institution formulates its own privacy protection rules independently, lacking a unified rule mapping and conflict resolution system. This makes it difficult to dynamically adapt privacy constraints during data sharing, easily leading to compliance vulnerabilities. Furthermore, traditional encryption algorithms often employ a single encryption strategy, failing to combine the sensitivity level of medical information to achieve layered and differentiated encryption, making it difficult to achieve a balance between security protection and data processing efficiency. Second, the connection between traceability and risk control is not close. Existing traceability systems mostly only record basic operation logs, lacking comprehensive collection of key elements throughout the entire lifecycle of medical information. Moreover, they have not established risk analysis models that match multi-chain collaborative verification mechanisms, making it impossible to achieve real-time identification and accurate response to abnormal behavior. This results in delayed privacy and security risk warnings and makes it difficult to form a closed-loop management chain. Summary of the Invention

[0004] To overcome the shortcomings and deficiencies of existing technologies, this invention provides a blockchain-based method and system for managing the privacy and security of medical information.

[0005] The technical solution adopted in this invention is a blockchain-based method for managing the privacy and security of medical information, comprising the following steps: S1, through the node identity allocation mechanism in the multi-chain collaborative privacy protection model, distributed identity authentication is performed on the nodes of each institution participating in medical information interaction, and a node-specific privacy access certificate is generated based on the node's historical interaction credibility weight and the correlation factor of the blockchain consensus mechanism; S2, a lightweight blockchain encryption and decryption algorithm is used to perform layered encryption processing on the original medical information data, and combined with the results of the medical information sensitivity level classification, symmetric and asymmetric encryption fusion operations with different encryption strengths are performed on the labeled diagnosis and treatment data and patient basic information respectively; S3, a multi-institutional privacy rule mapping system is constructed using a cross-institutional privacy collaborative governance model, and the privacy protection of each institution is encoded through blockchain smart contracts. To comply with regulations, a dynamically adaptable cross-institutional data sharing privacy constraint agreement is established; S4, the encrypted medical information data is split according to a preset sharding strategy, and combined with the blockchain distributed storage architecture, the data shards are distributed and stored across multiple chain nodes, while recording the mapping relationship between the data shard index and the storage node address; S5, the entire lifecycle operation data of medical information is collected through the blockchain medical privacy traceability platform, including timestamps, operation node identifiers, and operation behavior type traceability elements for each stage of data encryption, transmission, access, and decryption, generating an immutable traceability log; S6, based on the risk warning threshold and abnormal behavior identification rules in the medical information privacy security management parameters, the traceability log is analyzed in real time, and the legality of data operations is verified through a multi-chain collaborative verification mechanism, triggering the corresponding privacy security control response.

[0006] Furthermore, the expression for the multi-chain collaborative privacy protection model is: ,in, Output values ​​for the multi-chain collaborative privacy protection model. The correlation coefficient between node identity and credibility. Let be the distributed identity identifier value of the i-th node. Let be the historical interaction credibility weight of the i-th node. Here, Cons represents the compatibility coefficient between the consensus mechanism and multi-chain collaboration, and Cons represents the performance value of the blockchain consensus mechanism. Let j be the degree of collaborative participation of the j-th chain. This is a coefficient for adjusting privacy constraints and security policies. For the k-th privacy protection rule, Let n be the node access permission threshold corresponding to the k-th rule, and n be the total number of participating nodes. The number of privacy protection rules.

[0007] Furthermore, the expression for the lightweight encryption / decryption algorithm for the blockchain is: ,in, This is the encrypted data string output by a lightweight encryption / decryption algorithm. For symmetric encryption operators, To calibrate diagnostic and treatment data, Assigning coefficients to encryption strength. It is an asymmetric encryption operator. For the patient's basic information, For hash functions, The hash value of the original medical information data. For temporary session keys, For digit-by-digit multiplication operator, It is the XOR operator.

[0008] Furthermore, the expression for the cross-agency privacy collaborative governance model is: CIPGM is the adaptation value for the cross-organizational privacy collaborative governance model. The contribution to privacy protection of the p-th institution, This is the smart contract code value for the corresponding organization. This serves as a compliance verification coefficient for the organization. For the privacy compliance level of the r-th organization, Let be the privacy rule mapping coefficient for the r-th institution. This is a dynamic adjustment factor, where base is the logarithmic base. q represents the number of dynamic privacy rules, t represents the total number of institutions participating in collaborative governance, and t represents the total number of privacy rule types.

[0009] Furthermore, the expression for assessing the traceability integrity of the blockchain-based medical privacy traceability platform is as follows: ,in, This is the traceability integrity assessment value. Weighting for the integrity of traceability records. This represents the actual number of traceability records collected. This represents the total number of traceability records that should theoretically be collected. As a weight for the validity of traceability elements, This serves as the validity identifier for the s-th traceability timestamp. Let be the credibility value of the s-th operation node, and I be the total number of traceability elements.

[0010] Furthermore, the risk warning expression for the medical information privacy and security management is as follows: ,in, This is a risk warning value. This represents the impact coefficient of abnormal behavior. Let u be the frequency of occurrence of the u-th abnormal behavior. Let u be the risk threshold for the uth abnormal behavior. For the safety management efficiency coefficient, To ensure the effectiveness of the implementation of the wth safety control measure, Let be the weight of the w-th security control measure, v be the total number of abnormal behavior types, and x be the total number of security control measures.

[0011] Further, S3 includes the following sub-steps: S31, extracting the internal rules for medical information privacy protection of each participating institution, including data access permission scope, data sharing boundaries, and privacy information confidentiality period marking rule elements, and converting unstructured rules into structured data format using natural language processing technology; S32, based on the syntax specifications of blockchain smart contracts, encoding the structured privacy rules of each institution into smart contract code fragments, clarifying the rule triggering conditions, execution logic, and violation handling methods; S33, constructing a cross-institutional privacy rule conflict detection matrix, comparing and analyzing the rule differences between different institutions, determining the conflict resolution priority based on the medical information privacy protection marking principle, and generating a unified rule adaptation scheme; S34, integrating the encoded smart contract code fragments with the rule adaptation scheme, deploying them to the blockchain main chain node, and ensuring the consistency and effectiveness of the cross-institutional data sharing privacy constraint protocol through multi-node consensus verification.

[0012] Further, step S4 includes the following sub-steps: S41, based on the type, size, and sensitivity level of the medical information data, set a threshold for the data shard size and an upper limit for the number of shards, calculate the hash value of the data shards using a consistent hashing algorithm, and determine the sharding logic; S42, according to the sharding logic, split the encrypted medical information data into several data shards, assign a unique identifier code to each data shard, and record the association relationship between each shard and the original data; S43, query the storage resource status and load of the blockchain multi-chain nodes, allocate the data shards to the optimal storage nodes based on the load balancing principle, and update the node storage directory and data shard index; S44, encrypt the mapping relationship between the data shard index and the storage node address and store it in the blockchain traceability chain to ensure the traceability and location accuracy of the data shards.

[0013] Further, S5 includes the following sub-steps: S51, in the medical information encryption stage, collecting encryption algorithm type, encryption key identifier, encryption start and end time operation data, and associating them with the unique identifier code of the corresponding data shard; S52, during data transmission, capturing data transmission path, transmission node sequence, transmission delay and other relevant traceability elements through the real-time communication protocol between blockchain nodes, and synchronously recording them in a temporary traceability cache; S53, in the data access and decryption stage, collecting access request node identifier, access permission verification result, decryption operation executor identity identifier, and decryption time information, and associating and matching them with the access log of the data shard; S54, integrating the data in the temporary traceability cache with the traceability elements collected in each stage, sorting them by timestamp order to generate a complete traceability log, verifying the integrity of the log through the blockchain consensus mechanism, and storing it in an immutable blockchain block.

[0014] This blockchain-based medical information privacy and security management system, applied to a blockchain-based medical information privacy and security management method, includes: an identity authentication and dynamic permission allocation unit, a medical information layered encryption processing unit, a cross-institutional privacy rule decryption and adaptation unit, a distributed storage and index management unit, a multi-dimensional traceability data collection and log generation unit, and a privacy and security risk real-time monitoring and analysis unit. The identity authentication and dynamic permission allocation unit verifies the legitimacy of participating institution nodes through a blockchain consensus mechanism, generates and outputs node-specific privacy access permission credentials to the medical information layered encryption processing unit, providing a permission basis for subsequent data encryption. After receiving the permission credentials, the medical information layered encryption processing unit performs differentiated encryption operations based on the medical information sensitivity level classification results, and transmits the encrypted data to the cross-institutional privacy rule decryption and adaptation unit. The system comprises several components: a de-adaptation unit and a cross-institutional privacy rule resolution unit. The de-adaptation unit encodes and resolves conflicts in the privacy rules of various institutions associated with encrypted data, generating a compliant and adaptable cross-institutional data sharing protocol. The protocol-bound data is then sent to the distributed storage and index management unit. The distributed storage and index management unit splits and stores the data according to the blockchain storage architecture, while simultaneously synchronizing the storage index information to the multi-dimensional traceability data collection and log generation unit. The multi-dimensional traceability data collection and log generation unit collects operational data from each unit in real time to generate traceability logs, which are then transmitted to the privacy and security risk real-time monitoring and analysis unit. The privacy and security risk real-time monitoring and analysis unit analyzes the logs and identifies risks, providing feedback on permission adjustment instructions to the identity authentication and dynamic permission allocation unit. All units interact and collaborate through the blockchain network, forming a closed-loop medical information privacy and security management chain.

[0015] Beneficial Effects: This invention proposes a blockchain-based method and system for managing the privacy and security of medical information. It achieves distributed identity authentication and dynamic permission allocation for participating institutional nodes through a multi-chain collaborative privacy protection model. Lightweight blockchain encryption and decryption algorithms are used to perform differentiated layered encryption for medical information with different sensitivity levels, effectively solving the imbalance between security and efficiency in traditional single encryption strategies. By leveraging a cross-institutional privacy collaborative governance model and smart contract technology, a unified privacy rule mapping and conflict resolution system is constructed, transforming the independent privacy requirements of each institution into a collaboratively adaptable sharing protocol, thus addressing the difficulty in unifying cross-institutional privacy constraints. Simultaneously, encrypted data sharding and distributed storage enhance data storage security. A blockchain-based medical privacy traceability platform comprehensively collects all lifecycle operational elements to generate tamper-proof logs. Combined with multi-chain collaborative verification and risk warning mechanisms, real-time identification of abnormal behavior is achieved, forming a closed-loop link of authentication-encryption-collaboration-storage-traceability-control. Each unit of the system achieves data collaboration and instruction feedback through the blockchain network, ensuring the compliance of cross-institutional sharing of medical information and achieving precise prevention and control of privacy and security risks through full-process traceability and dynamic control, comprehensively improving the integrity and reliability of medical information privacy and security management. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating the overall process of the method of the present invention. Figure 2 This is a flowchart of method step S3 of the present invention; Figure 3 This is a flowchart of method step S4 of the present invention; Figure 4 This is a flowchart of step S5 of the method of the present invention; Figure 5 This is a diagram showing the system unit composition of the present invention. Detailed Implementation

[0017] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. The application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0018] like Figure 1 As shown, a blockchain-based method for managing the privacy and security of medical information is characterized by the following steps: S1 uses the node identity allocation mechanism in the multi-chain collaborative privacy protection model to perform distributed identity authentication on the nodes of various institutions participating in medical information interaction. Based on the node's historical interaction credibility weight and the correlation factor of the blockchain consensus mechanism, it generates a node-specific privacy access permission certificate. Specifically, step S1 focuses on the identity authentication and permission allocation of various institutional nodes participating in medical information exchange, implemented through the node identity allocation mechanism in the multi-chain collaborative privacy protection model. First, the participating node types are clearly defined, including medical institutions, testing institutions, and research institutions. Each node must submit qualification verification materials and historical interaction records. The system extracts core fields such as institution code, business scope, and compliance certification number from the node registration information to construct a basic node information database. Subsequently, a quantitative calculation is performed based on the node's historical interaction credibility weight parameter. This weight parameter ranges from 0 to 1 and is derived by weighting 12 indicators, including the node's past data sharing compliance rate, number of privacy and security violations, and data transmission stability. The compliance rate accounts for 30% of the weight, and the number of violations accounts for 25%. Simultaneously, a correlation factor is applied to the blockchain consensus mechanism. This factor matches the selected consensus algorithm type; for example, the correlation factor is 0.75 when using the Practical Byzantine Fault Tolerance algorithm and 0.58 when using the Proof-of-Work algorithm. The system combines the above two data sets and performs parallel verification through distributed computing nodes of a multi-chain collaborative privacy protection model. After removing abnormal data, it generates a node-specific privacy access permission certificate. The certificate includes a unique node identification code, permission level code, and validity period stamp. The permission level is divided into 5 levels, with level 1 corresponding to core data access and level 5 corresponding to the permission to view only publicly available medical statistics data. The validity period stamp is set to 90 days by default. After expiration, the system needs to resubmit certification materials to renew the permission, ensuring the legitimacy of the node's identity and the compatibility of its permissions.

[0019] S2 uses a lightweight blockchain encryption and decryption algorithm to perform layered encryption processing on the original medical information data. Combined with the results of the medical information sensitivity level classification, it performs symmetric and asymmetric encryption fusion operations with different encryption strengths on the calibrated diagnosis and treatment data and the patient's basic information respectively. Specifically, the S2 step uses a lightweight blockchain encryption and decryption algorithm to implement layered encryption of medical information. The first step is to classify the sensitivity level of medical information. Based on relevant standards for medical data privacy protection, the data is divided into four sensitivity levels: Level 1 is core diagnosis and treatment data (such as pathology reports and gene testing results); Level 2 is basic patient privacy information (such as ID number and contact information); Level 3 is routine diagnosis and treatment data (such as outpatient medical records and examination orders); and Level 4 is publicly available medical data (such as disease prevention knowledge). Differentiated encryption strategies are formulated for different levels of data. Level 1 data adopts a combination of symmetric and asymmetric encryption. The symmetric encryption algorithm uses Advanced Encryption Standard (AES) with a key length of 256 bits, and the asymmetric encryption algorithm uses Elliptic Curve Cryptography (ECC) with a key length of 224 bits. The encryption strength coefficient is 0.92. Level 2 data also adopts a combined encryption method, with a symmetric encryption key length of 192 bits and an asymmetric encryption key length of 192 bits. The encryption strength coefficient is 0.78. Level 3 data uses only symmetric encryption with a key length of 128 bits and an encryption strength coefficient of 0.65. Level 4 data uses hash encryption with an encryption strength coefficient of 0.42. During implementation, the system first standardizes the original data format, splits the data into blocks according to field type, and controls the size of each data block to be between 1024 bytes and 4096 bytes. Then, it calls the core module of the blockchain lightweight encryption and decryption algorithm, and combines the encryption parameters of the corresponding sensitivity level to complete the data block encryption, key generation, and ciphertext concatenation operations in sequence. The generated ciphertext data includes four parts: data identifier header, encryption level identifier, ciphertext body, and check code. The check code is generated through a cyclic redundancy check algorithm to ensure the integrity of the encrypted data. The entire encryption process is completed locally on the blockchain node to avoid the risk of privacy leakage during data transmission.

[0020] S3 utilizes a cross-agency privacy collaborative governance model to construct a multi-agency privacy rule mapping system. It encodes the privacy protection compliance requirements of each agency through blockchain smart contracts, forming a dynamically adaptable cross-agency data sharing privacy constraint protocol. Specifically, step S3 utilizes a cross-institutional privacy collaborative governance model to construct a multi-institutional privacy rule mapping system. The implementation process begins with initiating a cross-institutional privacy rule collection process. This involves connecting to the privacy management systems of participating institutions through standardized interfaces to extract the privacy protection rules from each institution. These rules include eight core rule elements: data access permission scope (e.g., departmental access, institutional access, cross-institutional access), data sharing boundaries (e.g., whether cross-regional sharing is allowed, whether it is allowed for research), privacy information confidentiality periods (e.g., 30-year retention of medical records, long-term retention of basic information), and data anonymization requirements (e.g., whether some fields need to be hidden, anonymization standards). Subsequently, natural language processing technology is used to transform these unstructured rule texts into structured data formats, categorizing and storing them according to rule type, constraints, and execution standards to form a structured rule library. Based on the syntax specifications of blockchain smart contracts, the structured privacy rules of each institution are encoded into smart contract code snippets, clearly defining the triggering conditions (e.g., when a specific node initiates an access request), execution logic (e.g., verifying the access node's permission level, recording access behavior), and violation handling methods (e.g., denying access, freezing node permissions, reporting to the regulatory platform). Next, a cross-institutional privacy rule conflict detection matrix is ​​constructed, with rows and columns representing the number of participating institutions. By comparing the constraints and enforcement standards of rules across different institutions, conflict points are identified. For example, if Institution A allows cross-regional sharing of medical record data while Institution B prohibits it, a conflict exists. Based on the core principles of medical information privacy protection, conflict resolution priorities are determined in the order of patient rights first, compliance first, and practicality second, generating a unified rule adaptation scheme. Finally, the coded smart contract code snippet is integrated with the rule adaptation scheme and deployed to 10 core nodes and 20 backup nodes on the blockchain main chain. Multi-node consensus verification ensures the consistency and effectiveness of the cross-institutional data sharing privacy constraint protocol; a verification pass rate of over 95% is required for it to take effect.

[0021] S4 splits the encrypted medical information data according to a preset sharding strategy, and combines it with the blockchain distributed storage architecture to distribute the data shards to multiple chain nodes, while recording the mapping relationship between the data shard index and the storage node address. Specifically, step S4 implements encrypted medical information data fragmentation and distributed storage. First, a data fragmentation strategy is established based on the type, size, and sensitivity level of the medical information data. Data types are divided into three categories: text data, image data, and audio data. Different fragmentation algorithms are used for different data types: text data uses a paragraph-based fragmentation method, image data uses a pixel-block-based fragmentation method, and audio data uses a time-segment-based fragmentation method. Data fragment size thresholds are set according to sensitivity levels: the maximum size for a Level 1 data fragment is 512 bytes, for Level 2 it is 1024 bytes, for Level 3 it is 2048 bytes, and for Level 4 it is 4096 bytes. The maximum number of fragments per data fragment is controlled between 8 and 16, with the specific number dynamically adjusted based on the original data size. During implementation, the system first performs integrity verification on the encrypted medical information data. After confirming the data is undamaged through hash value comparison, it splits the data according to a preset sharding strategy, assigning a unique identifier code to each data shard. This code consists of a 16-bit institution identifier, an 8-bit data type identifier, a 12-bit shard sequence number, and an 8-bit checksum. Simultaneously, it records the association between each shard and the original data, including the original data identifier, the shard's position within the original data, and the shard assembly order. Subsequently, the system queries the storage resource status and load of the blockchain multi-chain nodes, obtaining parameters such as the remaining storage space, CPU utilization, and network bandwidth utilization of each node. Nodes with remaining storage space greater than three times the shard size, CPU utilization below 70%, and network bandwidth utilization below 60% are considered candidate storage nodes. Based on load balancing principles, a round-robin scheduling algorithm is used to allocate data shards to the optimal storage nodes. During allocation, it ensures that different shards of the same original data are stored on nodes of different chains, and that the number of data shards of the same sensitivity level stored on a single node does not exceed 15% of the node's total storage capacity. After allocation, the node storage directory and data shard index are updated. The data shard index includes information such as shard unique identifier, storage node address, storage time, and shard size. Finally, the mapping relationship between the data shard index and the storage node address is encrypted using a symmetric encryption algorithm and stored in a designated block of the blockchain traceability chain. The encryption key is jointly managed by multiple chain nodes to ensure the traceability and location accuracy of the data shards.

[0022] S5 collects operational data throughout the entire lifecycle of medical information through a blockchain-based medical privacy traceability platform, including timestamps, operation node identifiers, and traceability elements of operation behavior types for each stage of data encryption, transmission, access, and decryption, generating an immutable traceability log. Specifically, step S5 utilizes a blockchain-based medical privacy traceability platform to collect operational data and generate traceability logs throughout the entire lifecycle of medical information. The implementation process covers four core stages: data encryption, transmission, access, and decryption. In the medical information encryption stage, the system collects seven operational data items in real time: encryption algorithm type, encryption key identifier, encryption start time, encryption end time, encryption node identifier, encrypted data size, and encryption level. Each data item is recorded in a standardized format, with time accurate to milliseconds. Node identifiers use globally unique codes, and all collected data is associated with the unique identifier code of its corresponding data segment. During data transmission, a real-time communication protocol between blockchain nodes captures ten traceability elements, including data transmission path, transmission node sequence, transmission start time, transmission end time, transmission delay, data packet loss rate, and transmission bandwidth. Transmission delay is recorded accurate to microseconds, and data packet loss rate is recorded as a percentage, retaining two decimal places. The collected elements are synchronously recorded in a temporary traceability cache with a capacity of 10GB, employing a first-in, first-out (FIFO) storage strategy. In the data access and decryption process, 12 pieces of information are collected, including the access request node identifier, access request time, access permission verification result, access data identifier, decryption operation executor's identity identifier, decryption key usage record, decryption time, and the purpose of the decrypted data. The access permission verification result is categorized into three types: passed, failed, and pending review. The purpose of the decrypted data is recorded according to a preset code. All information is correlated and matched with the access logs of the data shards to ensure that each operation can be traced back to a specific node and executor. Finally, the system integrates the data in the temporary traceability cache with the traceability elements collected in each stage, sorts them by timestamp, removes duplicate and invalid data, and generates a complete traceability log. Each log entry includes 28 core fields and undergoes integrity verification by no fewer than 15 nodes through a blockchain consensus mechanism. After successful verification, the logs are stored in an immutable blockchain block. Each block stores a maximum of 10,000 log entries, and the block generation interval is set to 10 minutes to ensure the security and continuity of the traceability data.

[0023] S6, based on the risk warning threshold and abnormal behavior identification rules in the medical information privacy and security management parameters, performs real-time analysis of the traceability logs, verifies the legality of data operations through a multi-chain collaborative verification mechanism, and triggers corresponding privacy and security control responses.

[0024] Specifically, step S6 conducts source tracing log analysis and privacy security control based on medical information privacy and security management parameters. First, it clarifies core parameter settings, with risk warning thresholds categorized according to data sensitivity levels: Level 1 data risk warning threshold is set at 0.3, Level 2 at 0.45, Level 3 at 0.6, and Level 4 at 0.75. These thresholds are derived through statistical analysis of historical risk event data and are dynamically adjusted quarterly based on the latest security situation. Abnormal behavior identification rules include 18 specific scenarios, such as unauthorized node access, viewing data beyond permissions, high-frequency data access, abnormal time-end operations, abnormal data transmission paths, and unauthorized use of decryption keys. Each rule has clearly defined judgment criteria; for example, high-frequency data access is defined as the same node accessing the same data more than 50 times within one hour. During implementation, the system continuously analyzes source tracing logs using real-time data stream processing technology. A distributed computing framework distributes log data to multiple analysis nodes for parallel processing. Each analysis node is responsible for a specific type of log analysis task, with analysis efficiency controlled at over 1000 logs per second. During the analysis, the legality of data operations is verified through a multi-chain collaborative verification mechanism. Each operation requires cross-verification by three types of nodes: the initiating node, the storage node, and the monitoring node. Verification content includes the permissions of the operating node, the compliance of the operation instructions, and the standardization of the data processing flow. When the analysis results show that the operation conforms to the abnormal behavior identification rules and the risk value exceeds the warning threshold of the corresponding sensitivity level, the system triggers the corresponding privacy and security control response. The control response is divided into four levels: Level 1 response includes freezing the permissions of the violating node, blocking data transmission, and reporting to the higher-level regulatory department; Level 2 response includes restricting the node's access scope, sending warning notifications, and recording the violation; Level 3 response includes sending reminder messages and strengthening data monitoring; and Level 4 response includes log marking and continuous tracking. Simultaneously, the system stores the control response results and operation logs on the blockchain, forming a complete security control closed loop to ensure that medical information privacy and security risks are dealt with promptly and effectively.

[0025] Preferably, the expression for the multi-chain collaborative privacy protection model is: ,in, Output values ​​for the multi-chain collaborative privacy protection model. The correlation coefficient between node identity and credibility. Let be the distributed identity identifier value of the i-th node. Let be the historical interaction credibility weight of the i-th node. Here, Cons represents the compatibility coefficient between the consensus mechanism and multi-chain collaboration, and Cons represents the performance value of the blockchain consensus mechanism. Let j be the degree of collaborative participation of the j-th chain. This is a coefficient for adjusting privacy constraints and security policies. For the k-th privacy protection rule, Let n be the node access permission threshold corresponding to the k-th rule, and n be the total number of participating nodes. The number of privacy protection rules.

[0026] Specifically, the multi-chain collaborative privacy protection model is used to achieve identity authentication and permission adaptation for participating institutional nodes in medical information interaction. Its implementation requires the use of multi-dimensional technical parameters and quantitative calculation logic. During the model calculation process, the correlation coefficient between node identity and trustworthiness is set to a range of 0.6 to 0.9. This coefficient is determined through statistical analysis of historical node interaction data and directly affects the correlation strength between node identity identifier and trustworthiness weight. The total number of participating nodes is dynamically adjusted according to the actual medical collaboration scenario, typically covering 20 to 50 institutional nodes. The distributed identity identifier value of each node is generated using 32-bit binary encoding to ensure uniqueness and unforgeability. The historical interaction trustworthiness weight is calculated by weighting eight indicators, including the node's data sharing compliance rate, number of privacy and security violations, and data transmission stability over the past 12 months. The weight range is 0 to 1, with the compliance rate indicator accounting for 30% and the number of violations accounting for 25%. The consensus mechanism and multi-chain collaboration adaptation coefficient are determined based on the selected consensus algorithm type. The coefficient for the practical Byzantine fault-tolerant algorithm is 0.75, and for the proof-of-work algorithm, it is 0.58. The blockchain consensus mechanism performance value is comprehensively evaluated using two parameters: node consensus response time and consensus success rate, with a value range of 0.5 to 1. The privacy constraint and security policy adjustment coefficient is fixed at 0.8. The number of privacy protection rules is set to 15 to 20 according to medical privacy and security management specifications. The node access permission threshold for each rule is divided into 5 levels according to data sensitivity, with level 1 corresponding to the highest permission. The model outputs the multi-chain collaborative privacy protection result through weighted summation, product operation, and difference calculation of the above parameters. This provides a quantitative basis for the validity of node identity authentication and the rationality of permission allocation, ensuring that only legitimate nodes obtain the corresponding privacy access permissions and guaranteeing the security of medical information interaction.

[0027] Preferably, the expression for the lightweight encryption / decryption algorithm for the blockchain is: ,in, This is the encrypted data string output by a lightweight encryption / decryption algorithm. For symmetric encryption operators, To calibrate diagnostic and treatment data, Assigning coefficients to encryption strength. It is an asymmetric encryption operator. For the patient's basic information, For hash functions, The hash value of the original medical information data. For temporary session keys, For digit-by-digit multiplication operator, It is the XOR operator.

[0028] Specifically, the lightweight blockchain encryption / decryption algorithm aims to achieve efficient encryption and secure decryption of medical information, balancing encryption strength and processing efficiency. Its implementation revolves around multiple technical parameters and operator operations. The encryption strength allocation coefficient is dynamically adjusted according to the sensitivity level of the medical information. The coefficient for core diagnostic data ranges from 0.8 to 0.95, while the coefficient for basic patient information ranges from 0.6 to 0.75. This coefficient directly determines the weighting of symmetric and asymmetric encryption. The symmetric encryption operator uses the Advanced Encryption Standard (AES), with key lengths set to 128, 192, or 256 bits depending on the sensitivity level. The asymmetric encryption operator uses the Elliptic Curve Cryptography (ECC) algorithm, with key lengths set to 192, 224, or 256 bits respectively. When the two encryption methods are combined, symmetric encryption is used first to process the data body to ensure efficiency, and then asymmetric encryption is used to protect the symmetric key to improve security. The hash function uses the SHA-256 algorithm to generate a 256-bit hash value from the original medical information data. This hash value is used for subsequent ciphertext integrity verification. Temporary session keys are dynamically generated through a key negotiation protocol between blockchain nodes. The key validity period is set to 24 hours, and it is automatically renewed upon expiration to avoid security risks associated with long-term key use. A bitwise multiplication operator is used to perform bitwise operations on encrypted data and hash values, enhancing the randomness of the ciphertext. An XOR operator is used to further encrypt the result using the temporary session key, further increasing the difficulty of cracking the ciphertext. During algorithm implementation, core diagnostic data and basic patient information are first distinguished. Encryption operations are performed according to the corresponding parameters, generating an encrypted data string including a data identifier, encryption level, ciphertext body, and checksum. Decryption follows the reverse process, ensuring data integrity and legitimacy through hash value verification and key verification, thus protecting the privacy of medical information during storage and transmission.

[0029] Preferably, the expression for the cross-agency privacy collaborative governance model is: CIPGM is the adaptation value for the cross-organizational privacy collaborative governance model. The contribution to privacy protection of the p-th institution, This is the smart contract code value for the corresponding organization. This serves as a compliance verification coefficient for the organization. For the privacy compliance level of the r-th organization, Let be the privacy rule mapping coefficient for the r-th institution. This is a dynamic adjustment factor, where base is the logarithmic base. q represents the number of dynamic privacy rules, t represents the total number of institutions participating in collaborative governance, and t represents the total number of privacy rule types.

[0030] Specifically, the cross-institutional privacy collaborative governance model addresses the issues of inconsistent privacy rules and insufficient compliance in data sharing among multiple institutions. Its implementation involves multi-parameter calculations and rule adaptation. The total number of participating institutions includes medical institutions, testing institutions, and regulatory agencies, typically ranging from 10 to 30. Each institution's contribution to privacy protection is comprehensively evaluated based on six indicators, including the completeness of its privacy rules, compliance rate, and data sharing cooperation, with values ​​ranging from 0 to 1. The compliance rate accounts for 35%, and the rule completeness accounts for 30%. The smart contract code value for each institution is generated by converting structured privacy rules into contract code. Each rule corresponds to a unique code, with a code length of 16 bits. The institutional compliance verification coefficient is fixed at 0.9, used to adjust the weight of institutional compliance on the model results. The total number of privacy rule types is divided into 8 to 12 categories based on data access, data sharing, data storage, and data destruction. The privacy compliance level of each rule category is divided into 3 levels according to the strictness of compliance requirements, with level 1 corresponding to the highest compliance standard. The privacy rule mapping coefficient is used to quantify the degree of adaptability between rules of different institutions, with a value range of 0.5 to 1. The dynamic adjustment factor has a value of 0.7 to 0.85, with the logarithmic base fixed as the natural constant e. The number of dynamic privacy rules is updated in real time according to institutional business adjustments, policy and regulatory updates, etc., with a regular update frequency of once a month. The model outputs a cross-institutional privacy collaborative governance adaptation value by summing the product of the institutional contribution and contract code value in the numerator, summing the product of the compliance level and mapping coefficient in the denominator, and performing subsequent division, logarithmic, and addition operations. When the adaptation value is higher than 0.8, the rules are considered to be well adapted, and data sharing can be carried out directly. When the adaptation value is between 0.6 and 0.8, the rules need to be optimized according to the conflict resolution scheme before sharing. When the adaptation value is lower than 0.6, cross-institutional data sharing is prohibited to ensure the compliance and privacy security of multi-institutional data sharing.

[0031] Preferably, the expression for assessing the traceability integrity of the blockchain-based medical privacy traceability platform is: ,in, This is the traceability integrity assessment value. Weighting for the integrity of traceability records. This represents the actual number of traceability records collected. This represents the total number of traceability records that should theoretically be collected. As a weight for the validity of traceability elements, This serves as the validity identifier for the s-th traceability timestamp. Let be the credibility value of the s-th operation node, and I be the total number of traceability elements.

[0032] Specifically, the blockchain-based medical privacy traceability platform uses a traceability integrity assessment expression to quantitatively evaluate the integrity and validity of traceability data, providing a reliable basis for tracing medical information throughout its entire lifecycle. Its implementation utilizes multiple traceability parameters and weighted calculation logic. The traceability record integrity weight is fixed at 0.6, emphasizing the core impact of the actual number of collected traceability records on the assessment results. The theoretically required total number of traceability records to be collected is determined according to the entire lifecycle of medical information, including four core stages: encryption, transmission, access, and decryption. Each stage corresponds to 5 to 8 mandatory traceability elements, totaling 25 to 30 items. The actual number of collected traceability records is statistically analyzed in real-time by the platform, with a frequency of once per second to ensure data timeliness. The traceability element validity weight is fixed at 0.4. The total number of traceability elements is consistent with the theoretically required total number of traceability records to be collected. The validity identifier of each traceability timestamp is determined through timestamp format verification and time rationality verification. A successful verification is marked as 1, and a failed verification is marked as 0. The credibility value of the operating node is consistent with the historical interaction credibility weight of the node in weight 2, ranging from 0 to 1. The model calculates the traceability integrity assessment value by combining the ratio of the actual number of collected records to the theoretical total number, along with the product of the timestamp validity identifier and the node credibility value, and then performing a weighted summation. The assessment value ranges from 0 to 1. An assessment value higher than 0.95 is considered to indicate complete and valid traceability. An assessment value between 0.8 and 0.95 requires the supplementation of missing traceability data. An assessment value lower than 0.8 requires investigation of faults in the traceability collection process. This ensures that the traceability log can comprehensively and accurately reflect the entire process of medical information operation, providing support for privacy and security traceability and liability determination.

[0033] Preferably, the risk warning expression for medical information privacy and security management is: ,in, This is a risk warning value. This represents the impact coefficient of abnormal behavior. Let u be the frequency of occurrence of the u-th abnormal behavior. Let u be the risk threshold for the uth abnormal behavior. For the safety management efficiency coefficient, To ensure the effectiveness of the implementation of the wth safety control measure, Let be the weight of the w-th security control measure, v be the total number of abnormal behavior types, and x be the total number of security control measures.

[0034] Specifically, the medical information privacy and security management risk early warning expression is used to identify medical information privacy and security risks in real time, providing a quantitative basis for risk control. Its implementation revolves around abnormal behavior monitoring and security control effectiveness evaluation. The abnormal behavior impact coefficient ranges from 0.7 to 0.9, used to strengthen the impact of abnormal behavior on risk early warning results. The total number of abnormal behavior types is divided into 15 to 20 categories according to the operation violation scenario, including unauthorized access, exceeding permissions, high-frequency access, and abnormal time operation. The frequency of each abnormal behavior is statistically analyzed in real time through source tracing logs, with a statistical period of 5 minutes. The risk threshold is divided into 3 levels according to the severity of abnormal behavior: the threshold for high-risk behavior is set to 5 times / cycle, the threshold for medium-risk behavior is set to 10 times / cycle, and the threshold for low-risk behavior is set to 15 times / cycle. The security control effectiveness coefficient is fixed at 0.85. The total number of security control measures is divided into 12 to 18 items according to the protection links, including identity authentication, encryption protection, access control, and traceability monitoring. The execution effectiveness of each security control measure is comprehensively evaluated by three indicators: measure activation rate, execution success rate, and fault repair time, with values ​​ranging from 0 to 1. The execution effectiveness weight is allocated according to the importance of the measures, with identity authentication and encryption protection measures each accounting for 20% of the weight, and the remaining measures allocated proportionally. The model obtains the risk warning value by summing the products of the frequency of abnormal behavior and the corresponding risk threshold, and subtracting the product of the square root of the weighted sum of the execution effectiveness of security control measures and the effectiveness coefficient. When the warning value is higher than 0.7, a level 1 warning is triggered, requiring immediate freezing of the permissions of the violating node and reporting to the regulatory authorities; when the warning value is between 0.5 and 0.7, a level 2 warning is triggered, restricting the node's access range and sending a warning notification; when the warning value is lower than 0.5, it is determined to be in a safe state. This hierarchical warning mechanism achieves precise prevention and control of privacy and security risks.

[0035] Preferred, such as Figure 2 As shown, S3 includes the following sub-steps: S31, extracting the internal rules for medical information privacy protection of each participating institution, including data access permission scope, data sharing boundaries, and privacy information confidentiality period marking rule elements, and converting unstructured rules into structured data format using natural language processing technology; S32, based on the syntax specifications of blockchain smart contracts, encoding the structured privacy rules of each institution into smart contract code fragments, clarifying the rule triggering conditions, execution logic, and violation handling methods; S33, constructing a cross-institutional privacy rule conflict detection matrix, comparing and analyzing the rule differences between different institutions, determining the conflict resolution priority based on the medical information privacy protection marking principle, and generating a unified rule adaptation scheme; S34, merging the encoded smart contract code fragments with the rule adaptation scheme, deploying them to the blockchain main chain node, and ensuring the consistency and effectiveness of the cross-institutional data sharing privacy constraint protocol through multi-node consensus verification.

[0036] Specifically, step S3 achieves standardization and collaborative adaptation of cross-institutional privacy rules through four sub-steps, ensuring privacy compliance for data sharing among multiple institutions. Step S31 first connects to the privacy protection systems of participating institutions through standardized interfaces, comprehensively extracting core rule elements such as data access permission scope, data sharing boundaries, and privacy information confidentiality periods, involving eight key rule dimensions. Then, natural language processing technology is used to transform the unstructured rule text into a structured data format. Structured fields include rule categories, constraints, and applicable scenarios. A semantic consistency verification mechanism is set up during the transformation process to ensure that the core meaning of the rules remains accurate. Step S32, based on smart contract syntax specifications, encodes the structured privacy rules of each institution into independent contract code fragments. Each code fragment clearly defines the rule triggering conditions, execution logic, and violation handling methods. Code fragments must pass syntax verification and logic testing; a pass rate of over 99% is required to proceed to the next step. In step S33, a cross-institutional privacy rule conflict detection matrix is ​​constructed. The matrix dimensions are consistent with the number of participating institutions. A similarity algorithm is used to compare the constraints and execution standards of rules between different institutions to identify rule conflicts. Then, based on the principles of prioritizing patient rights and compliance, the priority of conflict resolution is determined, and a unified rule adaptation scheme is generated. The accuracy of conflict resolution must meet the needs of practical applications. In step S34, the coded smart contract code snippets are deeply integrated with the rule adaptation scheme to form a complete cross-institutional data sharing privacy constraint protocol. This protocol is then deployed to 10 core nodes and 20 backup nodes on the blockchain main chain. Multi-node consensus verification ensures the consistency and effectiveness of the protocol. The protocol officially takes effect when the verification pass rate reaches over 95%, providing unified privacy rule support for cross-institutional data sharing.

[0037] Preferred, such as Figure 3 As shown, step S4 includes the following sub-steps: S41, based on the type, size, and sensitivity level of the medical information data, set a threshold for the data shard size and an upper limit for the number of shards, and use a consistent hashing algorithm to calculate the hash value of the data shards to determine the sharding logic; S42, according to the sharding logic, split the encrypted medical information data into several data shards, assign a unique identifier code to each data shard, and record the association between each shard and the original data; S43, query the storage resource status and load of the blockchain multi-chain nodes, and based on the load balancing principle, allocate the data shards to the optimal storage nodes, and update the node storage directory and data shard index; S44, encrypt the mapping relationship between the data shard index and the storage node address and store it in the blockchain traceability chain to ensure the traceability and location accuracy of the data shards.

[0038] Specifically, step S4 implements secure data sharding and distributed storage of encrypted data through four sub-steps, balancing storage security and data accessibility. Step S41 establishes differentiated sharding strategies based on the data type, size, and sensitivity level of the medical information. Data types include text, images, and audio; sensitivity levels are divided into four levels, each with different shard size thresholds and upper limits on the number of shards. Level 1 sensitive data has a shard size limit of 512 bytes and a shard count of 8 to 12; Level 4 sensitive data has a shard size limit of 4096 bytes and a shard count of 12 to 16. A consistent hashing algorithm is then used to calculate the hash value of each data shard, determining the sharding logic. The hash value calculation result is used for subsequent data integrity verification. Step S42 splits the encrypted medical information data into several data shards according to the preset splitting logic, assigning a unique identifier code to each data shard. The code consists of a 16-bit institution identifier, an 8-bit data type identifier, and a 12-bit shard sequence number. Detailed records are also kept of the relationship between each shard and the original data, including the original data identifier, the shard's position within the original data, and the shard assembly order. In step S43, the storage resource status and load of multi-chain nodes in the blockchain are queried in real time. Parameters such as remaining storage space, CPU utilization, and network bandwidth utilization are collected. Nodes with remaining storage space greater than three times the shard size and CPU utilization below 70% are considered as candidate storage nodes. Subsequently, based on the load balancing principle, data shards are allocated to the optimal storage nodes, and the node storage directory and data shard index are updated to ensure that different shards of the same original data are stored on nodes of different chains, improving data resistance to attacks. In step S44, a symmetric encryption algorithm is used to encrypt the mapping relationship between the data shard index and the storage node address. The encryption key is jointly managed by the multi-chain nodes. The encrypted mapping relationship is then stored in a designated block of the blockchain traceability chain to ensure the traceability and location accuracy of data shards, providing basic support for subsequent data access and traceability.

[0039] Preferred, such as Figure 4As shown, S5 includes the following sub-steps: S51, in the medical information encryption stage, collecting encryption algorithm type, encryption key identifier, encryption start and end time operation data, and associating them with the unique identifier code of the corresponding data shard; S52, during data transmission, capturing data transmission path, transmission node sequence, transmission delay and other relevant traceability elements through the real-time communication protocol between blockchain nodes, and synchronously recording them in the temporary traceability cache; S53, in the data access and decryption stage, collecting access request node identifier, access permission verification result, decryption operation executor identity identifier, and decryption time information, and associating and matching them with the access log of the data shard; S54, integrating the data in the temporary traceability cache with the traceability elements collected in each stage, sorting them by timestamp order to generate a complete traceability log, verifying the integrity of the log through the blockchain consensus mechanism, and storing it in an immutable blockchain block.

[0040] Specifically, step S5 comprehensively collects medical information lifecycle traceability data through four sub-steps, generating an immutable traceability log to provide a reliable basis for privacy and security tracing. Step S51 initiates data collection during the medical information encryption process, capturing seven operational data items in real time, including encryption algorithm type, encryption key identifier, encryption start time, encryption end time, and encryption node identifier. Time is recorded to millisecond accuracy, and node identifiers use globally unique codes. All collected data is associated and bound to the unique identifier code of the corresponding data segment, ensuring that data operations can be accurately traced to specific data objects. Step S52, during data transmission, captures ten traceability elements, including data transmission path, transmission node sequence, transmission delay, and data packet loss rate, through the real-time communication protocol between blockchain nodes. Transmission delay is recorded to microsecond accuracy, and the data packet loss rate is recorded as a percentage and retained to two decimal places. The collected elements are synchronously stored in a 10GB temporary traceability cache, which uses a first-in, first-out (FIFO) storage strategy to avoid data overflow. In step S53, during the data access and decryption phase, 12 pieces of information are comprehensively collected, including the access request node identifier, access request time, access permission verification result, decryption operation executor's identity identifier, and decryption key usage record. Access permission verification results are categorized into three types: passed, failed, and pending review. All collected information is correlated and matched with the access logs of data shards to ensure that each operation can be traced back to a specific node and executor. In step S54, the data in the temporary traceability cache is integrated with the traceability elements collected in each step, sorted by timestamp order, and duplicate and invalid data is removed to generate a complete traceability log including 28 core fields. Subsequently, the integrity is verified by no fewer than 15 nodes through the blockchain consensus mechanism. After successful verification, the traceability log is stored in an immutable blockchain block. Each block stores a maximum of 10,000 log entries, and the block generation interval is set to 10 minutes to ensure the continuity and security of traceability data, providing comprehensive support for subsequent risk analysis and liability determination.

[0041] like Figure 5 As shown, a blockchain-based medical information privacy and security management system is applied to a blockchain-based medical information privacy and security management method. The system includes: an identity authentication and dynamic permission allocation unit, a medical information layered encryption processing unit, a cross-institutional privacy rule resolution and adaptation unit, a distributed storage and index management unit, a multi-dimensional traceability data collection and log generation unit, and a privacy and security risk real-time monitoring and analysis unit. The identity authentication and dynamic permission allocation unit verifies the legitimacy of participating institution nodes through a blockchain consensus mechanism, generates and outputs node-specific privacy access permissions to the medical information layered encryption processing unit, providing a permission basis for subsequent data encryption. After receiving the permission credentials, the medical information layered encryption processing unit performs differentiated encryption operations based on the medical information sensitivity level classification results, and transmits the encrypted data to the cross-institutional privacy rule... The cross-institutional privacy rule resolution and adaptation unit encodes and resolves conflicts in the privacy rules associated with encrypted data from various institutions, generating a compliant and compatible cross-institutional data sharing protocol. The data bound to this protocol is then sent to the distributed storage and index management unit. This unit splits and stores the data according to the blockchain storage architecture, while simultaneously synchronizing the storage index information to the multi-dimensional traceability data collection and log generation unit. The multi-dimensional traceability data collection and log generation unit collects operational data from each unit in real time, generating traceability logs, which are then transmitted to the privacy and security risk real-time monitoring and analysis unit. This unit analyzes the logs, identifies risks, and sends permission adjustment instructions to the identity authentication and dynamic permission allocation unit. All units interact and collaborate through the blockchain network, forming a closed-loop medical information privacy and security management chain.

[0042] This blockchain-based medical information privacy and security management method and system achieves distributed identity authentication and dynamic permission allocation through a multi-chain collaborative mechanism. Combined with a layered encryption strategy, it implements differentiated protection for medical information of different sensitivity levels, ensuring both core data security and data processing efficiency. A cross-institutional privacy collaborative governance model, combined with smart contracts, transforms the independent privacy rules of various institutions into a unified and compatible shared protocol, resolving cross-institutional rule conflicts and adaptation challenges. At the system level, encrypted data sharding and distributed storage enhance data resistance to attacks, and a full lifecycle traceability platform comprehensively captures operational elements at each stage. Coupled with multi-chain collaborative verification and risk warning mechanisms, it enables real-time identification and rapid response to abnormal behavior. This invention addresses the problem of imperfect cross-institutional privacy collaboration mechanisms by extracting privacy rules from various institutions and converting them into a structured format. After conflict detection and resolution, these rules are encoded into smart contracts, forming a dynamically adaptable cross-institutional shared constraint protocol to ensure data sharing compliance. Addressing the imbalances in traditional encryption strategies and the weak connection between traceability and control, this invention employs a lightweight algorithm that integrates symmetric and asymmetric encryption, combined with sensitivity levels to achieve layered encryption. Simultaneously, it generates immutable logs through end-to-end traceability data collection, linking risk analysis models and access control units to construct a closed-loop chain of authentication-encryption-storage-traceability-control. This enables precise prevention and real-time response to privacy security risks, comprehensively improving the integrity, collaboration, and reliability of medical information privacy security management.

[0043] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various equivalent changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A blockchain-based method for managing the privacy and security of medical information, characterized in that: Includes the following steps: S1. Through the node identity allocation mechanism in the multi-chain collaborative privacy protection model, distributed identity authentication is performed on the nodes of various institutions participating in medical information interaction. Based on the node's historical interaction credibility weight and the correlation factor of the blockchain consensus mechanism, a node-specific privacy access certificate is generated. S2. A lightweight blockchain encryption and decryption algorithm is used to perform layered encryption processing on the original medical information data. Combined with the results of medical information sensitivity level classification, symmetric and asymmetric encryption fusion operations with different encryption strengths are performed on the labeled diagnosis and treatment data and patient basic information respectively. S3. A multi-institutional privacy rule mapping system is constructed using a cross-institutional privacy collaborative governance model. The privacy protection compliance requirements of each institution are encoded through blockchain smart contracts, forming a dynamically adaptable cross-institutional data sharing mechanism. Enjoy privacy constraint agreements; S4, split the encrypted medical information data according to the preset sharding strategy, combine the blockchain distributed storage architecture, and distribute the data shards to multiple chain nodes, while recording the mapping relationship between the data shard index and the storage node address; S5, collect the entire life cycle operation data of medical information through the blockchain medical privacy traceability platform, including the timestamps, operation node identifiers, and operation behavior type traceability elements of each stage of data encryption, transmission, access, and decryption, and generate an immutable traceability log; S6, based on the risk warning threshold and abnormal behavior identification rules in the medical information privacy and security management parameters, perform real-time analysis of the traceability log, verify the legality of data operations through a multi-chain collaborative verification mechanism, and trigger the corresponding privacy and security control response.

2. The blockchain-based medical information privacy and security management method according to claim 1, characterized in that, The expression for the multi-chain collaborative privacy protection model is: ,in, Output values ​​for the multi-chain collaborative privacy protection model. The correlation coefficient between node identity and credibility. Let be the distributed identity identifier value of the i-th node. Let be the historical interaction credibility weight of the i-th node. Here, Cons represents the compatibility coefficient between the consensus mechanism and multi-chain collaboration, and Cons represents the performance value of the blockchain consensus mechanism. Let j be the degree of collaborative participation of the j-th chain. This is a coefficient for adjusting privacy constraints and security policies. For the k-th privacy protection rule, Let n be the node access permission threshold corresponding to the k-th rule, and n be the total number of participating nodes. The number of privacy protection rules.

3. The blockchain-based medical information privacy and security management method according to claim 1, characterized in that, The expression for the lightweight encryption / decryption algorithm for the blockchain is: ,in, Here, the encrypted data string is the output of the lightweight encryption / decryption algorithm. For symmetric encryption operators, To calibrate diagnostic and treatment data, Assigning coefficients to encryption strength. It is an asymmetric encryption operator. For the patient's basic information, For hash functions, The hash value of the original medical information data. For temporary session keys, For digit-by-digit multiplication operator, It is the XOR operator.

4. The blockchain-based medical information privacy and security management method according to claim 1, characterized in that, The expression for the cross-agency privacy collaborative governance model is: CIPGM is the adaptation value for the cross-organizational privacy collaborative governance model. The contribution to privacy protection of the p-th institution, This is the smart contract code value for the corresponding organization. This serves as a compliance verification coefficient for the organization. For the privacy compliance level of the r-th organization, Let be the privacy rule mapping coefficient for the r-th institution. This is a dynamic adjustment factor, where base is the logarithmic base. q represents the number of dynamic privacy rules, t represents the total number of institutions participating in collaborative governance, and t represents the total number of privacy rule types.

5. The blockchain-based medical information privacy and security management method according to claim 1, characterized in that, The expression for assessing the integrity of traceability of the blockchain-based medical privacy traceability platform is as follows: ,in, This is the traceability integrity assessment value. Weighting for the integrity of traceability records. This represents the actual number of traceability records collected. This represents the total number of traceability records that should theoretically be collected. As a weight for the validity of traceability elements, This serves as the validity identifier for the s-th traceability timestamp. Let be the credibility value of the s-th operation node, and I be the total number of traceability elements.

6. The blockchain-based medical information privacy and security management method according to claim 1, characterized in that, The risk warning expression for medical information privacy and security management is as follows: ,in, value, This represents the impact coefficient of abnormal behavior. Let u be the frequency of occurrence of the u-th abnormal behavior. Let u be the risk threshold for the uth abnormal behavior. For the safety management efficiency coefficient, To ensure the effectiveness of the implementation of the wth safety control measure, Let be the weight of the w-th security control measure, v be the total number of abnormal behavior types, and x be the total number of security control measures.

7. The blockchain-based medical information privacy and security management method according to claim 1, characterized in that, S3 includes the following steps: S31, extracting the internal rules for medical information privacy protection from each participating institution, including data access permission scope, data sharing boundaries, and privacy information confidentiality period setting rules, and converting unstructured rules into structured data format using natural language processing technology; S32, based on the syntax specifications of blockchain smart contracts, encoding the structured privacy rules of each institution into smart contract code fragments, clarifying the rule triggering conditions, execution logic, and violation handling methods; S33, constructing a cross-institutional privacy rule conflict detection matrix, comparing and analyzing the rule differences between different institutions, determining the conflict resolution priority based on the medical information privacy protection setting principles, and generating a unified rule adaptation scheme; S34, integrating the encoded smart contract code fragments with the rule adaptation scheme, deploying them to the blockchain main chain node, and ensuring the consistency and effectiveness of the cross-institutional data sharing privacy constraint protocol through multi-node consensus verification.

8. The blockchain-based medical information privacy and security management method according to claim 1, characterized in that, The S4 includes the following steps: S41, based on the type, size and sensitivity level of the medical information data, set a data shard size threshold and a shard quantity limit, use a consistent hashing algorithm to calculate the hash value of the data shard, and determine the shard splitting logic; S42, according to the splitting logic, split the encrypted medical information data into several data fragments, assign a unique identifier code to each data fragment, and record the association relationship between each fragment and the original data; S43, query the storage resource status and load of the blockchain multi-chain nodes, allocate the data fragments to the optimal storage nodes based on the load balancing principle, and update the node storage directory and data fragment index; S44 encrypts the mapping relationship between the data shard index and the storage node address and stores it in the blockchain traceability chain to ensure the traceability and location accuracy of the data shards.

9. The blockchain-based medical information privacy and security management method according to claim 1, characterized in that, S5 includes the following steps: S51, in the medical information encryption stage, collecting encryption algorithm type, encryption key identifier, encryption start and end time operation data, and associating them with the unique identifier code of the corresponding data segment; S52, during the data transmission process, capturing data transmission path, transmission node sequence, transmission delay and other relevant traceability elements through the real-time communication protocol between blockchain nodes, and synchronously recording them to the temporary traceability cache. S53, in the data access and decryption stage, collect the access request node identifier, access permission verification result, decryption operation executor identity identifier, and decryption time information, and associate and match them with the access log of the data shard; S54, integrate the data in the temporary traceability cache with the traceability elements collected in each stage, sort them in the order of timestamps to generate a complete traceability log, verify the integrity of the log through the blockchain consensus mechanism, and store it in an immutable blockchain block.

10. A blockchain-based medical information privacy and security management system, characterized in that, The system is applied to the blockchain-based medical information privacy and security management method described in claim 1, comprising: an identity authentication and dynamic permission allocation unit, a medical information layered encryption processing unit, a cross-institutional privacy rule decryption and adaptation unit, a distributed storage and index management unit, a multi-dimensional traceability data collection and log generation unit, and a privacy and security risk real-time monitoring and analysis unit; the identity authentication and dynamic permission allocation unit verifies the legality of the participating institution nodes through a blockchain consensus mechanism, generates and outputs node-specific privacy access permission certificates to the medical information layered encryption processing unit, providing a permission basis for subsequent data encryption; after receiving the permission certificates, the medical information layered encryption processing unit performs differentiated encryption operations according to the medical information sensitivity level classification results, and transmits the encrypted data to the cross-institutional privacy rule decryption and adaptation unit; The cross-institutional privacy rule resolution and adaptation unit encodes and resolves conflicts in the privacy rules of various institutions associated with encrypted data, generating a compliant and adaptable cross-institutional data sharing protocol. The data bound to this protocol is then sent to the distributed storage and index management unit. The distributed storage and index management unit splits and stores the data according to the blockchain storage architecture, while simultaneously synchronizing the storage index information to the multi-dimensional traceability data collection and log generation unit. This unit collects operational data from each unit in real time, generates traceability logs, and transmits them to the privacy and security risk real-time monitoring and analysis unit. The unit analyzes the logs, identifies risks, and sends permission adjustment instructions to the identity authentication and dynamic permission allocation unit. All units interact and collaborate through the blockchain network, forming a closed-loop medical information privacy and security management chain.

Images