Medical image storage and sharing method and system based on alliance chain

Abstract

The invention provides a medical image storage and sharing method and system based on an alliance chain, and belongs to the field of block chains. The problems of poor data security, high privacy disclosure risk, insufficient access control, low cross-mechanism sharing efficiency and the like in the current medical image storage, transmission and sharing process are solved; the system comprises an image preprocessing module, an alliance chain registration module, a distributed storage module, an access control module and an image reconstruction module. The image preprocessing module performs privacy field stripping, AES-GCM encryption and JPEG2000 compression processing on the DICOM format image to ensure the confidentiality and integrity of image data; and the access control module performs on-chain access authorization in combination with user identity, role permission and policy rules, and supports RBAC and multi-signature approval mechanisms. The system realizes full-life-cycle safety management and credible sharing of medical images.

Description

Technical Field

[0001] The present application relates to the field of medical image storage and information security technology, and in particular to a medical image storage and sharing method and system based on alliance chain. Background Art

[0002] Medical images (such as CT, MRI, and PET) serve as crucial foundations for clinical diagnosis and play a central role in healthcare information systems. These images are typically managed using the DICOM (Digital Imaging and Communications in Medicine) standard. However, existing DICOM image storage and sharing often relies on a centralized server architecture, which presents several key issues:

[0003] 1. Security issues: Once centralized storage is attacked (such as ransomware, data hijacking), it may cause a large amount of patient image data to be leaked, resulting in serious consequences;

[0004] 2. Privacy issues: The DICOM format contains sensitive information such as patient names, ID numbers, and examination records. Without an effective encryption mechanism, there will be huge privacy risks;

[0005] 3. Weak permission control: Traditional systems lack flexible access control strategies and cannot implement refined authorization management;

[0006] 4. Lack of traceability: Image sharing is difficult to audit and track throughout its entire life cycle, making it difficult to meet medical research and legal compliance requirements.

[0007] In recent years, blockchain technology, particularly consortium blockchains, has been widely adopted in multi-party collaborative data management scenarios due to its advantages, including data immutability, full process traceability, and automated execution based on smart contracts. Hyperledger Fabric, a typical consortium blockchain framework, supports identity authentication, data isolation, and efficient concurrency, demonstrating significant potential in medical data management. Summary of the Invention

[0008] In order to solve the current problems of poor data security, high risk of privacy leakage, insufficient access control and low efficiency of cross-institutional sharing in the storage, transmission and sharing of medical images, this application proposes a medical image storage and sharing method and system based on alliance chain, which integrates DICOM image encryption processing, Hyperledger Fabric alliance chain architecture and IPFS distributed storage mechanism to build a secure, controllable and efficient medical image collaborative management platform with high security, scalability and practicality.

[0009] The technical solution adopted in this application is: a medical image storage and sharing method based on alliance chain, comprising the following steps:

[0010] S1: Image preprocessing and encryption compression, including:

[0011] S1.1: Separate the patient's privacy fields in the original medical image to generate an independent privacy field set ;

[0012] S1.2: Pixel data in original medical images Perform authentication encryption and set the encryption key to , the initial vector is , output encrypted image and certification labels ;

[0013] S1.3: Encrypted image Perform lossless compression to generate compressed encrypted images ;

[0014] S1.4: Yes Generate image hash digest using hash algorithm , for integrity verification and on-chain registration:

[0015] S2: Alliance chain registration and permission policy definition, including:

[0016] S2.1: Patient Anonymity , image hash summary , upload timestamp , uploader certificate hash , image tags To register objects and serve as metadata;

[0017] S2.2: Call the pre-deployed smart contract on the chain and pass the above metadata and access policy structure Write to the block ledger;

[0018] S2.3: Verify whether the contract is passed. If the verification is passed, the transaction hash, version number, and metadata of the registration process will be sent to Fabric for subsequent audit and on-chain verification. If the verification fails, the registration will be rejected.

[0019] S3: Upload the desensitized, encrypted, and compressed medical image files in step S1 to a distributed storage network, and perform content-addressable storage on the medical image files through the IPFS network;

[0020] S4: Access control: Authentication and permission determination of user image access requests;

[0021] S5: Image reconstruction: restore the original image to the authorized user;

[0022] S6: Access behavior is audited on the chain.

[0023] Furthermore, step S3 includes:

[0024] S3.1: Use the IPFS system to compress and encrypt images Perform content-addressable storage, generate a unique content address CID, and implement image data sharding and redundant backup through the Merkle-DAG structure;

[0025] At this stage, the compressed encrypted image Establish a binding relationship with the image CID stored in IPFS;

[0026] S3.2: IPFS system records CID and image hash summary One-to-one mapping relationship, and maintain the consistency of on-chain and off-chain data through on-chain registration;

[0027] S3.3: In the subsequent image access process, the data is pulled from IPFS through the CID and registered on the chain To verify the benchmark, an integrity check is performed.

[0028] Furthermore, step S4 includes:

[0029] S4.1: Receive the visitor's digital identity with the image request number , and submit it to the on-chain access control contract for permission judgment;

[0030] S4.2: The access decision function is as follows:

[0031] ;

[0032] in, representation and relationships;

[0033] S4.3: If authorization is successful, the image CID, decryption key index, and access token are returned; if authorization fails, access is denied, and the access behavior and results are synchronously recorded in the blockchain.

[0034] Furthermore, step S5 includes:

[0035] S5.1: Use the obtained CID to pull the compressed encrypted image from IPFS and obtain the symmetric key through the key management service ;

[0036] S5.2: Perform decryption operation to obtain the image ciphertext decryption result , then perform decompression to restore pixel data ;

[0037] S5.3: Finally, the decrypted image Separate privacy fields from the initial set Merge and restore legal DICOM format images.

[0038] Furthermore, the access policy structure Expressed as:

[0039] ;

[0040] in, Indicates the set of users allowed to access. To allow access to time windows, The time to start the visit, End of visit time, Indicates the access permission level;

[0041] Access policy structure Supports dynamic update mechanism, allowing authorized subjects to make subsequent adjustments to the permission list, time window and access mode of registered images;

[0042] Access policy adjustments are initiated by the system administrator or image uploader by calling the on-chain smart contract interface to conduct a policy change transaction. The transaction structure contains the image identifier, the policy change content, and the digital signature of the change initiator to ensure that the source of the policy modification is credible and verifiable;

[0043] After receiving a policy change request, the smart contract will verify the initiator's identity and, if the verification is successful, perform an overwrite update on the on-chain access control field. The policy update transaction will generate an independent transaction hash and record the version number to support future access behavior aligned with the policy snapshot, ensuring that the system supports fine-grained management and long-term evolution control of image permissions.

[0044] Furthermore, the access policy supports a role-based access control model and a multi-signature approval mechanism, allowing access rights to be dynamically assigned based on the role category held by the visitor.

[0045] Furthermore, the system also supports embedded watermark generation and traceability mechanisms during the image access process. When the image is legally authorized to be accessed and decrypted and restored, the system will automatically embed a digital watermark of the visitor's identity into the image to support source tracing of subsequent image leakage incidents.

[0046] Furthermore, a local access cache control mechanism is supported during the access process. When the user views the image, the decrypted image is only retained in temporary memory or a restricted sandbox environment at runtime. The image buffer data is immediately cleared after the access is completed to prevent long-term residual data. The specific process is as follows:

[0047] (1) When decrypting an image, the memory sandbox management service is called to decode and display the image data in an isolated area;

[0048] (2) Users are not allowed to save local copies during image processing, and the download function requires additional approval from the on-chain permission contract;

[0049] (3) Once the access window times out or the user actively closes the image view, the buffered image data, session token, and key reference are automatically cleared.

[0050] A medical image storage and sharing system based on alliance chain, including:

[0051] Image preprocessing module: used to perform structured separation and encryption compression processing on medical images, and output desensitized, encrypted, and compressed medical image files and corresponding content summaries for subsequent on-chain registration and integrity verification;

[0052] Alliance chain registration module: used to register, verify and track medical image metadata and access control policies;

[0053] Distributed storage module: Use the IPFS network to perform content-addressable storage of medical image files;

[0054] Access Control Module: This module is used to authenticate and determine the permissions of user image access requests. It authorizes on-chain access by combining user identity, role permissions, and policy rules. It also supports role-based access control models and multi-signature approval mechanisms.

[0055] Image decryption and reconstruction module: used to complete image pulling, decryption, decompression and privacy reconstruction after permission verification, and restore the original medical image.

[0056] Furthermore, the system also has a built-in configurable anonymization policy engine, allowing system administrators to independently define the processing rules of image privacy fields based on institutional policies or regulatory requirements, and implement different levels of desensitization processing;

[0057] The anonymization policy engine supports the following field-level operations:

[0058] (1) Field retention: Specific fields are retained in ciphertext for subsequent association;

[0059] (2) Field deletion: the field is directly deleted from the original medical image file structure;

[0060] (3) Field fuzziness: Use wildcards or partial truncation to handle;

[0061] (4) Field generalization: mapping field content to a generalized set;

[0062] The anonymization strategy is saved in the system configuration chaincode in the form of a rule set. The image preprocessing module performs field parsing and conversion before each image is uploaded. The conversion process is recorded in the privacy field summary structure for auditing and reverse restoration control.

[0063] The beneficial effects of this application compared to the prior art are:

[0064] 1. Improve data security: Through multiple mechanisms such as AES-GCM encryption, IPFS distributed storage, and alliance chain registration, prevent illegal access to images during transmission and storage;

[0065] 2. Privacy protection: Sensitive information is separated and encrypted to ensure that patient identity information cannot be read without authorization;

[0066] 3. Support refined permission control: automatically determine access rights based on smart contracts and flexibly configure multi-dimensional authorization strategies;

[0067] 4. Improve system scalability: The system supports horizontal expansion of alliance members, is compatible with multi-platform calls, and connects with heterogeneous data sources;

[0068] 5. Meet compliance requirements: The entire system operation process is auditable and traceable, and complies with international privacy protection regulations such as GDPR and HIPAA.

[0069] This system can be widely used in scenarios such as regional imaging cloud platforms, cross-institutional remote consultations, and medical research data sharing, while protecting patient privacy and improving the efficiency of medical image collaboration. BRIEF DESCRIPTION OF THE DRAWINGS

[0070] The present application will be further described below with reference to the accompanying drawings:

[0071] Figure 1 This is the overall system architecture diagram;

[0072] Figure 2 This is the DICOM image preprocessing flowchart;

[0073] Figure 3 Flowchart for consortium chain registration and permission policy binding;

[0074] Figure 4 Diagram of image content addressing and storage mechanism based on IPFS;

[0075] Figure 5Flowchart for image access request and on-chain permission verification;

[0076] Figure 6 Flowchart for image decryption and DICOM reconstruction;

[0077] Figure 7 Recording structure diagram for access audit chain;

[0078] Figure 8 This is a logic diagram for multi-signature access control decision;

[0079] Figure 9 Flowchart for image embedded watermark generation and traceability;

[0080] Figure 10 Processing flow chart for anonymization policy engine;

[0081] Figure 11 Schematic diagram of minimizing local cache and access window control. DETAILED DESCRIPTION

[0082] like Figures 1 to 11 As shown, this application also proposes a medical image storage and sharing method based on alliance chain, including the following steps:

[0083] S1: Image preprocessing and encryption compression: The image preprocessing module performs structured separation and encryption compression on medical image files. Figure 2 This is a DICOM image preprocessing flow chart, showing the processing path of the original medical image through privacy field extraction, AES-GCM encryption, JPEG2000 compression and hash summary generation, which constitutes the encryption compression and structure separation process before the image is stored on the chain. Specifically, it includes:

[0084] S1.1: Separate the patient's privacy fields (including name, ID, date of birth, examination time, etc.) in the original medical image to generate an independent privacy field set , to avoid the leakage of private information during storage and transmission;

[0085] Based on the semantic analysis of the DICOM image file header and data element segments, data fields related to patient identity are automatically extracted and organized into a data structure that can be desensitized and stored.

[0086] The structure is defined as a set of tuples in the form of key-value pairs:

[0087] ;

[0088] in, Indicates the privacy key field identifier defined in the DICOM standard (such as "PatientName", "PatientID", etc.), Represents the corresponding value. The extracted private fields are encrypted and stored in the off-chain database, and are bound one-to-one with the encrypted image using the summary fields registered on the chain.

[0089] This mechanism ensures that the system completely strips away patient identity information without affecting image pixel data processing, complying with GDPR's "data minimization" and HIPAA's "decoupling identity" compliance requirements, while also ensuring the reversibility and security of future privacy field reassociation.

[0090] S1.2: Pixel data in original medical images Use AES-GCM mode for authentication encryption, and set the encryption key to , the initial vector is , output encrypted image and certification labels ,Right now:

[0091] ;

[0092] S1.3: Encrypted image Use JPEG2000 algorithm for lossless compression to generate compressed encrypted images , used to reduce subsequent transmission pressure;

[0093] S1.4: Yes Generate image hash digest using the SHA-256 algorithm , for integrity verification and on-chain registration:

[0094] .

[0095] The AES-GCM (Galois / Counter Mode) mode used in the image encryption process has the ability to simultaneously ensure data confidentiality and integrity authentication, and is particularly suitable for high-fidelity and highly sensitive data scenarios in medical images.

[0096] During the image pixel encryption phase, the system uses a 128-bit symmetric key. , and a randomly generated 12-byte initialization vector , for pixel data The ciphertext generated by this is (i.e. encrypted image) can be reversed to restore the original image content, with the generated authentication tag The length is 128 bits and serves as the basis for determining whether the image has been tampered with.

[0097] During the image decryption and restoration phase, the system will receive If the recalculated label is compared with the original one, any discrepancies indicate that the image data may have been tampered with during transmission or storage. The system automatically aborts the restoration process and issues an integrity alert. This mechanism ensures that image data remains robust and tamper-resistant even in untrusted storage environments such as IPFS.

[0098] S2: Alliance chain registration and permission policy definition: The image metadata is registered on the Hyperledger Fabric alliance chain through the alliance chain registration module. Figure 3 This is a flowchart for consortium chain registration and permission policy binding, showing the process of the system calling the Fabric smart contract to register image metadata and access permission policy, including the image hash, uploader identity, timestamp, access role list and access time window on the chain. Specifically, it includes:

[0099] S2.1: Patient Anonymity , image hash summary , upload timestamp , uploader certificate hash , image tags For the registration object;

[0100] S2.2: Call the pre-deployed smart contract function on the chain and pass the above metadata and access policy structure When written into the block ledger, the policy structure is defined as:

[0101] ;

[0102] in, Indicates the set of users allowed to access. To allow access to time windows, The time to start the visit, End of visit time, Indicates the access permission level (e.g., read-only, download);

[0103] S2.3: Call Chaincoed to verify whether the contract is passed. If the verification is passed, the transaction hash, version number and other metadata of the registration process will be sent to Fabric for subsequent audit and on-chain verification. If the verification fails, the registration will be rejected.

[0104] Access policy structure Supports a dynamic update mechanism, allowing authorized entities to make subsequent adjustments to the permission list, time window, and access mode of registered images.

[0105] Policy adjustments are initiated by the system administrator or image uploader through a transaction involving an on-chain smart contract interface. This transaction structure includes the image identifier, the policy change details (e.g., adding a new physician ID, changing the access deadline, etc.), and the digital signature of the initiator of the change, ensuring the authenticity and verifiability of the policy modification.

[0106] Upon receiving a policy change request, the smart contract verifies the initiator's identity and, if verified, overwrites and updates the on-chain access control fields. The policy update transaction generates a unique transaction hash and records a version number to align future access actions with the policy snapshot, ensuring the system supports fine-grained management and long-term evolution of image permissions.

[0107] S3: Image files are uploaded to the distributed storage network: The distributed storage module is used to store image data off-chain and ensure verifiability. Figure 4 This is a diagram of the image content addressing and storage mechanism based on IPFS, describing the content sharding, CID generation, redundant storage, and subsequent pull and retrieval process of compressed and encrypted images through the IPFS network, as well as the on-chain CID hash value binding mechanism to ensure on-chain and off-chain data consistency. Specifically, it includes:

[0108] S3.1: Use the IPFS system to compress and encrypt images Perform content-addressable storage, generate a unique content address CID, and implement image data sharding and redundant backup through the Merkle-DAG structure;

[0109] At this stage, the compressed encrypted image Establish a binding relationship with the image CID stored in IPFS:

[0110] ;

[0111] During the image access phase, the system uses the above equation to compare the image currently extracted from IPFS with the on-chain record to see if it is consistent. If the hash verification fails, the decryption operation is rejected and a tampering alarm is issued.

[0112] This binding mechanism provides a unique on-chain fingerprint for cross-network distributed storage of image data, effectively preventing attacks such as man-in-the-middle attacks, image swapping, and unauthorized data replacement. It is the core supporting technology for the trusted storage capabilities of this system.

[0113] S3.2: System records CID and image hash digest One-to-one mapping relationship, and maintain the consistency of on-chain and off-chain data through on-chain registration;

[0114] S3.3: In the subsequent image access process, the data is pulled from IPFS through the CID and registered on the chain To verify the benchmark, an integrity check is performed.

[0115] S4: Access control: Authentication and permission determination of user image access requests. Figure 5 This is a flowchart of image access request and on-chain permission verification, showing that after a doctor user submits an access request, the system uses the on-chain contract to determine whether their identity matches the access policy, returns an authorization status or a rejection response, and records the access log. Specifically, it includes:

[0116] S4.1: The system receives the visitor's digital identity with the image request number , and submit it to the on-chain access control contract for permission judgment;

[0117] S4.2: The access decision function is as follows:

[0118] ;

[0119] S4.3: If authorization is successful, the system returns the image CID, decryption key index, and access token; if authorization fails, access is denied, and the access behavior and results are synchronously recorded in the blockchain.

[0120] S5: Image reconstruction: restore the original image to the authorized user. Figure 6 This is a flowchart for image decryption and DICOM reconstruction, showing how, after authorization is granted, the system pulls image data through the CID, performs AES-GCM decryption, JPEG2000 decompression, and privacy field reconstruction, ultimately restoring a legitimate DICOM file for use by the medical system. Specifically, it includes:

[0121] S5.1: Use the obtained CID to pull the compressed encrypted image from IPFS and obtain the symmetric key through the key management service ;

[0122] S5.2: Perform AES-GCM decryption operation to obtain the image ciphertext decryption result , then perform JPEG2000 decompression to restore pixel data ;

[0123] S5.3: Finally, the decrypted image Separate privacy fields from the initial set Merge and restore legal DICOM format images :

[0124] ;

[0125] Where, is the reassembly function, which recompresses the decompressed image pixel data Combined with the privacy field set P to form a complete and legal DICOM image file D; is the decompression function of JPEG2000, which is the inverse process of the compression function 𝜏 and is used to restore the original pixel data .

[0126] The system supports embedded watermark generation and traceability mechanisms during image access. When an image is legally authorized for access and decrypted and restored, the system will automatically embed a digital watermark of the visitor's identity into the image to support source tracing of subsequent image leakage incidents.

[0127] Figure 9 This is a flowchart for image embedded watermark generation and traceability. It describes how the system embeds the visitor's identity hash in the image's DCT domain as a digital watermark after image decryption, forming a unique identity tracking identifier for use in data breach traceability and forensics. The watermark uses a DCT (Discrete Cosine Transform) + Hash encoding algorithm based on position robustness and semantic awareness, performing the following steps:

[0128] (1) Generate a digital signature by encoding the visitor’s digital identity IDU through SHA-256 ;

[0129] (2) Select a set of perceptually insensitive regions in the image frequency domain ,in For image pixel data The result after performing Discrete Cosine Transform (DCT);

[0130] (3) Using embedded functions Embed the signature into the image to generate an embedded image .

[0131] The DICOM file generated by the image reconstruction module will be used As the source of pixel data, the watermark embedding identifier is recorded in the privacy field. This mechanism can be used to trace the source of the image leak by comparing the embedded signature with the identity signature in the access log.

[0132] S6: Access behavior audit on the chain: Figure 7This diagram shows the structure of the access audit chain record, illustrating the data structure of the on-chain audit record generated by the access control module. This data includes fields such as the visitor's identity hash, image ID, access time, access result, and signature hash, demonstrating the log's immutability. For each image access request (successful or unsuccessful), the system records the operation log via Chaincode calls. This information includes the visitor's identity, access time, accessed image ID, response status, and operation type. This information is written to the consortium chain ledger using a transaction hash, enabling traceability and oversight of the entire operation process.

[0133] This application also provides a medical image storage and sharing system based on alliance chain, Figure 1 This is the overall system architecture diagram, which shows the five core functional modules of the system of this application and the data interaction process between them, including image preprocessing module, alliance chain registration module, distributed storage module, access control module and image reconstruction module, reflecting the system logic of on-chain and off-chain collaboration, privacy separation and access control. The modules are linked through data flow and permission strategy to jointly complete the secure processing, storage registration, access control and sharing services of medical images.

[0134] The image preprocessing module is responsible for performing structured separation and encryption compression preprocessing on medical images (such as DICOM 3.0 format) to ensure the security and privacy compliance of image data during storage and transmission. This module specifically includes the following sub-functions:

[0135] (1) Privacy field separation: Automatically parse the data elements in the DICOM image, extract the patient's name, ID, gender, examination date and other privacy fields, and store them in an independent structure, that is, an independent privacy field set middle;

[0136] (2) Image encryption: The image pixel data is encrypted using the AES-GCM algorithm, which has authenticated encryption capabilities and can achieve both confidentiality and integrity protection;

[0137] (3) Image compression: Use the JPEG2000 standard to perform lossless compression on encrypted images to reduce storage and transmission loads;

[0138] (4) Digest generation: Perform SHA-256 hash operation on the compressed image data to obtain a globally unique content digest for subsequent on-chain registration and integrity verification.

[0139] Through the above processing, this module can output desensitized, encrypted, and compressed medical image files, as well as the corresponding hash summary and privacy information structure.

[0140] Consortium chain registration module: Based on Hyperledger Fabric, the consortium chain network is built to register, verify, and track image metadata and access control policies. Its main functions include:

[0141] (1) On-chain identity management: Fabric CA is used to implement digital identity authentication based on the X.509 standard, supporting identity registration and certificate issuance for multiple roles such as medical institutions, doctors, and patients;

[0142] (2) Metadata registration: The image’s hash value, uploader identity, public key, upload timestamp, image type and other metadata are written into the ledger through Chaincode (smart contract);

[0143] (3) Access policy setting: Support image-level access permission setting based on smart contracts, including the identity list of allowed visitors, accessible time window, etc.

[0144] (4) Logging and auditing: All upload, modification, and access operations are written to the on-chain log through contract-triggered transactions to ensure traceability throughout the entire life cycle.

[0145] This module ensures that the metadata of all medical images can be tracked and verified, and builds an image-level trusted data registration system.

[0146] The distributed storage module uses IPFS (InterPlanetary File System) as the off-chain storage infrastructure for image data, enabling efficient storage, transmission, and content verifiability of image files. Specific functions include:

[0147] (1) Content-addressed storage: The uploaded encrypted and compressed images are stored in blocks on the IPFS network, and each image corresponds to a unique CID (Content Identifier);

[0148] (2) Multi-node redundant backup: Image data can be distributed and deployed on multiple IPFS nodes to enhance disaster recovery capabilities;

[0149] (3) On-chain-off-chain binding: The CID of each image file is hashed and registered on the consortium chain to achieve on-chain authentication and off-chain access;

[0150] (4) Data pulling and caching: When accessing images, files are pulled from IPFS through CID. The system can automatically cache hot images to optimize access latency.

[0151] Through this module, the system can achieve cost reduction, decentralization and tamper-proof storage of massive medical images.

[0152] The distributed storage module has cross-node redundant replication and availability recovery capabilities. It uses the decentralized network structure of IPFS to achieve multi-node storage and data persistence of images, thereby improving the availability and disaster recovery capabilities of images.

[0153] After the image is written to the IPFS network for the first time, the system automatically triggers the replication strategy and synchronously distributes the image file with the content address CID to the pre-configured N trusted nodes, ensuring that when any node fails, other nodes can be quickly awakened to restore access capabilities.

[0154] The replica synchronization status of each node is recorded and periodically sent to the regulatory contract in the alliance chain network. The regulatory contract generates a status summary of indicators such as the number of node replicas, availability, and synchronization delay, and registers them on the chain.

[0155] This mechanism ensures that the system has a high degree of distributed robustness, and can still guarantee high availability and accessibility of image data even when the hospital information system is offline, the node is attacked, or the off-chain network is interrupted.

[0156] The access control module is responsible for authenticating, authorizing, and auditing image access requests submitted by users. The core mechanism is driven by on-chain smart contracts to ensure the principle of minimum permissions and full traceability of access behavior. Functional submodules include:

[0157] (1) Access request resolution: resolution of the requester's identity (via digital certificate), access image number, and operation type;

[0158] (2) Policy matching engine: Makes decisions based on the access rules defined in the contract (such as whitelist identities, accessible time periods, one-time access restrictions, etc.);

[0159] (3) Authorization response generation: After authorization is passed, the image CID, encryption key index and audit number are returned to the client;

[0160] (4) Behavior recording and auditing: Information such as access requests, authorization decisions, and access times are recorded on the chain for later supervision and dispute tracing.

[0161] This module combines on-chain contracts and off-chain logs to dually ensure access security, meeting the compliance requirements of GDPR, HIPAA and other regulations on the principle of minimum access.

[0162] The access control module also supports an access authorization mechanism based on a multi-signature strategy, enabling cross-organizational and multi-role collaborative participation in image access approval, and enhancing the compliance and collective supervision capabilities of access behavior.

[0163] The system can enable a multi-signature access mechanism for sensitive images (such as preoperative planning images and cross-border shared images). Figure 8This is a multi-signature access control decision logic diagram, showing that access requests must be signed by multiple authorized roles to reach a threshold. The threshold signature mechanism that can only be authorized by the contract after the visitor submits the access request is suitable for highly sensitive scenarios such as scientific research sharing and remote consultation. Requires at least The access request is confirmed by an authorized role, and the following conditions are met:

[0164] ;

[0165] A set of predefined roles that have image access authorization permissions, for example: ={Medical Affairs Administrator, Director of Radiology Department, Ethics Reviewer, Project Leader}.

[0166] The signature uses an ECDSA-based digital signature scheme and is aggregated through a consortium blockchain smart contract. Only when the number of signatures reaches a threshold does the system allow the access process to proceed, and the complete multi-signature approval path and timestamp are recorded.

[0167] This mechanism is widely applicable to high-trust threshold scenarios such as scientific research image retrieval, remote consultation, and privacy-sensitive image extraction, providing collective endorsement and process evidence support for image access behavior.

[0168] The image decryption and reconstruction module is used to restore the original DICOM image after the permission verification is passed for use by the medical diagnosis system or image viewer. The main processing flow is as follows:

[0169] (1) Image pull: Pull the corresponding encrypted image data from IPFS through the returned CID;

[0170] (2) Image decryption: Decrypt the image using the AES-GCM key obtained by the key management system (or the user's local security module);

[0171] (3) Image decompression: Perform JPEG2000 decompression on the decrypted image;

[0172] (4) Privacy merging: Merge the privacy fields stripped in the early stage with the image data structure to reconstruct the complete DICOM standard image file.

[0173] This module ensures that authorized users can quickly restore image files with complete clinical information while avoiding the exposure of any sensitive fields in unauthorized scenarios.

[0174] The access control policy in the system supports the role-based access control model (RBAC), which allows dynamic allocation of access rights based on the role category held by the accessor.

[0175] The system presets role sets for different medical institutions and users, including but not limited to: "Radiologist", "Attending Physician", "Researcher", "Hospital Administrator", etc.; the access policy for each image can specify the role set allowed to access .

[0176] During the access determination phase, the system obtains the visitor’s bound role information through smart contracts. and set the role whitelist collection with the image Match. If , the access request is deemed legitimate and the system continues the authorization process. This mechanism significantly simplifies permission configuration in cross-institutional, multi-user environments, avoiding tedious user-by-user authorization and improving the system's versatility and flexibility in multi-scenario use of medical images.

[0177] Every image access attempt in the system (including successful and failed authorization) is recorded as an operation log transaction by the smart contract on the access control module-driven chain, forming an access audit chain.

[0178] The log transaction includes but is not limited to the following fields: visitor identity hash, access image number, access timestamp, access result (success / rejected), access intention (browse / download), request IP address (optional), and transaction hash returned by the access contract.

[0179] All log transactions are written to the blockchain ledger and are irrevocable and tamper-proof, making them available for subsequent compliance checks, user behavior backtracking, and legal evidence collection. Furthermore, the system supports extracting image access log summaries through an on-chain state reading interface, generating a graphical access history view to automate medical safety audits.

[0180] The alliance chain smart contract has a verifiable and modular upgrade mechanism, which supports the system to achieve secure iteration and upgrade deployment of contract logic without reconstructing the blockchain network.

[0181] The contracts used for registration, authorization, auditing and other operations in the system are constructed as independent contract units (such as RegisterContract, AuthContract, LogContract, etc.) through modular writing. Each module contract is bound to a version number and contract hash, and audit-level lifecycle management is performed through the Chaincode Lifecycle protocol provided by Fabric.

[0182] During the upgrade process, the new version of the contract is released through the on-chain proposal and chaincode update mechanism, and approved by the system administrator through on-chain multi-signature voting or pre-authorization; the original data structure and calling interface are backward compatible through the version mapping mechanism, ensuring smooth migration of the coexistence of new and old contract logic.

[0183] This mechanism not only ensures the verifiability of the system contract logic, but also can continuously adapt to the policy evolution and system function expansion needs of the medical industry, and has high engineering availability and safe evolution capabilities.

[0184] The system also supports a hierarchical authorization and sharing collaboration mechanism for medical images among multiple medical institutions. Each image in the system is bound to its "institution ID" and "shareable scope" on the chain, and is synchronously controlled by multiple organizations through a cross-chain consensus module.

[0185] The system supports dividing images into three sharing levels:

[0186] (1) In-house access: only for doctors in this hospital;

[0187] (2) Sharing within the alliance: accessible to alliance hospital members;

[0188] (3) Cross-domain authorization: It must be provided to external research institutions or remote platforms after multi-signature approval.

[0189] Sharing levels are incorporated into the contract policy field and are strongly tied to image access behavior. The system uses Fabric's MSP (Membership Service Provider) mechanism to identify the visitor's organization and dynamically match authorization boundaries accordingly.

[0190] In addition, the system supports the construction of multi-hospital data isolation and controllable intercommunication network through the Fabric channel mechanism. Each hospital has a local ledger copy and private data collection, realizing an image sharing and collaboration model of "data immobility and permission-driven".

[0191] The system also has a built-in configurable anonymization policy engine that allows system administrators to independently define processing rules for image privacy fields based on institutional policies or regulatory requirements, achieving different levels of desensitization. Figure 10 This is a flowchart of the anonymization policy engine processing, showing how the system performs retention, deletion, blurring, or generalization operations on DICOM privacy fields according to the configured rules, thus achieving a configurable and auditable image de-identification processing path.

[0192] The policy engine supports the following field-level operations:

[0193] (1) Field Preservation: Specific fields are retained in ciphertext for subsequent association;

[0194] (2) Field deletion (Drop): The field is directly deleted from the DICOM file structure;

[0195] (3) Field fuzziness (Mask): Use wildcards or partial truncation to process, such as retaining the year of birth and erasing the day and month;

[0196] (4) Field generalization: Map the field content to a generalized set (such as "over 60 years old", "male").

[0197] Anonymization policies are stored as rule sets in the system configuration chaincode. A preprocessing module performs field parsing and conversion before each image upload. This conversion process is recorded in a privacy field summary structure for auditing and reverse restoration control. This mechanism enables the system to flexibly adapt to different national regulations and institutional data use agreements (such as GDPR, HIPAA, and China's Personal Information Protection Law).

[0198] The system has a local access cache control mechanism. When a user views an image, the decrypted image is only retained in temporary memory or a restricted sandbox environment at runtime. The image buffer data is cleared immediately after the access is completed to prevent long-term residue. Figure 11 To minimize local caching and access window control, this diagram shows how the decrypted image is limited to a short presentation in a sandbox environment. The image copy and key reference are automatically destroyed after the window is closed to prevent data from remaining or being illegally exported. The specific process is as follows:

[0199] (1) The image decryption module calls the memory sandbox management service to decode and display the image data in the isolated area;

[0200] (2) During image processing, the system does not allow users to save local copies, and the download function requires additional approval from the on-chain permission contract;

[0201] (3) Once the access window times out or the user actively closes the image view, the system automatically clears the buffered image data, session token, and key reference to ensure that "data can be seen but not retained."

[0202] This mechanism is applicable to high-leakage risk scenarios such as mobile devices, remote terminals, and shared reading stations, ensuring that images are displayed in read-only mode only within a controllable time, and implementing the Minimum Disclosure Principle from a technical perspective.

[0203] To better understand the practical application process of this application, we will now describe the entire process of a patient uploading medical images and authorizing a doctor to access them, using a specific scenario. This example uses the storage and sharing of DICOM images as the core object to demonstrate the collaborative operation of the various modules of the present invention and their functional implementation paths.

[0204] Suppose a patient undergoes a chest CT scan in Hospital A. The image is generated in DICOM format. The system will start the image sharing process through the image upload terminal.

[0205] Step 1: Image preprocessing and encryption compression

[0206] Patient imaging data is connected to the system through the hospital radiology department terminal and first processed by the image preprocessing module. The system automatically parses the DICOM file structure, separates the privacy fields (such as name, ID number, date of birth, etc.), and organizes them into structured tuples. . Then the image pixel data Use AES-GCM algorithm to encrypt and obtain the ciphertext image , and generate authentication tags at the same time . Compression module Perform JPEG2000 lossless compression to obtain compressed ciphertext . Finally, SHA-256 is used to generate the digest , for subsequent on-chain registration.

[0207] Step 2: Alliance chain registration and permission policy definition

[0208] The image upload system calls the alliance chain service module to hash the image , anonymize patient identifiers , X.509 certificate issued by the current medical institution , image generation timestamp And the default permission policy Submitted to the Hyperledger Fabric chain. The permission policy structure is defined as:

[0209] ;

[0210] in A collection of doctor certificate IDs that are authorized to access. The time interval for allowing access, Indicates the access operation type (e.g., read-only, downloadable). On-chain registration is completed by calling a pre-deployed Chaincode function. After registration is completed, the system returns the registration number and contract transaction hash for audit tracking.

[0211] Step 3: Upload the image file to the distributed storage network

[0212] Encrypted compressed image Submitted to the IPFS network. The system calls the IPFS client interface to store the image in blocks and generates a unique content address CID (Content Identifier):

[0213] ;

[0214] The CID is used as the off-chain physical location of the image and is hashed on the chain Mapping binding, the system Calculate the hash verification again:

[0215] ;

[0216] A successful verification indicates that the image upload is complete and has not been tampered with.

[0217] Step 4: Doctor applies for image access and authorization verification

[0218] After the image registration is completed, the authorized doctor of Hospital B enters his digital certificate and target image number I through the front-end system and initiates an image access request to the alliance chain. , current time ,image Submit the following parameters to the on-chain smart contract for permission verification:

[0219] ;

[0220] If the judgment result is 1, the contract returns the image CID and encryption key index location; otherwise, access is denied and the access behavior log is recorded on the chain.

[0221] Step 5: Image extraction, decryption, and DICOM reconstruction

[0222] The doctor terminal pulls images from the IPFS network through CID , and obtain the corresponding symmetric key through the key service The image restoration module performs the following process:

[0223] 1.AES-GCM decryption: ;

[0224] 2.JPEG2000 decompression: ;

[0225] 3. Privacy field reorganization: the previously separated and Resynthesize into a valid DICOM file D:

[0226] ;

[0227] After reconstruction is completed, doctors can browse, diagnose or annotate through medical imaging systems (such as PACS).

[0228] Step 6: Auditing access behavior on-chain

[0229] For every image access request (whether successful or not), the system records the operation log through Chaincode calls, including visitor identity, access time, access object image ID, response status, operation type and other information, and writes it to the consortium chain ledger in the form of transaction hash, making the entire operation process traceable and controllable.

[0230] It can be seen from the above embodiments that the present invention not only forms a closed-loop protection mechanism in terms of data security and access control, but also fully combines the immutability of blockchain, the verifiability of distributed storage, and the confidentiality of encryption algorithms in actual operation, thereby realizing a standardized, trusted, and compliant processing flow for medical image sharing.

[0231] An embodiment of the present application further provides a computer device, comprising a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of the method.

[0232] An embodiment of the present application further provides a computer-readable storage medium having a computer program / instruction stored thereon, which implements the steps of the method when the computer program / instruction is executed by a processor.

[0233] An embodiment of the present application also provides a computer program product, including a computer program / instruction, which implements the steps of the method when executed by a processor.

[0234] The memory may be of any type suitable for the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory, and removable memory. The processor may be of any type suitable for the local technical environment and may include, by way of non-limiting example, one or more of a general-purpose computer, a special-purpose computer, a microprocessor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), an FPGA, a gate-level circuit, and a processor based on a multi-core processor architecture.

[0235] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some or all of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A medical image storage and sharing method based on alliance chain, characterized by: Including the following step: S1: Image preprocessing and encryption compression, including: S1.1: Separate the patient's privacy fields in the original medical image to generate an independent privacy field set ; S1.2: Pixel data in original medical images Perform authentication encryption and set the encryption key to , the initial vector is , output encrypted image and certification labels ; S1.3: Encrypted image Perform lossless compression to generate compressed encrypted images ; S1.4: Yes Generate image hash digest using hash algorithm , for integrity verification and on-chain registration: S2: Alliance chain registration and permission policy definition, including: S2.1: Patient Anonymity , image hash summary , upload timestamp , uploader certificate hash , image tags To register objects and serve as metadata; S2.2: Call the pre-deployed smart contract on the chain and pass the above metadata and access policy structure Write to the block ledger; S2.3: Verify whether the contract is passed. If the verification is passed, the transaction hash, version number, and metadata of the registration process will be sent to Fabric for subsequent audit and on-chain verification. If the verification fails, the registration will be rejected. S3: Upload the desensitized, encrypted, and compressed medical image files in step S1 to a distributed storage network, and perform content-addressable storage on the medical image files through the IPFS network; S4: Access control: Authentication and permission determination of user image access requests; S5: Image reconstruction: restore the original image to the authorized user; S6: Access behavior is audited on the chain.

2. The medical image storage and sharing method based on alliance chain according to claim 1 is characterized in that: Step S3 includes: S3.1: Use the IPFS system to compress and encrypt images Perform content-addressable storage, generate a unique content address CID, and implement image data sharding and redundant backup through the Merkle-DAG structure; At this stage, the compressed encrypted image Establish a binding relationship with the image CID stored in IPFS; S3.2: IPFS system records CID and image hash summary One-to-one mapping relationship, and maintain the consistency of on-chain and off-chain data through on-chain registration; S3.3: In the subsequent image access process, the data is pulled from IPFS through the CID and registered on the chain To verify the benchmark, an integrity check is performed.

3. The medical image storage and sharing method based on alliance chain according to claim 2 is characterized in that: Step S4 includes: S4.1: Receive the visitor's digital identity with the image request number , and submit it to the on-chain access control contract for permission judgment; S4.2: The access decision function is as follows: ； in, representation and relationships; S4.3: If authorization is successful, the image CID, decryption key index, and access token are returned; if authorization fails, access is denied, and the access behavior and results are synchronously recorded in the blockchain.

4. The medical image storage and sharing method based on alliance chain according to claim 3 is characterized by: Step S5 includes: S5.1: Use the obtained CID to pull the compressed encrypted image from IPFS and obtain the symmetric key through the key management service ; S5.2: Perform decryption operation to obtain the image ciphertext decryption result , then perform decompression to restore pixel data ; S5.3: Finally, the decrypted image Separate privacy fields from the initial set Merge and restore legal DICOM format images.

5. The medical image storage and sharing method based on alliance chain according to claim 1 is characterized in that: Access policy structure Expressed as: ； in, Indicates the set of users allowed to access. To allow access to time windows, The time to start the visit, End of visit time, Indicates the access permission level; Access policy structure Supports dynamic update mechanism, allowing authorized subjects to make subsequent adjustments to the permission list, time window and access mode of registered images; Access policy adjustments are initiated by the system administrator or image uploader by calling the on-chain smart contract interface to conduct a policy change transaction. The transaction structure contains the image identifier, the policy change content, and the digital signature of the change initiator to ensure that the source of the policy modification is credible and verifiable; After receiving a policy change request, the smart contract will verify the initiator's identity and, if the verification is successful, perform an overwrite update on the on-chain access control field. The policy update transaction will generate an independent transaction hash and record the version number to support future access behavior aligned with the policy snapshot, ensuring that the system supports fine-grained management and long-term evolution control of image permissions.

6. The medical image storage and sharing method based on alliance chain according to claim 5 is characterized in that: Access policies support role-based access control models and multi-signature approval mechanisms, allowing dynamic allocation of access rights based on the role category held by the visitor.

7. The medical image storage and sharing method based on alliance chain according to claim 5 is characterized in that: The system also supports embedded watermark generation and traceability mechanisms during image access. When an image is legally authorized for access and decrypted and restored, the system will automatically embed a digital watermark of the visitor's identity into the image to support source tracing of subsequent image leakage incidents.

8. The medical image storage and sharing method based on alliance chain according to claim 1 is characterized in that: The local access cache control mechanism is supported during the access process. When the user views the image, the decrypted image is only retained in temporary memory or a restricted sandbox environment at runtime. The image buffer data is cleared immediately after the access is completed to prevent long-term residual data. The specific process is as follows: (1) When decrypting an image, the memory sandbox management service is called to decode and display the image data in an isolated area; (2) Users are not allowed to save local copies during image processing, and the download function requires additional approval from the on-chain permission contract; (3) Once the access window times out or the user actively closes the image view, the buffered image data, session token, and key reference are automatically cleared.

9. A medical image storage and sharing system based on alliance chain, characterized by: include: Image preprocessing module: used to perform structured separation and encryption compression processing on medical images, and output desensitized, encrypted, and compressed medical image files and corresponding content summaries for subsequent on-chain registration and integrity verification; Alliance chain registration module: used to register, verify and track medical image metadata and access control policies; Distributed storage module: Use the IPFS network to perform content-addressable storage of medical image files; Access Control Module: This module is used to authenticate and determine the permissions of user image access requests. It authorizes on-chain access by combining user identity, role permissions, and policy rules. It also supports role-based access control models and multi-signature approval mechanisms. Image decryption and reconstruction module: used to complete image pulling, decryption, decompression and privacy reconstruction after permission verification, and restore the original medical image.

10. The medical image storage and sharing system based on alliance chain according to claim 9, characterized in that: The system also has a built-in configurable anonymization policy engine, allowing system administrators to independently define processing rules for image privacy fields based on institutional policies or regulatory requirements, achieving different levels of desensitization. The anonymization policy engine supports the following field-level operations: (1) Field retention: Specific fields are retained in ciphertext for subsequent association; (2) Field deletion: the field is directly deleted from the original medical image file structure; (3) Field fuzziness: Use wildcards or partial truncation to handle; (4) Field generalization: mapping field content to a generalized set; The anonymization strategy is saved in the system configuration chaincode in the form of a rule set. The image preprocessing module performs field parsing and conversion before each image is uploaded. The conversion process is recorded in the privacy field summary structure for auditing and reverse restoration control.

Images