Medical image security management method and system based on block chain

Abstract

The invention discloses a medical image security management method and system based on a block chain, and the method comprises the steps: obtaining an initial medical image, carrying out the channel division of the initial medical image, and obtaining a plurality of pieces of channel image data; performing encryption processing on the plurality of channel image data to obtain encrypted image data and a verification value, storing the encrypted image data to a plurality of different storage nodes, and transmitting a storage address and the verification value to a preset block chain; generating a dynamic access strategy based on a preset block chain, and when an access request is received, generating an access token corresponding to the access request based on the dynamic access strategy; and generating plaintext watermark data based on target channel image data in the multiple pieces of channel image data, and generating an access result corresponding to the access request based on the plaintext watermark data and the access token. According to the method and the device, the safety, the reliability and the auditing performance of the medical image in the whole process of storage, sharing and use can be remarkably improved.

Description

Technical Field

[0001] This application relates to the field of blockchain encryption technology, specifically to a blockchain-based medical image security management and system. Background Technology

[0002] In the crucial area of ​​medical data management within the modern healthcare system, patient privacy protection, data security, and cross-institutional collaboration efficiency are paramount. Medical images, as core data for diagnosis and treatment, require secure storage and efficient sharing, which is a core task in the development of medical informatization. Currently, traditional centralized storage systems, due to single-point-of-failure risks and data leakage, as well as the lack of effective privacy protection mechanisms, are insufficient to meet practical needs. While existing blockchain technology, with its decentralized, tamper-proof, and highly transparent characteristics, has been widely explored and applied to medical data management, it is limited by high on-chain storage costs and complex access controls, failing to simultaneously meet the dual demands of efficiency and compliance in medical scenarios. Furthermore, cross-institutional data sharing faces challenges related to insufficient standardization and traceability, further hindering the improvement of collaboration efficiency.

[0003] Therefore, how to securely manage unwanted images based on blockchain is an urgent problem to be solved. Summary of the Invention

[0004] To address the aforementioned technical problems, embodiments of this application provide a blockchain-based medical image security management method and system.

[0005] According to one aspect of the embodiments of this application, a blockchain-based medical image security management method is provided, comprising: acquiring an initial medical image; dividing the initial medical image into channels to obtain multiple channel image data; encrypting the multiple channel image data respectively to obtain encrypted image data and a verification value; storing the encrypted image data in multiple different storage nodes; and transmitting the storage address and the verification value to a preset blockchain; generating a dynamic access policy based on the preset blockchain; and generating a corresponding access token based on the dynamic access policy when an access request is received; generating plaintext watermark data based on the target channel image data in the multiple channel image data; and generating an access result corresponding to the access request based on the plaintext watermark data and the access token.

[0006] According to one aspect of the embodiments of this application, the method includes: parsing the access request, and determining an access identity identifier corresponding to the access request and a permission level corresponding to the access identity identifier based on the parsing result; generating a corresponding access token based on the access identity identifier, the permission level, and the dynamic access policy.

[0007] According to one aspect of the embodiments of this application, the method further includes: if the access identity identifier satisfies the dynamic access policy, then generating the access token based on the permission level, the access token including access duration, access permissions, forwarding restrictions, and image clarity; if the image integrity satisfies a preset integrity threshold, then obtaining the associated image set corresponding to the initial medical image; determining the treatment data corresponding to the associated image set, and generating the access result corresponding to the access request based on the associated image set and the treatment data.

[0008] According to one aspect of the embodiments of this application, generating plaintext watermark data based on target channel image data among the plurality of channel image data includes: determining target channel image data from the plurality of channel image data based on the permission level, wherein the permission level is positively correlated with the confidentiality of the channel corresponding to the target channel image data; and generating plaintext watermark data based on the access identity identifier and the target channel image data.

[0009] According to one aspect of the embodiments of this application, the method further includes: obtaining address information corresponding to the access request, the address information including a geographical location and an IP address; determining an access identity identifier corresponding to the access request based on the IP address, and determining the access permissions of the access token based on the geographical location.

[0010] According to one aspect of the embodiments of this application, the preset blockchain is a consortium blockchain, and the step of generating a dynamic access policy based on the preset blockchain includes: obtaining a smart contract deployed on the consortium blockchain, the smart contract being used to manage access control policies for medical images; obtaining the patient authorization status and data sensitivity corresponding to the initial medical image; and generating a dynamic access policy corresponding to the initial medical image based on the patient authorization status, the data sensitivity, and the smart contract.

[0011] According to one aspect of the embodiments of this application, the method further includes: obtaining voting information submitted by each node on the consortium blockchain, and determining the voting result based on the voting information; determining a smart contract for the consortium blockchain based on the voting result, wherein the smart contract includes an access policy template, access policy monitoring, and a dynamic implementation strategy for the smart contract.

[0012] According to one aspect of the embodiments of this application, the method further includes: determining an accesser role based on an access identity identifier, and determining a private key corresponding to the accesser role; comparing the private key with the verification value, and if the private key matches the verification value, determining that the access request satisfies the dynamic access policy; decrypting the encrypted image data, and generating an access result based on the decrypted image data and plaintext watermark data.

[0013] According to one aspect of the embodiments of this application, the method further includes: generating a zero-knowledge proof corresponding to the visitor role, the zero-knowledge proof being used to prove the legitimate identity possessed by the visitor role; and determining a private key corresponding to the visitor role based on the legitimate identity.

[0014] According to one aspect of the embodiments of this application, a blockchain-based medical image security management system is provided. The system includes: an acquisition module, configured to acquire an initial medical image, divide the initial medical image into channels to obtain multiple channel image data; an encryption module, configured to encrypt the multiple channel image data respectively to obtain encrypted image data and a verification value, store the encrypted image data in multiple different storage nodes, and transmit the storage address and the verification value to a preset blockchain; an access module, configured to generate a dynamic access policy based on the preset blockchain, and generate a corresponding access token based on the dynamic access policy when an access request is received; and a watermarking module, configured to generate plaintext watermark data based on the target channel image data in the multiple channel image data, and generate an access result corresponding to the access request based on the plaintext watermark data and the access token.

[0015] According to one aspect of the embodiments of this application, an electronic device is provided, including: one or more processors; and a storage device for storing one or more programs, which, when executed by the one or more processors, cause the electronic device to implement the blockchain-based medical image security management method as described above.

[0016] According to one aspect of the embodiments of this application, a computer-readable storage medium is provided, on which computer-readable instructions are stored, which, when executed by a computer's processor, cause the computer to perform the blockchain-based medical image security management method as described above.

[0017] According to one aspect of the embodiments of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps in the blockchain-based medical image security management method as described above.

[0018] In the technical solution provided by the embodiments of this application, by dividing the initial medical images into channels and encrypting them separately, not only is data confidentiality enhanced by multi-channel independent encryption, but the integrity of each channel's data can also be monitored in real time through check values, effectively resisting single-point attacks and data tampering risks. Then, the encrypted data is distributed and stored on multiple nodes, and the storage address and check value are recorded on the blockchain. This eliminates the risk of single-point failure through a decentralized architecture and ensures the trustworthy traceability of data storage by leveraging the immutability of the blockchain. Furthermore, the dynamic access policy generated based on the blockchain can adjust the permission scope in real time, and together with the access token mechanism, it achieves fine-grained access control, ensuring compliant use of data while preventing unauthorized access. Finally, a plaintext watermark is generated from the target channel image and associated with the access token, which can accurately locate the source of the leak and the responsible party in the event of a data breach, forming a complete data security closed loop. This solution significantly improves the security, reliability, and auditability of medical images throughout the entire process of storage, sharing, and use through the synergistic effect of channel encryption, distributed storage, dynamic permission management, and watermark traceability.

[0019] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0020] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings: Figure 1 This is a schematic diagram illustrating the structure of a blockchain system as shown in an exemplary embodiment of this application; Figure 2 This is a schematic diagram illustrating an implementation environment for blockchain-based medical image security management, as shown in an exemplary embodiment of this application. Figure 3 This is a flowchart illustrating a blockchain-based medical image security management method, as shown in an exemplary embodiment of this application. Figure 4 This is a flowchart illustrating a blockchain-based medical image security management method, as shown in another exemplary embodiment of this application. Figure 5 This is a flowchart illustrating a blockchain-based medical image security management method, as shown in another exemplary embodiment of this application. Figure 6 This is a flowchart illustrating a blockchain-based medical image security management method, as shown in another exemplary embodiment of this application. Figure 7 This is a flowchart illustrating a blockchain-based medical image security management method, as shown in another exemplary embodiment of this application. Figure 8 This is a flowchart illustrating a blockchain-based medical image security management method, as shown in another exemplary embodiment of this application. Figure 9 This is a flowchart illustrating a blockchain-based medical image security management method, as shown in another exemplary embodiment of this application. Figure 10 This is a flowchart illustrating a blockchain-based medical image security management method, as shown in another exemplary embodiment of this application. Figure 11 This is a flowchart illustrating a blockchain-based medical image security management method, as shown in another exemplary embodiment of this application. Figure 12 This is a block diagram illustrating a blockchain-based medical image security management system, as shown in an exemplary embodiment of this application. Figure 13 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown. Detailed Implementation

[0021] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of systems and methods consistent with some aspects of this application as detailed in the appended claims.

[0022] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0023] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0024] In this application, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0025] First, it's important to clarify that blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. Essentially, a blockchain is a decentralized database, a chain of data blocks (i.e., blocks) linked together using cryptographic methods. Each data block contains information about a batch of network transactions, used to verify the validity of the information (anti-counterfeiting) and to generate the next block. A blockchain can include an underlying platform, a platform product and service layer, and an application service layer.

[0026] As mentioned above, a blockchain is essentially a decentralized database, and it is maintained collaboratively by nodes within a blockchain network. For example, please refer to [link to relevant documentation]. Figure 1 ,exist Figure 1 The blockchain network 200 shown may include multiple blockchain nodes 201, 202, 203, and 20n, etc. Each blockchain node, in its normal operation, receives input information and maintains shared data within the blockchain network based on this information. To ensure information exchange within the blockchain network, information connections exist between each blockchain node, allowing for information transmission. For example, when any blockchain node receives input information, other blockchain nodes in the network obtain this input information according to a consensus algorithm and store it as shared data, ensuring data consistency across all blockchain nodes.

[0027] Each blockchain node in a blockchain network has a corresponding node identifier, and each node can store the node identifiers of other blockchain nodes. This allows for the subsequent broadcasting of generated blocks to other blockchain nodes based on their identifiers. Each blockchain node can maintain a list of node identifiers, storing the node name and its corresponding identifier. The node identifier can be an IP address (Internet Protocol) address or any other information that can be used to identify the node.

[0028] Each blockchain node in a blockchain network stores the same blockchain. See also Figure 2As shown, a blockchain consists of multiple blocks. The genesis block includes a block header and a block body. The block header stores input information features, version number, timestamp, and difficulty value, while the block body stores the input information. The next block after the genesis block takes the genesis block as its parent block. The next block also includes a block header and a block body. The block header stores the input information features of the current block, the block header features of the parent block, version number, timestamp, and difficulty value, and so on. This ensures that the block data stored in each block is related to the block data stored in the parent block, guaranteeing the security of the input information in the blocks.

[0029] It is understood that each blockchain node in a blockchain network can be a server or a terminal. A server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and intelligent platforms. A terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, terminal used in a car, aircraft, etc., but is not limited to these. Blockchain nodes can be directly or indirectly connected via wired or wireless communication, and this application does not impose any restrictions on this.

[0030] Please see Figure 2 , Figure 2 This application provides a blockchain-based medical image security management system, such as... Figure 2 As shown, the blockchain-based medical image security management system includes a blockchain network 200 and a terminal device 210. A communication connection is established between the blockchain network 200 and the terminal device 210. The terminal device 210 can include any one or more of the following: sensors, smartphones, tablets, laptops, desktop computers, smart vehicles, and smart wearable devices. The terminal device 210 can run testing applications (such as JMeter), and can also run various other applications (APPs), such as game clients, virtual interaction clients, multimedia playback clients, social clients, information streaming clients, etc.

[0031] Figure 2 The blockchain network 200 shown can specifically be a system for data sharing between nodes. This blockchain network 200 can include multiple blockchain nodes (simply referred to as nodes, or consensus nodes), such as... Figure 2Blockchain nodes 201 to 204 are shown; among them, Figure 2 The ellipsis in the code indicates that the blockchain network 200 also includes other blockchain nodes. Blockchain nodes are the basic components of the entire blockchain system, responsible for processing transactions, storing blockchain data, and participating in consensus.

[0032] Each blockchain node in a blockchain network 200 stores the same blockchain (also known as a block ledger), that is... Figure 2 The blockchain ledger (model 205) is the core data structure of a blockchain system, used to store and manage all confirmed blocks. Organized in a chain-like structure, each block contains a set of transactions, a block header (including metadata such as the hash value and timestamp of the previous block), and other information. The ledger provides a public, immutable history of transactions for the blockchain system, ensuring transparency and consistency.

[0033] Furthermore, each blockchain node, in its normal operation, receives input information and maintains shared data within the blockchain network 200 based on this received input information. To ensure information exchange within the blockchain network 200, such as... Figure 2 As shown, each blockchain node in the blockchain network 200 can have a wired or wireless communication connection, and information can be transmitted between the blockchain nodes through the aforementioned communication connection.

[0034] For example, when any blockchain node in blockchain network 200 responds to a transaction request and executes the requested transaction, it can package the executed transaction as input information into a block. Upon receiving this block, other blockchain nodes in blockchain network 200 process it according to the consensus algorithm. After consensus is reached, the block is stored as data in the shared data, ensuring that the data stored on all blockchain nodes in blockchain network 200 is consistent.

[0035] In the crucial area of ​​medical data management within the modern healthcare system, patient privacy protection, data security, and cross-institutional collaboration efficiency are paramount. Medical images, as core data for diagnosis and treatment, require secure storage and efficient sharing, which is a core task in the development of medical informatization. Currently, traditional centralized storage systems, due to single-point-of-failure risks and data leakage, as well as the lack of effective privacy protection mechanisms, are insufficient to meet practical needs. While existing blockchain technology, with its decentralized, tamper-proof, and highly transparent characteristics, has been widely explored and applied to medical data management, it is limited by high on-chain storage costs and complex access controls, failing to simultaneously meet the dual demands of efficiency and compliance in medical scenarios. Furthermore, cross-institutional data sharing faces challenges related to insufficient standardization and traceability, further hindering the improvement of collaboration efficiency.

[0036] To address these issues, embodiments of this application propose a blockchain-based medical image security management method, a blockchain-based medical image security management system, an electronic device, a computer-readable storage medium, and a computer program product, which will be described in detail below.

[0037] Please see Figure 3 , Figure 3 This is a flowchart illustrating a blockchain-based medical image security management method as an exemplary embodiment of this application. This method can be applied to... Figure 2 The implementation environment shown is specifically executed by the terminal device 210 within that implementation environment. It should be understood that this method can also be applied to other exemplary implementation environments and executed by devices in other implementation environments; this embodiment does not limit the implementation environment to which the method is applicable.

[0038] like Figure 3 As shown, in an exemplary embodiment, the blockchain-based medical image security management method includes at least steps S310 to S340, which are described in detail below: Step S310: Obtain the initial medical image, divide the initial medical image into channels, and obtain multiple channel image data.

[0039] For example, in a medical image processing workflow, the initial medical image in the original Digital Imaging and Communications in Medicine (DICOM) format is first obtained through the hospital PACS system or medical imaging equipment interface. This image typically contains multiple data channels (such as a color CT image with RGB three channels or overlay data of medical images of different modalities). The system adopts a channel partitioning algorithm based on deep learning, and the specific implementation process is as follows: First, the image is input into a pre-trained convolutional neural network (such as the feature extraction layer of ResNet-50), and the channel data of different frequency domains and semantic features are automatically extracted through the sliding window operation of the convolutional kernel; for multimodal medical images (such as CT plus MRI fused images), a multi-channel attention mechanism is adopted, and the correlation matrix between each modality channel is calculated (such as using the self-attention module of Transformer), and the channels with correlation weights lower than the threshold (0.3) are separated into independent data blocks; for the special structure of DICOM images, the system will prioritize separating the metadata channel (a tag group containing patient privacy information) from the pixel data channel, and use the SHA-256 hash algorithm to generate an irreversible digest for the metadata channel, while the pixel data channel is based on the Photometric in the DICOM standard. Interpretation tags (such as RGB, MONOCHROME2) are used to decouple the color space. During the channel partitioning process, the system dynamically maintains the channel relationship graph, records the dependencies between channels (such as whether a channel is the differential encoding result of other channels), and stores the graph as part of the digital signature in the blockchain. The final generated image data of multiple channels will be assigned a unique identifier (UUID), which combines the image's StudyInstance UID and the channel feature fingerprint (generated by a perceptual hash algorithm) to ensure the traceability of channel data in subsequent processing. The entire channel partitioning process is executed in the local secure computing environment of the medical institution. All intermediate results are encrypted with AES-256. The key is generated by the Hardware Security Module (HSM) and distributed to authorized nodes using a threshold key sharing scheme (such as Shamir secret sharing).

[0040] Step S320: Encrypt the image data from multiple channels separately to obtain encrypted image data and verification values. Store the encrypted image data in multiple different storage nodes and transmit the storage address and verification value to the preset blockchain.

[0041] For example, in a medical image processing workflow, the initial medical image in raw DICOM format is first obtained through a hospital PACS system or medical imaging equipment interface. This image typically contains multiple data channels (such as a color CT image with RGB three channels or overlay data of medical images of different modalities). The system adopts a channel partitioning algorithm based on deep learning, and the specific implementation process is as follows: First, the image is input into a pre-trained convolutional neural network (such as the feature extraction layer of ResNet-50), and the channel data of different frequency domains and semantic features are automatically extracted through the sliding window operation of the convolutional kernel; for multimodal medical images (such as CT+MRI fused images), a multi-channel attention mechanism is adopted, and by calculating the correlation matrix between each modality channel (such as using the self-attention module of Transformer), channels with correlation weights lower than the threshold (0.3) are separated into independent data blocks; for the special structure of DICOM images, the system will prioritize separating metadata channels (containing patient privacy information). The system uses a combination of signature groups and pixel data channels. For the metadata channel, an irreversible digest is generated using the SHA-256 hash algorithm, while the pixel data channel is decoupled in color space according to the photometric interpretation labels in the DICOM standard (such as RGB and MONOCHROME2, which describes the mapping relationship between pixel values ​​and actual brightness in monochrome medical images). During the channel partitioning process, the system dynamically maintains a channel relationship graph, records the dependencies between channels (such as whether a channel is the differential encoding result of other channels), and stores this graph as part of the digital signature in the blockchain. The final generated image data for multiple channels is assigned a unique identifier (UUID), which combines the image's Study Instance UID and the channel feature fingerprint (generated by a perceptual hash algorithm) to ensure the traceability of channel data in subsequent processing. The entire channel partitioning process is executed in the local secure computing environment of the medical institution. All intermediate results are encrypted using AES-256, and the key is generated by the Hardware Security Module (HSM) and distributed to authorized nodes using a threshold key sharing scheme (such as Shamir secret sharing).

[0042] Step S330: Generate a dynamic access policy based on a preset blockchain, and generate an access token corresponding to the access request based on the dynamic access policy when an access request is received.

[0043] For example, a smart contract system needs to be built first as the core of policy management. This smart contract should include a policy template library (storing predefined access rule templates), a policy generation engine (supporting dynamic parameter combinations), and a token verification module. The specific implementation process is as follows: When the system initializes, the administrator submits basic policy templates to the blockchain through a secure channel. These templates are defined in JSON Schema format and include placeholder fields such as subject attributes (e.g., role, department), resource path (URI pattern), operation type (CRUD), and time constraints. When an access request is received, the requester (e.g., a user or service) first sends a metadata packet containing identity credentials and request context to the policy generation node. After confirming the requester's identity through an off-chain authentication service (e.g., OAuth 2.0 or DID verification), the node reads the latest policy template from the blockchain and dynamically populates parameters based on the current system state (e.g., resource load, security level). For example, for access to sensitive data in a healthcare system, the system automatically binds the "doctor" role to the current shift, generating a policy rule similar to {"subject": {"role": "doctor", "shift": "2023-11-15T09:00-17:00"}, "resource": " / patient / records / *", "action": "read", "validity": 3600}. The policy generation engine uses the Attribute-Based Encryption (ABE) algorithm to encrypt the rule, ensuring that only a qualified requester can decrypt it. Subsequently, the system calls the on-chain token minting contract to combine the policy rule hash, expiration timestamp, and random salt value to generate a unique token identifier, and uses asymmetric encryption to generate a digital signature containing a policy digest. The token itself is in JWT format, but the policy rule is stored on the blockchain in Merkle Tree form, with only the root hash included in the token as proof of existence. During verification, the resource server verifies the token's validity through the smart contract's zero-knowledge proof interface, confirming access rights without needing to obtain the original policy content. The entire process achieves auditability through blockchain event logs, with each policy change and token generation recording an immutable timestamp and operation record. To optimize performance, the system uses off-chain state channels to handle high-frequency token verification, arbitrating only through the blockchain in case of disputes. Dynamic policy adjustments are implemented through governance contracts, supporting emergency policy updates based on threshold signatures (such as 3 / 5 multi-signatures), ensuring a rapid response in the event of security incidents. This design guarantees both the dynamic adjustability of the policy and maintains the security of access control through the immutability of the blockchain.

[0044] Step S340: Generate plaintext watermark data based on the target channel image data from multiple channel image data, and generate the access result corresponding to the access request based on the plaintext watermark data and the access token.

[0045] For example, upon receiving an access request, the system first parses the access token carried in the request and verifies the token's validity through a blockchain smart contract (including signature verification, policy matching, and timestamp checking) to confirm that the requester has access to the target channel data. After successful verification, the system retrieves the corresponding target channel image data from distributed storage, which has already been encrypted and stored on the blockchain through the preceding process. Subsequently, the system enters the watermark generation stage: using a frequency domain watermarking algorithm (such as Discrete Wavelet Transform (DWT) or Discrete Cosine Transform (DCT), the target channel image data is converted to the transform domain, embedding plaintext watermark information in a high-frequency sub-band that does not affect the validity of medical diagnosis. The watermark content consists of three parts: 1) the requester's unique identifier (such as DID or device MAC address hash); 2) the access timestamp (accurate to milliseconds); and 3) the blockchain transaction hash (associated with the currently accessed storage record). To enhance robustness, the watermark is modulated using spread spectrum technology and its anti-interference capability is improved through error correction coding (such as BCH codes). After embedding, the system associates and maps the watermarked image data with the policy rules in the access token: by extracting the policy digest (such as resource URI and operation type) from the token, it generates corresponding access result description metadata, which includes the watermark location index, verification polynomial, and access behavior label. Finally, the system encapsulates the watermarked image data, watermark verification parameters, and access result metadata into a structured response package. The image data remains in its original encrypted state (only authorized parties can decrypt it), while the watermark information is indirectly verified through token association. Upon receiving the response, the accessing party can recover the plaintext watermark from the image using a watermark extraction algorithm (knowing the embedding key), and then verify the consistency between the watermark content and the access record using a blockchain query interface. The entire process forms a closed-loop verification: the watermark serves as physical layer evidence, the token as logical layer credential, and the blockchain as evidence storage layer security. The cross-verification of these three ensures the data source is trustworthy, the access behavior is traceable, and the content has not been tampered with. The system also supports dynamic watermark strength adjustment, automatically adjusting the embedding strength based on image sensitivity (such as through sensitivity markers in DICOM tags), maximizing anti-counterfeiting capabilities while ensuring diagnostic quality.

[0046] In some embodiments of this application, by dividing channels, encrypting and storing medical image data on different nodes, and using blockchain to record verification values ​​to generate dynamic access policies, and combining the target channel image data to generate plaintext watermark data, the access results can be generated. This can effectively ensure the secure storage, flexible access control, and traceability of the data source of medical image data.

[0047] Furthermore, based on the above embodiments, please refer to... Figure 4 In one exemplary embodiment provided in this application, the specific implementation process of the above-mentioned blockchain-based medical image security management method may further include steps S410 and S420, which are described in detail below: Step S410: Parse the access request and determine the access identity identifier corresponding to the access request and the permission level corresponding to the access identity identifier based on the parsing result; Step S420: Generate a corresponding access token based on the access identity, permission level, and dynamic access policy.

[0048] For example, when an access request arrives at the system entry point, the request data packet (usually an HTTP request or gRPC message) first passes through the protocol parsing layer to extract key identity information, including but not limited to: digital certificates submitted by the requester (such as X.509 format), OAuth 2.0 access tokens, biometric hashes (such as encrypted digests of fingerprints or voiceprints), or Distributed Identity Identifiers (DIDs). The system employs a layered parsing strategy: for structured requests (such as REST API calls), the identity claim fields in the JSON / XML payload are directly parsed; for unstructured requests (such as binary protocols), the identity identifier in the header information is extracted through a predefined protocol parser. After the identity identifier is parsed, the system enters the identity authentication phase, verifying the validity of the identifier through an off-chain identity service (such as an LDAP directory service or a blockchain identity registry) and obtaining the associated set of permission attributes. The determination of permission levels adopts an attribute-based access control (ABAC) model: the system extracts data from the attribute set associated with the identity identifier, including dimensions such as role (e.g., "attending physician", "radiology intern"), department (e.g., "cardiovascular surgery"), and security permission level (e.g., "confidential"), and combines this with dynamic permission policies stored on the blockchain (e.g., "cardiovascular surgery attending physicians can access CT images from the past 72 hours during their on-call hours"), and performs real-time calculations through policy decision points (PDPs). This calculation process involves: 1) pattern matching of identity attributes with conditional expressions in policy rules; 2) application of time window constraints (e.g., verifying on-call hours using timestamps synchronized with NTP); and 3) dynamic adjustment through resource sensitivity marking (e.g., sensitivity levels in DICOM tags). The policy engine uses the RETE algorithm to optimize rule matching efficiency and supports millisecond-level permission determination. After determining the permission level, the system enters the token generation stage: first, a token payload containing identity identifier, permission declaration, and context information is constructed, using JWT (JSON Web Token) format but with customized extensions, adding blockchain notarization fields (e.g., "policy hash" and "audit log pointer"). Subsequently, an asymmetric key pair is generated via the Hardware Security Module (HSM). The private key is used to digitally sign the token, while the public key is registered in the blockchain's DID document via a smart contract. The integration of dynamic access policies adopts a Policy as Code (PaC) paradigm: the system reads the latest policy rules from the blockchain (verifying data integrity through Merkle proofs), compiles them into executable policy fragments, and embeds them into the token generation process. For example, when a high-risk operation is detected (such as bulk downloading image data), a multi-factor authentication (MFA) process is automatically triggered, embedding a temporary challenge code (such as a TOTP seed) into the token, requiring the requester to provide a dynamic verification code in subsequent interactions.The generated access token employs layered encryption: the outer layer uses transport layer encryption (such as TLS 1.3) to protect channel security, the inner layer encrypts the token payload using national cryptographic algorithms (such as SM4), and the key is dynamically generated through a key negotiation protocol (such as ECDHE). The token validity period uses a sliding window mechanism: the base validity period (such as 1 hour) can be dynamically adjusted via a blockchain oracle based on access behavior characteristics (such as access frequency and resource sensitivity). The entire process forms a closed-loop verification: the identity resolution result, the permission calculation process, and the token generation operation are all recorded as blockchain events, and compliance checks can be performed subsequently through audit contracts. The system also supports on-chain registration of tokens, generating a unique digital fingerprint for the token through a smart contract and storing it on the blockchain, achieving full lifecycle traceability of the token. This design ensures both the real-time nature of token generation (average processing latency <200ms) and the immutability of permission determination through blockchain notarization.

[0049] In some embodiments of this application, by parsing access requests to clarify the visitor's identity and permission level, and by generating access tokens in conjunction with dynamic access policies, fine-grained permission control and dynamic secure access management can be achieved, effectively preventing unauthorized access and improving system security.

[0050] Furthermore, based on the above embodiments, please refer to... Figure 5 In one exemplary embodiment provided in this application, the specific implementation process of the above-mentioned blockchain-based medical image security management method may further include steps S510 to S530, which are described in detail below: Step S510: If the access identity meets the dynamic access policy, an access token is generated based on the permission level. The access token includes access duration, access permissions, forwarding restrictions, and image clarity.

[0051] For example, after the access identity is verified by the policy engine, the system first dynamically generates an access token based on the permission level. This token adopts a structured design and includes four core modules: 1) Access duration control, which sets the validity period based on the permission level and resource sensitivity (e.g., 2 hours for general practitioners, 24 hours for department heads), and hard-encodes the timestamp synchronized by the Network Time Protocol (NTP) obtained through a blockchain oracle; 2) Access permission scope, which adopts a hybrid RBAC and ABAC model to map the permission level to a specific operation list (e.g., "DICOM image reading", "3D reconstruction calculation"), and embeds resource path wildcards (e.g., / patient / {id} / mri / *); 3) Forwarding restriction rules, which restricts the data-using terminals through a blockchain-stored device fingerprint list, and uses a hardware security module (HPM) to generate a device-bound token segment; 4) Image clarity parameters, which dynamically allocate resolution based on the permission level and diagnostic needs (e.g., "diagnostic level 1024×1024" or "reference level 256×256"), and this parameter is written to the optional declaration segment of the token through asymmetric encryption.

[0052] Step S520: If the access permission meets the preset access permission level, then obtain the associated image set corresponding to the initial medical image; Step S530: Determine the treatment data corresponding to the associated image set, and generate the access result corresponding to the access request based on the associated image set and the treatment data.

[0053] For example, after the token is generated, the system enters a deep permission verification phase: if the access permission level reaches a preset threshold (such as "attending physician" or above), the associated data retrieval process is automatically triggered. At this time, the system calls the medical knowledge graph service to query the metadata index stored on the blockchain through the patient ID and examination type (such as "chest CT") to locate the associated image set corresponding to the initial medical image (such as multi-phase enhanced CT sequences of the same patient or MRI slices of adjacent anatomical planes). The acquisition of the associated image set adopts a distributed query protocol, and each storage node returns data along with a hash chain proof of the blockchain evidence to ensure that the data has not been tampered with. After acquiring the associated image set, the system initiates treatment data correlation analysis: First, it extracts electronic medical record (EMR) fragments from the blockchain smart contract and parses the treatment keywords (such as "targeted therapy for lung cancer" and "radiotherapy plan verification") using natural language processing (NLP); second, it calls the Clinical Decision Support System (CDSS) to perform spatiotemporal correlation analysis between associated image features (such as tumor volume and lymph node status) and dose parameters and time points in the treatment data; finally, it generates a comprehensive analysis report through a federated learning model (deployed in a secure execution environment (TEE)). This report includes structured data such as treatment response prediction and complication risk assessment. The generation of access results adopts a layered encapsulation technology: the base layer is watermarked image data (the watermark content includes token hash and access timestamp), the middle layer is the treatment data correlation analysis results (JSON format), and the outermost layer is a blockchain notarization pointer (pointing to the transaction hash storing the analysis report summary). For highly sensitive results (such as image analysis involving genetic data), the system automatically enables a secondary verification mechanism, requiring the requester to submit dynamic biometrics (such as real-time facial recognition video stream) through a designated secure channel within 15 minutes. Only after successful verification is the complete data released. The entire process forms a closed-loop audit: all operations are recorded as blockchain events, including token generation parameters, associated data access records, and analysis result summaries, supporting subsequent compliance traceability via smart contracts. The system also supports a dynamic permission degradation mechanism; when abnormal access patterns are detected (such as frequent access to different patient data within a short period), the token validity period is automatically shortened to 5 minutes, triggering a manual review process. This design ensures both refined authorization of medical data (the principle of least privilege) and enhances the reliability of clinical decisions through blockchain-based evidence storage and treatment data correlation analysis.

[0054] In some embodiments of this application, an access token containing fine-grained control parameters (duration, permissions, forwarding, and resolution) is generated after verifying identity and permissions through a dynamic strategy. When the permissions are met, a complete access result is generated by associating treatment data, which not only ensures the secure and controllable sharing of medical images, but also realizes the integrated and accurate transmission of diagnostic and treatment information.

[0055] Furthermore, based on the above embodiments, please refer to... Figure 6In one exemplary embodiment provided in this application, the specific implementation process of generating plaintext watermark data based on target channel image data from multiple channel image data may further include steps S610 and S620, which are described in detail below: Step S610: Determine the target channel image data from multiple channel image data based on the permission level. The permission level is positively correlated with the confidentiality of the channel corresponding to the target channel image data. Step S620: Generate plaintext watermark data based on the access identity identifier and the target channel image data.

[0056] For example, once the permission level is determined, the system first retrieves the channel confidentiality configuration table for multi-channel image data from the blockchain smart contract. This table is stored in a Merkle tree structure and contains the confidentiality level (e.g., "public," "clinical," "research") and its corresponding encryption parameters for each channel. The system converts the permission level (e.g., "resident physician," "attending physician," "department head") into a numerical permission score (e.g., 1-10 points) and matches it with the confidentiality level score of each channel. The matching algorithm uses a weighted threshold model: for N image channels, the difference ΔS between the confidentiality score S and the permission score P of each channel is calculated, and only channels with ΔS ≤ the threshold (usually set to 2) are selected as candidates. If multiple candidate channels exist, they are further prioritized according to clinical guidelines (e.g., "chest CT diagnosis must include mediastinal and lung windows") to finally determine the target channel image dataset. This process is automatically executed through the channel selection strategy of the smart contract, ensuring that the selection result can be verified by the blockchain. After identifying the target channel, the system enters the watermark generation phase: First, key attributes (such as user ID, device MAC address, and access timestamp) are extracted from the access identity identifier, and combined with a random challenge code generated by the blockchain (generated through a VRF-verifiable random function) to construct the watermark information payload. To enhance security, the watermark data adopts a three-layer nested structure: 1) The core layer contains the identity hash (SHA-3 algorithm) and the Merkle root hash of the channel selection strategy; 2) The time layer embeds the blockchain block height and token expiration time; 3) The verification layer uses BCH error correction codes to encode the data of the first two layers. The watermark generation algorithm uses adaptive frequency domain embedding technology: the target channel image is subjected to three-level wavelet decomposition, and the embedding strength is dynamically adjusted according to the local complexity of the image in the HH3 (high-frequency detail) subband (the strength is reduced by 30% in complex regions to avoid artifacts). The embedding process uses chaotic sequence encryption of the watermark bitstream, and the key is generated by derivation from the policy hash in the access token and the device fingerprint through HKDF. Specifically, for highly confidential channels (such as research-grade images), the system employs a dual watermarking mechanism: complementary watermarks are simultaneously embedded in both the spatial domain (DCT intermediate frequency coefficients) and the transform domain (wavelet HH3 subband), with cross-verification achieved through the Chinese Remainder Theorem (CRT). After watermark embedding, the system generates a watermark existence proof: calculating the hash of a specific region of the watermarked image (such as the PHash of the ROI), and comparing the proof data with the evidence record on the blockchain. The timestamps and operation parameters of the entire watermark generation process are recorded in the blockchain event log, and the binding relationship between the watermark and the identity identifier can be verified subsequently through the zero-knowledge proof interface of the smart contract without exposing the original image content. This design achieves a dynamic balance between channel confidentiality and watermark robustness: the higher the access level, the stronger the confidentiality of the accessible channel, while the larger the amount of embedded watermark information and the higher the verification strength, forming a tiered data protection mechanism.

[0057] Optionally, in some feasible embodiments, the security levels of the divided image data channels and their corresponding channels can be determined. For example, if there are n channels of image data, denoted as... Image data for each channel Corresponding to a permission level ,in, 'm' represents the preset maximum access level. Access level is positively correlated with channel confidentiality; that is, the higher the access level, the stronger the channel confidentiality. When verifying target channel image data, the access level can be determined based on the current user's access level. (in, The range of values ​​is still 1. Then, filter from multiple channels to find those that meet the requirements. All channel image data, and then select the permission level from these channel image data that meet the conditions. The largest channel image data is used as the target image data. Next, plaintext watermark data will be generated. Given the access identifier as ID, the access identifier ID will be matched with the target channel image data. Combine to generate plaintext watermark data A simple way to combine them is to convert the ID to binary form and then... Perform a bitwise XOR operation on the pixel values. Assume the binary sequence after ID conversion is... , ( (length of the binary sequence) The value of a certain pixel in p The generated plaintext watermark data W Pixel value at the corresponding position The calculation formula is: in, This indicates a bitwise XOR operation. The value is determined according to pre-defined rules, such as corresponding each bit in the binary sequence according to the position of the pixels in the image. In this way, the access identifier is integrated into the target channel image data to generate plaintext watermark data, realizing the addition of an identifier to the image data. At the same time, considering the permission level factor, it ensures that only users with the corresponding permissions can access and process the target channel image data.

[0058] In some embodiments of this application, target image data is matched by a positive correlation between permission level and channel confidentiality, and plaintext watermarks are generated by combining access identity. This achieves both hierarchical protection of sensitive medical data and ensures the non-repudiation of access traceability.

[0059] Furthermore, based on the above embodiments, please refer to... Figure 7 In one exemplary embodiment provided in this application, the specific implementation process of the above-mentioned blockchain-based medical image security management method may further include steps S710 and S720, which are described in detail below: Step S710: Obtain the address information corresponding to the access request. The address information includes the geographical location and IP address. Step S720: Determine the access identity identifier corresponding to the access request based on the IP address, and determine the access permission of the access token based on the geographical location.

[0060] For example, upon receiving an access request, the system first extracts the X-Forwarded-For and X-Real-IP fields from the HTTP request header and constructs an initial set of IP addresses by combining them with the source IP address from the TCP handshake phase. Then, it performs geolocation resolution on each IP address by calling the GeoIP database and a third-party location API, generating a location information set containing latitude and longitude coordinates, ASN (Autonomous Region Number), and city-level administrative region. To improve positioning accuracy, the system uses a weighted centroid algorithm to fuse multi-source location data, where the weights are determined by IP type, ASN reputation score, and location data source confidence. Based on the resolved IP address, the system determines the access identity identifier through the following steps: First, it queries the IP reputation contract stored on the blockchain to check if the IP belongs to a preset trust domain; if it matches, it directly associates it with a pre-registered identity. For IPs not on the whitelist, it extracts device features such as HTTP User-Agent and TLS fingerprint, combines them with the IP address to generate a temporary device fingerprint, and verifies the fingerprint's historical access behavior through blockchain-stored records; if it complies with the security policy, a temporary identity identifier is created. When determining access permissions, the system matches geographic location information with predefined geofencing policies. It calculates the spherical distance between the current location and the center of the authorized area, verifies access legitimacy by combining this with administrative division codes, and performs cross-validation based on the IP address's ASN and the timezone consistency of the geographic location. Finally, it generates a dynamic access token containing spatiotemporal constraints. The token's access scope is jointly determined by the geographic location risk level (e.g., automatic downgrading in high-risk areas) and the IP reputation score, and the permissions are immutably bound through a blockchain smart contract. This entire process achieves a reliable mapping from address information to identity identifiers and fine-grained control of access permissions based on geographic location.

[0061] In some embodiments of this application, by combining IP addresses to accurately associate access identities and dynamically adjusting access permissions using geographical location, fine-grained access control based on geofencing is achieved, effectively enhancing the security and compliance of medical data sharing.

[0062] Furthermore, based on the above embodiments, please refer to... Figure 8 In one exemplary embodiment provided in this application, the aforementioned preset blockchain is a consortium blockchain, and the specific implementation process of generating a dynamic access policy based on the preset blockchain may further include steps S810 to S830, which are detailed below: Step S810: Obtain the smart contract deployed on the consortium blockchain. The smart contract is used to manage the access control policy for medical images. Step S820: Obtain the patient authorization status corresponding to the initial medical image with data sensitivity; Step S830: Based on the patient's authorization status, data sensitivity, and the smart contract, generate a dynamic access strategy corresponding to the initial medical image.

[0063] For example, the system synchronizes the latest deployed smart contract from the consortium blockchain node. This contract is written in Solidity and jointly signed and verified by multiple authoritative institutions. The contract stores a medical image access control policy template library, including various policy models such as Role-Based Access Control (RBAC), Attribute-Based Access Control (ABAC), and Purpose-Based Access Control (PBAC). Simultaneously, the system retrieves the patient's authorization status corresponding to the initial medical image from the patient's Electronic Health Record (EHR) system. This status is verified through a digital authorization letter signed by the patient (using the W3C VC standard). The authorization letter includes the scope of authorization (e.g., diagnosis, research, teaching), validity period, and revocation record. The system parses the JSON-LD semantic description of the authorization letter and converts it into executable permission rules. For data sensitivity assessment, the system adopts the NIST-defined medical data sensitivity grading standard, combining DICOM tags in image metadata (e.g., patient age, disease type, examination site) and blockchain-stored institutional data classification tags. A weighted scoring model is used to calculate the sensitivity score, which considers data leakage risks, compliance requirements (e.g., HIPAA, GDPR), and industry best practices. When generating dynamic access policies, the system first deconstructs the patient's authorization status into atomic permission conditions (such as allowing access to specific departments, prohibiting commercial use, etc.). Then, it combines the data sensitivity score to trigger the policy template selection logic: for highly sensitive data (score ≥ 80), a multi-level approval policy is automatically activated, requiring access requests to be verified by three levels: the data owner, the medical institution administrator, and the regulatory agency; for moderately sensitive data (40 ≤ score < 80), attribute-based dynamic authorization is adopted, calculating permissions in real time based on the visitor's professional qualifications, access history, and current context (such as geographical location and access time); for low-sensitivity data (score < 40), a simplified RBAC policy is applied. During the policy generation process, the system obtains real-time regulatory policies (such as temporarily prohibiting the export of specific disease data in a certain region) through an oracle service and injects these external rules into the policy rule engine. The final generated dynamic access policy is encapsulated in JSON format, containing a policy ID, applicable image hash, permission condition set, and expiration timestamp. This policy is sent to the policy execution node through the privacy transaction channel of the consortium blockchain (using zero-knowledge proof technology), and the policy's hash value is recorded in the blockchain event log for audit traceability. The entire process achieves automated integration of patient authorization intent, data sensitivity characteristics, and regulatory requirements, ensuring that access policies not only comply with legal requirements but also adapt to the dynamic changes in the healthcare scenario.

[0064] In some embodiments of this application, access policies are generated by dynamically integrating patient authorization status and data sensitivity through consortium blockchain smart contracts. This achieves both automated compliance management of medical image access and ensures privacy protection and traceability of sensitive data throughout its entire lifecycle. Further, based on the above embodiments, please refer to... Figure 9 In one exemplary embodiment provided in this application, the specific implementation process of the above-mentioned blockchain-based medical image security management method may further include steps S910 and S920, which are described in detail below: Step S910: Obtain the voting information submitted by each node on the consortium blockchain, and determine the voting result based on the voting information; Step S920: Determine the smart contract of the consortium blockchain based on the voting results. The smart contract includes an access policy template, access policy monitoring, and a dynamic implementation strategy for the smart contract.

[0065] For example, in a consortium blockchain environment, the process of obtaining voting information submitted by each node and determining the voting results typically involves a multi-stage negotiation and consensus mechanism. First, each authorized node in the consortium blockchain submits voting information through a predefined smart contract interface. This information may include support, opposition, or abstention status for a specific proposal, as well as possible additional parameters (such as voting weight). Voting information is usually packaged as transactions and broadcast to the network. Other nodes, upon receiving these transactions, store them in a local temporary cache. Subsequently, the system triggers a consensus process (such as PBFT, Raft, or a custom consensus algorithm), where each node verifies the validity of the voting transactions, including checking signature legality, duplicate voting, and voting eligibility. After successful verification, nodes exchange voting summaries or complete voting data through multiple rounds of communication, ultimately reaching a consensus on the voting results. For example, in PBFT consensus, the master node collects votes and generates a pre-preparation message. Other nodes, after verification, enter the preparation and submission phase. Only when more than a threshold number of nodes confirm that the voting results are consistent is the result finally confirmed and written to the blockchain.

[0066] Based on the determined voting results, the system further selects or generates smart contracts for the consortium blockchain. This process may involve dynamic policy configuration: if the voting results support a proposal (such as updating the access policy template), the smart contract's code or parameters will be adjusted accordingly. Access policy templates typically define the permission rules for data access (such as control based on roles, attributes, or time conditions). These templates may be directly specified through the voting results or dynamically loaded from a pre-built template library. The access policy monitoring mechanism, as a continuously running component of the smart contract, checks in real time whether transactions conform to the current policy, for example, by parsing the identity credentials of the transaction initiator and matching them with the policy rules. If unauthorized access is detected, the contract can trigger an alert, reject the transaction, or initiate an arbitration process. Dynamic policy implementation refers to the smart contract's ability to automatically adjust its behavioral logic based on external events (such as voting results, time triggers, or off-chain data). For example, when the voting results require an upgrade to the contract's functionality, the system can load the new logic through a proxy contract or hot deployment mechanism, while ensuring a smooth transition between the old and new contract states. The entire process emphasizes decentralized collaboration and policy flexibility; the voting results are not only the output of static decisions but also the core input driving the dynamic evolution of smart contracts.

[0067] In some embodiments of this application, the smart contract and its dynamic access strategy are determined through consensus via a consortium blockchain node voting mechanism. This not only ensures the democratic governance and decentralized, trustworthy execution of medical data access control rules, but also enables real-time monitoring and adaptive optimization of the strategy.

[0068] Furthermore, based on the above embodiments, please refer to... Figure 10 In one exemplary embodiment provided in this application, the specific implementation process of the above-mentioned blockchain-based medical image security management method may further include steps S1010 to S1030, which are described in detail below: Step S1010: Determine the visitor role based on the access identity identifier, and determine the private key corresponding to the visitor role; Step S1020: Compare the private key with the verification value. If the private key and the verification value match, it is determined that the access request meets the dynamic access policy. Step S1030: Decrypt the encrypted image data and generate an access result based on the decrypted image data and plaintext watermark data.

[0069] For example, in implementing dynamic access control based on access identity, the system first needs to extract the visitor's identity information from the access request. This identity can be in the form of a digital certificate, token, or user credentials. The system verifies the identity through a predefined authentication mechanism. After confirming its legitimacy, it determines the visitor's role based on an identity-role mapping table (which stores the correspondence between identity identifiers and visitor roles). Examples include administrator, regular user, or visitor roles. After determining the role, the system obtains the private key associated with that role from the key management system. The key management system may use a role-based access control (RBAC) model or attribute-based encryption (ABE) technology to manage key distribution.

[0070] Next, the system matches the acquired private key with a pre-stored checksum. The checksum can be a hash value, a digital signature, or a specific encrypted fragment, and its generation method must be consistent with the private key generation logic. For example, if the private key is generated using an asymmetric encryption algorithm, the checksum might be a specific data fragment encrypted with the corresponding public key. The matching process involves performing the same encryption or hash operation on the private key and checksum and comparing the results. If they match perfectly, the private key is deemed valid, thus confirming that the access request complies with the security requirements set in the dynamic access policy. The dynamic access policy may include conditions such as time constraints, device fingerprint verification, or multi-factor authentication, and the system needs to consider all these conditions in its judgment.

[0071] Once the access request is verified, the system begins processing the encrypted image data. First, the encrypted image is decrypted using the verified private key. The decryption algorithm must match the algorithm used for encryption (such as AES, RSA, etc.). During decryption, the system must ensure the integrity and confidentiality of the private key to prevent key leakage and data security risks. After decryption, the system obtains the plaintext form of the original image data. Subsequently, the system embeds plaintext watermark data into the decrypted image. The watermark data may contain copyright information, user identifiers, or timestamps. The embedding process employs invisible watermarking techniques (such as DCT transform domain embedding) to ensure that the image's visual quality is not affected.

[0072] Finally, the system integrates the decrypted image data with the watermarked result to generate the final access result. This result may be returned to the visitor in the form of an image file, video stream, or data buffer. Simultaneously, the system records an access log, including access time, visitor role, and operation type, for subsequent auditing and tracking. The entire process must ensure the atomicity and security of each step. For example, in case of decryption or watermark embedding failure, the operation should be rolled back and an error message returned to avoid data inconsistencies caused by partial processing. Through this implementation, the system can securely and efficiently control access permissions for image data in dynamically changing access environments.

[0073] In some embodiments of this application, (beneficial effects) the compliance of dynamic policies is verified by matching the private key associated with the visitor role with the verification value, and the results are generated based on the decrypted data and plaintext watermark. This achieves both fine-grained security access control based on identity and ensures the integrity and traceability of medical image data transmission.

[0074] Furthermore, based on the above embodiments, please refer to... Figure 11 In one exemplary embodiment provided in this application, the specific implementation process of the above-mentioned blockchain-based medical image security management method further includes steps S1110 and S1120, which are described in detail below: Step S1110: Generate a zero-knowledge proof corresponding to the visitor role. The zero-knowledge proof is used to prove the legitimate identity of the visitor role. Step S1120: Determine the private key corresponding to the visitor role based on the legitimate identity.

[0075] For example, in generating a zero-knowledge proof corresponding to a visitor role to demonstrate their legitimate identity and determine the corresponding private key, a suitable zero-knowledge proof system must first be constructed. This system is typically based on specific cryptographic assumptions, such as the discrete logarithm problem or mathematical problems on elliptic curves. Assuming we adopt an elliptic curve-based zero-knowledge proof scheme, the entire implementation process can be described as follows: The system first predefines a set of public parameters, including the base points and order of the elliptic curve, which are public to all participants. When a visitor registers in the system, a unique identity identifier is generated. Using the key generation algorithm provided by the system, combined with their own identity information, a public-private key pair is generated. The private key is securely stored by the visitor, while the public key is associated with the identity identifier and stored in the system. When a visitor needs to prove their legitimate identity, the system generates a random challenge requiring the visitor to provide a zero-knowledge proof. A visitor uses their private key and challenge information, combined with zero-knowledge proof protocols such as zk-SNARKs or Stern-like protocols, to generate a proof that verifies the visitor indeed possesses the private key corresponding to a specific public key, without revealing any information about the private key during the proof process. Specifically, the visitor constructs a proof polynomial that satisfies a specific mathematical relation under the influence of the private key and challenge information, and then sends the proof to the verifier via interactive or non-interactive means. Upon receiving the proof, the verifier uses public parameters and the visitor's public key to verify whether the proof polynomial satisfies the expected mathematical relation. If the verification passes, the visitor is confirmed to possess a valid private key, thus proving their legitimate identity. Once the visitor's legitimate identity is confirmed, the system can determine the private key corresponding to the visitor's role based on pre-defined rules, such as access control lists or role-based permission mappings. It's important to note that "determining the private key" here does not mean directly exposing the private key to the system or verifier, but rather that the system internally records or references the association between the private key and the visitor's role for use in subsequent access control or encrypted communication. Throughout the process, the core value of zero-knowledge proof lies in its ability to allow visitors to prove that they possess a private key without revealing its specific contents, thus achieving a balance between security and privacy in identity verification.

[0076] In some embodiments of this application, zero-knowledge proofs are used to verify the legitimate identity of the visitor role and associate it with the private key, which not only achieves non-disclosure identity authentication for access to sensitive medical data, but also ensures the security and compliance of the distribution of encrypted keys.

[0077] Figure 12 This is a block diagram illustrating a blockchain-based medical image security management system, as shown in an exemplary embodiment of this application. The system can be applied to... Figure 2The implementation environment shown is specifically configured in terminal device 210. This system can also be applied to other exemplary implementation environments and specifically configured in other devices. This embodiment does not limit the implementation environment to which the device is applicable.

[0078] like Figure 12 As shown, this exemplary blockchain-based medical image security management system includes: an acquisition module 1210 for acquiring an initial medical image, dividing the initial medical image into channels to obtain multiple channel image data; an encryption module 1220 for encrypting the multiple channel image data respectively to obtain encrypted image data and a verification value, storing the encrypted image data in multiple different storage nodes, and transmitting the storage address and verification value to a preset blockchain; an access module 1230 for generating a dynamic access policy based on the preset blockchain, and generating a corresponding access token based on the dynamic access policy when an access request is received; and a watermark module 1240 for generating plaintext watermark data based on the target channel image data in the multiple channel image data, and generating an access result corresponding to the access request based on the plaintext watermark data and the access token.

[0079] According to one aspect of the embodiments of this application, the access module 1230 is further configured to: parse the access request, and determine the access identity identifier corresponding to the access request and the permission level corresponding to the access identity identifier based on the parsing result; and generate a corresponding access token based on the access identity identifier, the permission level and the dynamic access policy.

[0080] According to one aspect of the embodiments of this application, the access module 1230 is further configured to: if the access identity identifier meets the dynamic access policy, generate an access token based on the permission level, the access token including access duration, access permission, forwarding restriction and image clarity; if the access permission meets the preset access permission level, obtain the associated image set corresponding to the initial medical image; determine the treatment data corresponding to the associated image set, and generate the access result corresponding to the access request based on the associated image set and the treatment data.

[0081] According to one aspect of the embodiments of this application, the access module 1230 is further configured to: determine the target channel image data from multiple channel image data based on the permission level, wherein the permission level is positively correlated with the confidentiality of the channel corresponding to the target channel image data; and generate plaintext watermark data based on the access identity identifier and the target channel image data.

[0082] According to one aspect of the embodiments of this application, the access module 1230 is further configured to: obtain address information corresponding to the access request, the address information including geographical location and IP address; determine the access identity identifier corresponding to the access request based on the IP address, and determine the access permission of the access token based on the geographical location.

[0083] According to one aspect of the embodiments of this application, the access module 1230 is further configured to: obtain a smart contract deployed on the consortium blockchain, the smart contract being used to manage access control policies for medical images; obtain the patient authorization status and data sensitivity corresponding to the initial medical image; and generate a dynamic access policy corresponding to the initial medical image based on the patient authorization status, data sensitivity, and the smart contract.

[0084] According to one aspect of the embodiments of this application, the access module 1230 is further configured to: obtain voting information submitted by each node on the consortium blockchain, and determine the voting result based on the voting information; determine the smart contract of the consortium blockchain based on the voting result, wherein the smart contract includes an access policy template, access policy monitoring, and a dynamic implementation strategy for the smart contract.

[0085] According to one aspect of the embodiments of this application, the watermark module 1240 is further configured to: determine the visitor role based on the access identity identifier, and determine the private key corresponding to the visitor role; compare the private key with the verification value, and if the private key matches the verification value, determine that the access request satisfies the dynamic access policy; decrypt the encrypted image data, and generate an access result based on the decrypted image data and the plaintext watermark data.

[0086] According to one aspect of the embodiments of this application, the watermark module 1240 is further configured to generate a zero-knowledge proof corresponding to the visitor role, the zero-knowledge proof being used to prove the legitimate identity possessed by the visitor role; and determine the private key corresponding to the visitor role based on the legitimate identity.

[0087] It should be noted that the blockchain-based medical image security management system and the blockchain-based medical image security management method provided in the above embodiments belong to the same concept. The specific methods by which each module and unit performs its operations have been described in detail in the method embodiments and will not be repeated here. In practical applications, the blockchain-based medical image security management system provided in the above embodiments can allocate the above functions to different functional modules as needed, that is, divide the internal structure of the device into different functional modules to complete all or part of the functions described above, and this is not a limitation.

[0088] Embodiments of this application also provide an electronic device, including: one or more processors; and a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the electronic device enables the blockchain-based medical image security management method provided in the above embodiments.

[0089] Based on the above method and apparatus embodiments, this application also provides an electronic device. See also Figure 13This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 13 The electronic device shown may include at least a processor 1301, an input interface 1302, an output interface 1303, and a computer storage medium 1304. The processor 1301, input interface 1302, output interface 1303, and computer storage medium 1304 may be connected via a bus or other means.

[0090] Computer storage medium 1304 can be stored in the memory of an electronic device. Computer storage medium 1304 is used to store computer programs, which include program instructions. Processor 1301 is used to execute the program instructions stored in computer storage medium 1304. Processor 1301 (or CPU (Central Processing Unit)) is the computing and control core of the electronic device, suitable for implementing one or more instructions, specifically suitable for loading and executing one or more instructions to achieve the aforementioned blockchain performance evaluation method or corresponding functions.

[0091] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying a computer-readable computer program. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The computer program contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0092] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0093] The units described in the embodiments of this application can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.

[0094] Another aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the aforementioned blockchain-based medical image security management method. This computer-readable storage medium may be included in the electronic device described in the above embodiments, or it may exist independently and not incorporated into the electronic device.

[0095] Another aspect of this application provides a computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the blockchain-based medical image security management method provided in the various embodiments described above.

[0096] The above description is merely a preferred exemplary embodiment of this application and is not intended to limit the implementation of this application. Those skilled in the art can easily make corresponding modifications or alterations based on the main concept and spirit of this application. Therefore, the scope of protection of this application should be determined by the scope of protection claimed in the claims.

Claims

1. A blockchain-based method for medical image security management, characterized in that, include: Acquire an initial medical image, and divide the initial medical image into channels to obtain multiple channel image data; The image data from the multiple channels are encrypted to obtain encrypted image data and a verification value. The encrypted image data is then stored in multiple different storage nodes, and the storage address and the verification value are transmitted to a preset blockchain. A dynamic access policy is generated based on the preset blockchain, and an access token corresponding to the access request is generated based on the dynamic access policy when an access request is received. Plaintext watermark data is generated based on the target channel image data from the multiple channel image data, and the access result corresponding to the access request is generated based on the plaintext watermark data and the access token. The step of generating plaintext watermark data based on the target channel image data from the plurality of channel image data includes: The access request is parsed, and the identity attribute corresponding to the access request, the time constraint corresponding to the identity attribute, and the resource sensitivity corresponding to the access object of the access request are determined based on the parsing result. The access request's corresponding permission level is determined based on the identity attribute, the time constraint, and the resource sensitivity. The target channel image data is determined from the multiple channel image data based on the permission level, and the permission level is positively correlated with the confidentiality of the channel corresponding to the target channel image data; Obtain the access identity identifier corresponding to the access request, and generate plaintext watermark data based on the access identity identifier and the target channel image data.

2. The method as described in claim 1, characterized in that, The method includes: The access request is parsed, and the access identity identifier corresponding to the access request and the permission level corresponding to the access identity identifier are determined based on the parsing result; A corresponding access token is generated based on the access identity identifier, the permission level, and the dynamic access policy.

3. The method as described in claim 2, characterized in that, The method further includes: If the access identity identifier satisfies the dynamic access policy, then the access token is generated based on the permission level. The access token includes access duration, access permissions, forwarding restrictions, and image clarity. If the access permission meets the preset access permission level, then obtain the associated image set corresponding to the initial medical image; Determine the treatment data corresponding to the associated image set, and generate the access result corresponding to the access request based on the associated image set and the treatment data.

4. The method as described in claim 2, characterized in that, The method further includes: Obtain the address information corresponding to the access request, the address information including geographical location and IP address; The access identity identifier corresponding to the access request is determined based on the IP address, and the access permissions of the access token are determined based on the geographical location.

5. The method as described in claim 1, characterized in that, The preset blockchain is a consortium blockchain, and the generation of dynamic access policies based on the preset blockchain includes: Obtain the smart contract deployed on the consortium blockchain, which is used to manage access control policies for medical images; Obtain the patient authorization status corresponding to the initial medical image with data sensitivity; Based on the patient's authorization status, the data sensitivity, and the smart contract, a dynamic access strategy is generated corresponding to the initial medical image.

6. The method as described in claim 5, characterized in that, The method further includes: Obtain the voting information submitted by each node on the consortium blockchain, and determine the voting result based on the voting information; The smart contract of the consortium blockchain is determined based on the voting results. The smart contract includes an access policy template, access policy monitoring, and a dynamic implementation strategy for the smart contract.

7. The method as described in claim 1, characterized in that, The method further includes: The visitor role is determined based on the access identity identifier, and the private key corresponding to the visitor role is determined; The private key is compared with the verification value. If the private key matches the verification value, the access request is determined to satisfy the dynamic access policy. The encrypted image data is decrypted, and an access result is generated based on the decrypted image data and the plaintext watermark data.

8. The method as described in claim 7, characterized in that, The method further includes: Generate a zero-knowledge proof corresponding to the visitor role, the zero-knowledge proof being used to prove the legitimate identity possessed by the visitor role; The private key corresponding to the visitor role is determined based on the legitimate identity.

9. A blockchain-based medical image security management system, characterized in that, The system includes: The acquisition module is used to acquire an initial medical image, divide the initial medical image into channels, and obtain multiple channel image data; The encryption module is used to encrypt the image data of the multiple channels respectively to obtain encrypted image data and a verification value, and to store the encrypted image data in multiple different storage nodes, and to transmit the storage address and the verification value to a preset blockchain; The access module is used to generate a dynamic access policy based on the preset blockchain, and to generate a corresponding access token based on the dynamic access policy when an access request is received. The watermarking module is used to generate plaintext watermark data based on target channel image data from the multiple channel image data, and to generate an access result corresponding to the access request based on the plaintext watermark data and the access token. Generating plaintext watermark data based on the target channel image data from the multiple channel image data includes: parsing the access request and determining the identity attribute corresponding to the access request, the time constraint corresponding to the identity attribute, and the resource sensitivity corresponding to the access object of the access request based on the parsing result; determining the permission level corresponding to the access request based on the identity attribute, the time constraint, and the resource sensitivity; determining the target channel image data from the multiple channel image data based on the permission level, wherein the permission level is positively correlated with the channel confidentiality corresponding to the target channel image data; obtaining the access identity identifier corresponding to the access request, and generating plaintext watermark data based on the access identity identifier and the target channel image data.

Images