Blockchain-based peritoneal dialysis data security sharing and traceability system

Abstract

This invention provides a blockchain-based peritoneal dialysis data security sharing and traceability system, comprising: a data sensing module that collects data from hospital information systems and patient equipment, and encrypts and stores the data after adding source identifiers, timestamps, and digital signatures; a data storage and authorization module that implements data hash storage, fine-grained access control, and full-process operation traceability based on a consortium blockchain network; and a collaborative analysis module that supports multi-node privacy computing under authorized conditions, enabling cross-institutional data joint analysis. This invention utilizes the immutability and traceability of blockchain, combined with national cryptographic algorithms and privacy computing technology, to improve the sharing efficiency and collaborative analysis capabilities of peritoneal dialysis data while ensuring data security and patient privacy.

Description

Technical Field

[0001] This invention relates to the intersection of medical informatics and blockchain technology, specifically a blockchain-based peritoneal dialysis data security sharing and traceability system. Background Technology

[0002] Peritoneal dialysis is an important home-based treatment for patients with end-stage renal disease. Its efficacy assessment and long-term management heavily rely on continuous, multi-dimensional, and high-quality treatment data. This data originates not only from hospital information systems but also extensively from IoT devices used by patients at home, such as smart peritoneal dialysis machines, scales, and blood pressure monitors, exhibiting characteristics of being multi-source, heterogeneous, and high-frequency. Currently, this data is mostly scattered and stored within various medical institutions or on isolated patient devices, forming data silos. This hinders efficient cross-institutional and cross-regional clinical research, efficacy comparisons, and collaborative management, thus restricting the overall improvement of peritoneal dialysis treatment and the development of personalized medicine.

[0003] However, existing technological solutions face several significant shortcomings in attempting to break down data silos and promote data sharing and collaborative analysis. First, data security and patient privacy protection face severe challenges. Traditional centralized sharing models suffer from single points of failure and internal tampering risks, and lack reliable, immutable records of the entire data flow process. Once data leakage or misuse occurs, it is difficult to trace the source of responsibility. Second, existing sharing mechanisms often lack granular access control. They cannot achieve differentiated data authorization for different roles while protecting patient privacy, resulting in data that is either excessively closed or excessively open. Furthermore, cross-institutional collaborative analysis usually requires the aggregation of raw data, posing legal and ethical risks of privacy breaches, while traditional anonymization or aggregation methods may compromise data value and analytical accuracy. Summary of the Invention

[0004] To address the technical problems mentioned in the background section, this invention proposes a blockchain-based peritoneal dialysis data security sharing and traceability system.

[0005] Therefore, the technical solution adopted by the present invention is as follows: A blockchain-based peritoneal dialysis data security sharing and traceability system includes: Data sensing module: Collects peritoneal dialysis data from the hospital's information system and the patient's peritoneal dialysis equipment; when the peritoneal dialysis data is generated, it adds a data source identifier and timestamp, and generates a digital signature; then it encrypts the peritoneal dialysis data and stores it in the corresponding hospital's secure storage system; Control module: Constructs a consortium blockchain network with multiple medical stakeholders as nodes. The consortium blockchain network includes an evidence storage unit, an authorization unit, and a traceability unit. The evidence storage unit is used to calculate the cryptographic hash value of the encrypted peritoneal dialysis data and store it in the consortium blockchain network. The authorization unit is used to verify and authorize data operation requests. The traceability unit is used to verify the integrity and operation trajectory of the peritoneal dialysis data. Collaborative Analysis Module: For collaborative analysis requests, the authorization unit coordinates each node to process the encrypted peritoneal dialysis data using privacy computing technology and outputs joint analysis results.

[0006] Furthermore, the data source identifier on the hospital side is the system identity information of the data source, which includes a unique hospital code, a system type identifier, and a system trusted number; The data source identifier on the patient side is the device identifier of the peritoneal dialysis device on the patient side.

[0007] Furthermore, the nodes include data provision and verification nodes, monitoring nodes, controlled query nodes, and consensus and ledger nodes; The data provision and verification nodes are provided by the hospital's peritoneal dialysis center; The regulatory nodes are managed by regional medical and health management agencies. The controlled query nodes are operated by research institutions with medical research qualifications; The consensus and ledger nodes are selected from the data providing and verification nodes based on preset filtering criteria.

[0008] Furthermore, the node includes a key pair and a node identifier based on the SM2 elliptic curve public key cryptography algorithm; The node identifier is obtained by calculating the node's feature set using the national cryptographic SM3 hash algorithm.

[0009] Furthermore, the working process of the evidence storage unit is as follows: The first step is to verify the encrypted peritoneal dialysis data using the public key of the monitoring node. After successful verification, the encrypted data text, device identifier or system identity information, timestamp, and digital signature are extracted from the peritoneal dialysis data. The second step is to use the SM3 cryptographic hash algorithm to calculate the cryptographic hash value of the encrypted data body; The third step is to encapsulate the data into standardized evidence storage blocks in a fixed order of cryptographic hash value, data type, timestamp, device identifier or system trusted number, and digital signature. The fourth step is to broadcast the evidence storage data block to all the consensus and ledger nodes via P2P technology. The consensus and ledger nodes retrieve the corresponding public key from the supervisory node, verify the validity of the digital signature in the evidence storage data block, and then the consensus and ledger nodes use the PBFT algorithm to reach a complete consensus on the legality and validity of the broadcast and verification of the evidence storage data block. The fifth step involves packaging the evidence storage data block into a newly generated block, linking the block to the consortium blockchain network in chronological order, and storing the cryptographic hash value in the consortium blockchain network. The sixth step is to establish a mapping relationship between the storage address of the peritoneal dialysis data and the cryptographic hash value on the consortium blockchain network.

[0010] Furthermore, the working process of the authorization unit is as follows: The first step is that when a patient registers with the system for the first time, the system generates a key pair for the patient based on the SM2 algorithm; The second step involves the patient initiating an authorization strategy, which supports fine-grained dimensional settings. Third, the patient signs the authorization policy using their private key to obtain the authorization policy file; Fourth, after receiving the authorization policy file, the system verifies the validity of the authorization policy file using a public key and then generates a unique authorization token based on the authorization policy file. Fifth, when the data operation initiator submits a data operation request, the authorization unit verifies the data operation initiator and the data operation request; Step 6: After successful verification, the authorization unit generates an authorization execution instruction; The seventh step is to send the authorized execution instruction to the corresponding data source node, which then extracts the corresponding data based on the authorization policy and feeds it back to the data operation initiator.

[0011] Furthermore, the collaborative analysis request can only be initiated through the controlled query node; The collaborative analysis request includes a node identifier, an authorization token signed with the patient's private key, an analysis task description, a unique task identifier, and filing information, and is submitted to the monitoring node. After receiving the collaborative analysis request, the regulatory node verifies the filing information. If the verification is successful, the collaborative analysis request is forwarded to the authorization unit for secondary verification. If the verification is successful, the authorization unit generates a task filing record. The authorization unit issues collaborative analysis task instructions to the data providing and verification nodes involved in the collaborative analysis request; and designates the data providing and verification nodes involved in the collaborative analysis request as participating nodes; After receiving the instruction, the participating node extracts the corresponding peritoneal dialysis data from the secure storage system through the task filing record, and performs joint analysis on the extracted peritoneal dialysis data based on the preset privacy computing technology to obtain the joint analysis result. The privacy-preserving computation technology includes at least federated learning and secure multi-party computation.

[0012] Compared with the prior art, the advantages of the present invention are as follows: 1. This invention constructs a consortium blockchain network to immutably store the cryptographic hash values ​​of data and key operation logs on the blockchain. Combined with digital signatures and fine-grained authorization mechanisms, it ensures that every step of data generation, storage, sharing and use is traceable and auditable, effectively solving the problems of data tampering risk and liability definition in the traditional centralized model.

[0013] 2. By integrating national cryptographic algorithms with privacy computing technology, this invention enables cross-institutional collaborative analysis to be conducted without directly transmitting or decrypting the original patient data, outputting only encrypted joint analysis results, thus fundamentally avoiding the risk of privacy leakage during data sharing.

[0014] 3. Through patient-defined authorization strategies and blockchain smart contract technology, this invention enables the system to achieve refined and dynamic authorization for different requesters, different data ranges, and different operation types. While protecting patient data sovereignty, it improves the efficiency of data sharing and the convenience of collaborative research under security and compliance. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a schematic diagram of the execution flow of the system of the present invention; Figure 2 This is a schematic diagram of the execution flow of the evidence storage unit of the present invention; Figure 3 This is a schematic diagram of the execution flow of the authorized unit of the present invention. Detailed Implementation

[0017] To achieve the above objectives, this invention provides a blockchain-based peritoneal dialysis data security sharing and traceability system. Please refer to [link / reference]. Figure 1 ,include: Data sensing module: Collects peritoneal dialysis data from the hospital's information system and the patient's peritoneal dialysis equipment; when the peritoneal dialysis data is generated, it adds a data source identifier and timestamp, and generates a digital signature; then it encrypts the peritoneal dialysis data and stores it in the corresponding hospital's secure storage system; The procedure for collecting peritoneal dialysis data at the hospital is as follows: By connecting with the hospital's existing information system through a standardized interface, the system can synchronize structured peritoneal dialysis-related data of patients during their hospital stay in real time, including examination results, dialysis prescriptions issued by doctors, peritoneal balance test data, clinical diagnosis and treatment records, etc. During the collection process, the system automatically verifies the consistency of data format and removes invalid and redundant information.

[0018] The peritoneal dialysis data for the patient side mainly focuses on home scenarios, and the specific collection procedure is as follows: The system integrates securely modified IoT devices, including smart peritoneal dialysis machines, electronic scales with Bluetooth communication, blood pressure monitors, and blood glucose meters. These devices establish a stable connection with the patient's mobile app via Bluetooth Low Energy (BLE 5.0) or Wi-Fi, automatically collecting dynamic data during home treatment, such as dialysis fluid infusion volume, drainage volume, ultrafiltration volume, treatment duration, and key indicators monitored at home, including blood pressure, weight, and blood glucose. This replaces traditional manual recording methods and avoids human error.

[0019] The data source identifier on the hospital side is the system identity information of the data source, which includes the hospital's unique code, system type identifier, and system trusted number; The hospital's unique code follows the national medical and health information standards. The system type is clearly identified, and the data comes from HIS (Hospitalization), LIS (Laboratory), or EMR (Electronic Medical Record). The system's trusted number is calculated and generated by the hospital's information department based on the SM3 algorithm, taking into account the system server hardware characteristics and deployment node information, to ensure that the identity information cannot be forged.

[0020] The data source identifier on the patient side is the device identifier of the peritoneal dialysis device on the patient side; Both the hospital's servers and the peritoneal dialysis equipment used by patients are equipped with security units; The logic for generating the device identifier is as follows: The security unit extracts the core feature set of the device hardware and uses the national cryptographic SM3 hash algorithm (hereinafter referred to as SM3 algorithm) to perform a one-way hash operation on the feature set to generate a fixed-length (256-bit) unique device identifier. The core feature set includes the chip's unique serial number, the motherboard's physical code, the device's production batch number, etc.

[0021] The generated device identifier is stored in the read-only storage area of ​​the security unit through a fuse-based write technology. It is permanently bound to the physical entity of the device and can only be read. It cannot be modified or replaced by software tampering, hardware disassembly, or other means, ensuring the uniqueness and immutability of each IoT peritoneal dialysis device.

[0022] The logic for generating timestamps is as follows: The security unit has a built-in high-precision real-time clock (RTC) module. During device initialization, it establishes an encrypted synchronization channel with an authoritative time server certified by the National Time Service Center via the Network Time Protocol (NTP). It automatically performs a time calibration every 24 hours to ensure that the timestamp accuracy is controlled within ±10ms. When the device is offline, the temperature-compensated crystal oscillator built into the security unit maintains the time accuracy, with the cumulative deviation not exceeding 50ms / 24 hours.

[0023] The additional rules for timestamps are as follows: When the patient's peritoneal dialysis device collects dialysis data, the safety unit captures the clock information of the data generation time in real time, generates a timestamp according to the ISO 8601 standard format, and structurally associates the timestamp with the dialysis data and device identifier to form a three-element basic data block of data content, device identifier and timestamp; When the hospital-side information system generates dialysis data, the security unit synchronously captures the clock information of the data confirmation moment, generates a timestamp according to the same ISO 8601 standard format, and structurally associates it with the dialysis data and the identity information of the data source system to form a three-element basic data block of data content, system identity information and timestamp.

[0024] The process of generating a digital signature is as follows: When the security unit leaves the factory, it generates a unique asymmetric key pair, including a private key and a public key, using the national cryptographic SM2 elliptic curve public key cryptography algorithm (hereinafter referred to as the SM2 algorithm). The private key is stored in the encrypted key area of ​​the security unit and protected by hardware isolation technology. It can only be accessed internally by the security unit and is never exported to the device operating system or external terminals. The public key is simultaneously uploaded to the hospital trust list and the consortium blockchain network monitoring node as the legal basis for subsequent data verification. The consortium blockchain network monitoring node is a core component of the consortium blockchain network built by the subsequent evidence storage and authorization module. The hospital trust list is a security whitelist deployed internally by the hospital to store the identity credentials of IoT peritoneal dialysis devices that have legally accessed the system. The core storage content is the public key of each compliant device and the associated basic device information. In essence, it is a device identity trust database at the hospital level, which is uniformly managed by the hospital's information security department.

[0025] The security unit first uses the SM3 algorithm to calculate the hash digest of the ternary basic data block, and then uses the private key to encrypt the hash digest to generate a digital signature.

[0026] The entire signing process is completed within a hardware encryption sandbox in the security unit, isolating malicious access and tampering at the operating system layer and application layer, thus ensuring the security of the signature generation process.

[0027] The security unit adds an integrity check code to the generated digital signature and uses the national cryptographic SM4 block cipher algorithm (hereinafter referred to as SM4 algorithm) to perform lightweight encryption and encapsulation of the signature data to prevent the signature data from being tampered with during transmission within the device; Meanwhile, the security unit has a built-in signature log recording function that automatically retains information such as device status and timestamps for each signature operation, forming a traceability chain for signature operations and further strengthening the anti-counterfeiting capabilities at the source.

[0028] Peritoneal dialysis data encryption uses the AES-256-GCM symmetric encryption algorithm to encrypt the peritoneal dialysis data, generating encrypted data packets. The encryption key is dynamically allocated by the hospital's key management system and distributed to the acquisition device and receiving end through a secure channel to ensure secure key transmission. Transmission link encryption uses the TLS 1.3 protocol to build a secure transmission channel, and performs link-layer encryption on transmitted content such as encrypted data packets and digital signatures to resist attacks such as eavesdropping, interception, and tampering during transmission. A data verification mechanism is set up during transmission. The receiving end verifies the integrity of the data packet every time it receives a data segment. If data loss or tampering is found, a retransmission request is automatically initiated. The corresponding hospital on the patient's side refers to the hospital responsible for managing the patient's peritoneal dialysis treatment.

[0029] Control module: Constructs a consortium blockchain network with multiple medical stakeholders as nodes. The consortium blockchain network includes an evidence storage unit, an authorization unit, and a traceability unit. The evidence storage unit is used to calculate the cryptographic hash value of the encrypted peritoneal dialysis data and store it in the consortium blockchain network. The authorization unit is used to verify and authorize data operation requests. The traceability unit is used to verify the integrity and operation trajectory of the peritoneal dialysis data. The nodes include data provision and verification nodes, regulatory nodes, controlled query nodes, and consensus and ledger nodes; Data provider and verification node: This is undertaken by the peritoneal dialysis centers of various hospitals. They are responsible for uploading the hash value of the encrypted peritoneal dialysis data collected by their own hospitals, participating in cross-institutional data verification and privacy computing tasks, and are the core suppliers of data resources in the consortium blockchain network. Regulatory nodes: These are handled by regional healthcare management agencies, responsible for node access review, network operation status monitoring, and compliance auditing of operation logs, ensuring the compliance and security of the consortium blockchain network. Controlled query nodes: These are staffed by research institutions with medical research qualifications. They can only initiate data queries or joint calculation requests after obtaining authorization, and have no permission to store or modify the original data. Consensus and ledger nodes: These nodes are selected from data providing and verification nodes and are technically capable and have excellent reputations. They adopt the Practical Byzantine Fault Tolerance (PBFT) consensus algorithm and are responsible for block generation, transaction confirmation and ledger synchronization to ensure a balance between consensus efficiency and fault tolerance.

[0030] Each node includes a key pair based on the SM2 algorithm and a node identifier; The private key in the key pair is stored in the node's hardware security carrier and protected by hardware isolation technology. It can only be called internally by the node for operation and signature, and is never exported to external terminals or networks to avoid the risk of leakage. The public key in the key pair is synchronously uploaded to the consortium blockchain network regulatory node for filing and publicly registered on the chain to verify the legality of the node's operation.

[0031] The node identifier is obtained by calculating the node's feature set using the SM3 algorithm; The feature set includes hospital qualifications, hardware attributes, network attributes, and access procedures; The hospital's qualification certificate is a unique code. Hardware attributes are the core hardware information of the server deployed on the node, including the server chip's unique serial number, motherboard physical code, and storage device firmware number; Network attributes are static information for nodes accessing the consortium blockchain network, including the fixed IP address deployed by the node, the dedicated communication port number, and the physical address of the network adapter, to avoid the identification association from becoming invalid due to changes in the network environment; The admission process consists of key audit records in the node admission process, including the approval timestamp of the regulatory node and the digital signature digest of the audit node (the hash value of the audit result after the regulatory node signs it with its own SM2 private key).

[0032] The node admission process is as follows: New nodes need to submit qualification certificates to the regulatory node. After the regulatory node verifies the application materials with digital signature using the national cryptographic SM2 algorithm, it will conduct multi-signature review in conjunction with three or more existing consensus and ledger nodes. Qualification certificates include hospital practice licenses, scientific research institution filing certificates, etc. After approval, a key pair and node identifier based on SM2 are generated for the new node, completing the node access configuration.

[0033] The working process of the evidence storage unit is as follows; please refer to [link / reference]. Figure 2 : The first step is to verify the peritoneal dialysis data using the public key of the monitoring node. After successful verification, the encrypted data text, device identifier or system identity information, timestamp, and digital signature are extracted from the peritoneal dialysis data. The second step is to calculate the cryptographic hash value of the encrypted data body using the SM3 algorithm. The calculation formula is as follows: in, The cryptographic hash value of the encrypted text. For the SM3 algorithm, Encrypted data body; The third step is to encapsulate the data into standardized evidence storage blocks in a fixed order, consisting of cryptographic hash value, data type (hospital side or patient side), timestamp, device identifier or system trusted number, and digital signature. The fourth step involves broadcasting the evidence storage data block to each consensus and ledger node via P2P technology. The consensus and ledger nodes retrieve the corresponding public key from the supervisory node and verify the validity of the digital signature in the evidence storage data block. All the consensus and ledger nodes then use the PBFT algorithm to reach a complete consensus on the legality and validity of the broadcast and verification of the evidence storage data block. The fifth step is to package the evidence storage data block into the newly generated block. The block is linked to the consortium blockchain network in chronological order, and the cryptographic hash value is permanently stored on the blockchain, that is, stored in the consortium blockchain network, and cannot be tampered with. The sixth step is to establish a mapping relationship between the storage address of the encrypted peritoneal dialysis data and the cryptographic hash value on the consortium blockchain network. The mapping record contains information such as storage path, access permission identifier, and data expiration time, and is stored in the consortium blockchain network to facilitate subsequent data retrieval and integrity verification.

[0034] The working process of the authorization unit is as follows, please refer to [link / reference]. Figure 3 : The first step is that when a patient registers with the system for the first time, the system generates a key pair for the patient based on the SM2 algorithm; The private key is kept by the patient, while the public key is uploaded to the regulatory node for record-keeping and included in the patient's digital identity trust list, serving as the legal basis for verifying data operation requests. Changes to the public key require confirmation by the patient's private key signature and are updated on the blockchain after review by the regulatory node.

[0035] The second step involves the patient initiating an authorization strategy. This strategy supports fine-grained settings, including: authorized recipients, authorized data scope, authorization validity period, authorization purpose, and operation permission type. Operation permission types include read-only, query and statistics, and combined calculation, among others. The third step involves the patient signing the authorization policy with their private key to obtain the authorization policy file. The fourth step is that after receiving the authorization policy file, the system verifies the validity of the authorization policy file with a public key and generates a unique authorization token based on the authorization policy file. The authorization token adopts the JWT format and contains the following core fields: patient anonymity identifier, authorized object node identifier, authorized data range hash, validity period timestamp and authorization unit signature. The validity period of the token is consistent with the authorization policy and it will automatically expire. Fifth, when the data operation initiator submits a data operation request, the authorization unit verifies the data operation initiator and the data operation request. The specific process is as follows: First, confirm whether the node initiating the data operation is in normal operating condition; then, verify the validity of the authorization token through the public key and check whether the authorization token is within its validity period; finally, extract the information from the authorization policy file in the authorization token and compare it with the data range and operation type in the operation request to confirm that the request content does not exceed the authorization range. For research-related operation requests, additional verification is required to ensure that the data operation initiator has completed the research project filing (the filing information is stored at the regulatory node) to ensure that the authorized use is compliant. The data operation request includes the node identifier of the data operation initiator, the authorization token, the operation type, and the target data identifier (hash digest or patient anonymity identifier). Step 6: After successful verification, the authorization unit generates an authorization execution instruction and synchronously updates the data operation log. The log is then encrypted and stored on the blockchain. If the verification fails, the authorization unit returns a rejection response, and the reason for rejection and the verification process log are stored on the blockchain for subsequent auditing and traceability. The seventh step is to send the authorization execution command to the corresponding data source node. The data source node extracts the corresponding data based on the authorization policy and sends it back to the operation initiator through the TLS 1.3 secure channel.

[0036] The specific operation of the traceability unit is as follows: The node requesting tracing sends a tracing request to the supervisory node, including the node identifier, tracing target, query conditions, and a digital signature based on the SM2 algorithm; the digital signature based on the SM2 algorithm is generated by the node requesting tracing by encrypting the tracing request with its private key; The supervisory node verifies the signature validity and node status by requesting the node's public key, and locates the data according to the query conditions, generating a location list containing block height, storage address, and associated hash value; Extract the cryptographic hash value from the consortium blockchain network, obtain the encrypted peritoneal dialysis data that needs to be traced through the location list, recalculate the cryptographic hash value, and compare it with the cryptographic hash value in the consortium blockchain network: if they match, the verification is deemed successful; if they do not match, the tampering difference and data status are recorded. Extract the associated operation log index of the data that needs to be traced, and traverse the relevant transaction records such as evidence storage, authorization, and collaborative analysis; The key information includes the operation node identifier, type, timestamp, and anonymized operator information. Organize the data into a linear trajectory chain based on timestamps to clarify the data flow path throughout its entire lifecycle; When data modifications are involved, the old version is located by using historical hash values ​​to trace the modification nodes, times, and reasons, ensuring auditability.

[0037] Collaborative Analysis Module: For collaborative analysis requests, the authorization unit coordinates each node to process the encrypted peritoneal dialysis data using privacy computing technology and outputs joint analysis results.

[0038] Collaborative analysis requests can only be initiated through controlled query nodes; The collaborative analysis request includes a node identifier, an authorization token signed with the patient's private key, an analysis task description, a unique task identifier, and filing information, and is submitted to the monitoring node. The unique identifier for a task is calculated using the SM3 algorithm based on the request content and the timestamp initiation. The filing information includes the project purpose, scope of data use, participating institutions, and research period.

[0039] After receiving the collaborative analysis request, the regulatory node verifies the registration information. If the verification is successful, the collaborative analysis request is forwarded to the authorization unit for secondary verification. The specific steps are as follows: First, the validity of the scientific research registration of the controlled query node is verified by the public key of the supervisory node; Secondly, verify the integrity and validity of the authorization token; Finally, the patient authorization scope was extracted from the authorization token to confirm that the analysis request did not exceed the authorization boundaries.

[0040] After verification, the authorization unit generates a task filing record, which includes information such as the unique identifier of the task, a list of participating nodes, and the scope of authorization. The record is stored on the blockchain for subsequent auditing. If the verification fails, a rejection response will be returned, and the reason for the rejection will be recorded on the blockchain.

[0041] The authorization unit issues collaborative analysis task instructions to the data providing and verification nodes involved in the collaborative analysis request. The collaborative analysis task instructions include a unique task identifier, encrypted analysis algorithm parameters, and data extraction rules; and designates the data providing and verification nodes involved in the collaborative analysis request as participating nodes. After receiving the instruction, the participating node extracts the corresponding encrypted peritoneal dialysis data from the local secure storage system through the task filing record, and uses the SM3 algorithm to calculate the hash digest of the extracted data as the basis for data consistency verification. Participating nodes import the extracted encrypted peritoneal dialysis data into a local hardware security sandbox and perform joint analysis based on preset privacy computing technologies, which include at least federated learning and secure multi-party computation. The specific steps of federated learning are as follows: The node that initiates the collaborative analysis request acts as the federated learning coordinator, distributing the initial model parameters through a secure channel; Participating nodes use encrypted peritoneal dialysis data to perform localized training on a pre-set global model within a secure sandbox, only calculating model gradient update values, without involving the decryption and transmission of the original data; After training is completed, the participating nodes digitally sign the gradient update values ​​using the SM2 algorithm, and then use the secret sharing technique in secure multi-party computation to split and encrypt the gradient values, which are then transmitted to the coordinating node via P2P technology. The initiating node collects the encrypted gradient values ​​of all participating nodes, performs aggregate calculations to generate global model update parameters, and then feeds them back to each participating node for the next round of training until the model converges. After the model converges, the initiating node integrates the final converged global model parameters, and based on the analysis task description, uses the global model to perform unified calculations on the privacy-preserving data representations provided by the participating nodes, directly outputting the aggregated joint analysis results, without involving the decryption of the original data or cross-node transmission.

[0042] The specific steps for secure multi-party computation are as follows: Participating nodes associate the cryptographic hash value corresponding to the encrypted peritoneal dialysis data with the unique identifier of the task, and distribute the data fragments to other participating nodes through a secret sharing protocol. The fragmented data is encrypted using the SM4 algorithm, and the valid information can only be restored by the collaborative decryption of all participating nodes. Based on encrypted sharded data, each node synchronously executes a preset analysis algorithm (such as statistical analysis and regression calculation). During the calculation process, zero-knowledge proof technology is used to verify the correctness of intermediate results to prevent malicious nodes from providing false data. After all nodes complete their local calculations, they encrypt and upload the intermediate results to the coordinating node, which then aggregates and generates the final joint analysis results.

[0043] The results of the joint analysis are aggregated conclusions or model outputs obtained after cross-institutional collaborative processing of encrypted peritoneal dialysis data using privacy computing technology. These include peritoneal dialysis efficacy statistics, treatment risk prediction results, and aggregated model parameters required for multicenter studies. They do not contain any original patient data.

[0044] After the joint analysis results are generated, the initiating node uses the SM3 algorithm to calculate the hash digest of the results and performs a correlation verification with the hash digest of the intermediate results uploaded by the participating nodes to ensure that the results have not been tampered with. Simultaneously, the results are digitally signed using the public key of the monitoring node to prove their compliance. Subsequently, the joint analysis results are encrypted using the AES-256-GCM symmetric encryption algorithm. The encryption key is distributed by the coordinating node to the participating and initiating nodes through a secure channel to ensure secure transmission of the results.

[0045] The encrypted joint analysis results are fed back to the initiating controlled query node through a TLS 1.3 secure channel. The node receives the results and decrypts them using the key. Meanwhile, the entire process log of collaborative analysis is encrypted with the SM4 algorithm and stored on the blockchain. The log is tamper-proof and is used for subsequent compliance audits by regulatory nodes.

[0046] The blockchain-based peritoneal dialysis data security sharing and traceability system proposed in this invention integrates national cryptographic algorithms and privacy computing technology through a consortium blockchain network evidence storage and authorization architecture. It solves the problems of security and trustworthiness, privacy leakage and data silos faced by cross-institutional sharing of peritoneal dialysis data. Under the premise of ensuring data immutability, full traceability and strong protection of patient privacy, it realizes secure and efficient data sharing and collaborative analysis.

[0047] In summary, this invention, by constructing a complete technical system integrating consortium blockchain networks, national cryptographic algorithms, and privacy computing, achieves secure, reliable, accurate traceability, and fine-grained controllable sharing of peritoneal dialysis data throughout its entire lifecycle. Under the premise of thoroughly protecting patient privacy, it effectively breaks down data silos and supports secure and efficient collaborative analysis across institutions.

[0048] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A blockchain-based peritoneal dialysis data security sharing and traceability system, characterized in that, include: Data sensing module: Collects peritoneal dialysis data from the hospital's information system and the patient's peritoneal dialysis equipment; When the peritoneal dialysis data is generated, a data source identifier and timestamp are attached, and a digital signature is generated; then the peritoneal dialysis data is encrypted and stored in the corresponding hospital's secure storage system; Control module: Constructs a consortium blockchain network with multiple medical stakeholders as nodes. The consortium blockchain network includes an evidence storage unit, an authorization unit, and a traceability unit. The evidence storage unit is used to calculate the cryptographic hash value of the encrypted peritoneal dialysis data and store it in the consortium blockchain network. The authorization unit is used to verify and authorize data operation requests. The traceability unit is used to verify the integrity and operation trajectory of the peritoneal dialysis data. Collaborative Analysis Module: For collaborative analysis requests, the authorization unit coordinates each node to process the encrypted peritoneal dialysis data using privacy computing technology and outputs joint analysis results.

2. The system according to claim 1, characterized in that, The data source identifier on the hospital side is the system identity information of the data source, which includes a unique hospital code, a system type identifier, and a trusted system number. The data source identifier on the patient side is the device identifier of the peritoneal dialysis device on the patient side.

3. The system according to claim 2, characterized in that, The nodes include data provision and verification nodes, regulatory nodes, controlled query nodes, and consensus and ledger nodes; The data provision and verification nodes are provided by the hospital's peritoneal dialysis center; The regulatory nodes are managed by regional medical and health management agencies. The controlled query nodes are operated by research institutions with medical research qualifications; The consensus and ledger nodes are selected from the data providing and verification nodes based on preset filtering criteria.

4. The system according to claim 3, characterized in that, The node includes a key pair and a node identifier based on the SM2 elliptic curve public key cryptography algorithm; The node identifier is obtained by calculating the node's feature set using the national cryptographic SM3 hash algorithm.

5. The system according to claim 4, characterized in that, The working process of the evidence storage unit is as follows: The first step is to verify the encrypted peritoneal dialysis data using the public key of the monitoring node. After successful verification, the encrypted data text, device identifier or system identity information, timestamp, and digital signature are extracted from the peritoneal dialysis data. The second step is to use the SM3 cryptographic hash algorithm to calculate the cryptographic hash value of the encrypted data body; The third step is to encapsulate the data into standardized evidence storage blocks in a fixed order of cryptographic hash value, data type, timestamp, device identifier or system trusted number, and digital signature. The fourth step is to broadcast the evidence storage data block to all the consensus and ledger nodes via P2P technology. The consensus and ledger nodes retrieve the corresponding public key from the supervisory node, verify the validity of the digital signature in the evidence storage data block, and then the consensus and ledger nodes use the PBFT algorithm to reach a complete consensus on the legality and validity of the broadcast and verification of the evidence storage data block. The fifth step involves packaging the evidence storage data block into a newly generated block, linking the block to the consortium blockchain network in chronological order, and storing the cryptographic hash value in the consortium blockchain network. The sixth step is to establish a mapping relationship between the storage address of the peritoneal dialysis data and the cryptographic hash value on the consortium blockchain network.

6. The system according to claim 5, characterized in that, The working process of the authorization unit is as follows: The first step is that when a patient registers with the system for the first time, the system generates a key pair for the patient based on the SM2 algorithm; The second step involves the patient initiating an authorization strategy, which supports fine-grained dimensional settings. Third, the patient signs the authorization policy using their private key to obtain the authorization policy file; Fourth, after receiving the authorization policy file, the system verifies the validity of the authorization policy file using a public key and then generates a unique authorization token based on the authorization policy file. Fifth, when the data operation initiator submits a data operation request, the authorization unit verifies the data operation initiator and the data operation request; Step 6: After successful verification, the authorization unit generates an authorization execution instruction; The seventh step is to send the authorized execution instruction to the corresponding data source node, which then extracts the corresponding data based on the authorization policy and feeds it back to the data operation initiator.

7. The system according to claim 6, characterized in that, The collaborative analysis request can only be initiated through the controlled query node; The collaborative analysis request includes a node identifier, an authorization token signed with the patient's private key, an analysis task description, a unique task identifier, and filing information, and is submitted to the monitoring node. After receiving the collaborative analysis request, the regulatory node verifies the filing information. If the verification is successful, the collaborative analysis request is forwarded to the authorization unit for secondary verification. After successful verification, the authorization unit generates a task filing record; The authorization unit issues collaborative analysis task instructions to the data providing and verification nodes involved in the collaborative analysis request; and designates the data providing and verification nodes involved in the collaborative analysis request as participating nodes; After receiving the instruction, the participating node extracts the corresponding peritoneal dialysis data from the secure storage system through the task filing record, and performs joint analysis on the extracted peritoneal dialysis data based on the preset privacy computing technology to obtain the joint analysis result. The privacy-preserving computation technology includes at least federated learning and secure multi-party computation.

Images