Public health data sharing method and storage medium

Abstract

The invention relates to a public health data sharing method and a storage medium, and the method comprises the steps: generating a corresponding on-chain digital identity for each participant based on a distributed account book of a block chain; the block chain stores encrypted data bound with a digital identity on the chain, the encrypted data is obtained by encrypting public health data based on an access strategy, and the access strategy is generated based on a preset user attribute condition; detecting a user access request; in response to the detected user access request, analyzing an access user attribute; and sending a decryption key of the encrypted data to the access user based on the on-chain digital identity indicated by the user access request under the condition that the access user attribute is detected to accord with the access strategy. According to the invention, the problem that the public health data sharing process is tedious and low in efficiency is solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of blockchains, and in particular to a method for sharing public health data and a storage medium. BACKGROUND

[0002] In the context of accelerating globalization, the speed and scope of disease transmission have increased significantly. Timely, accurate and secure data sharing plays a crucial role in disease prevention and control, public health decision-making and scientific research cooperation.

[0003] However, in the related art, the software systems of the participants in a medical association are relatively independent, and data sharing between different medical institutions within the same medical association or between different medical associations is difficult. Most of them have not achieved interconnection and intercommunication. The problem of repeated construction of systems may inevitably occur when a medical association cloud platform is built, and the problem of difficulty in data connection between different medical association cloud platforms still exists, resulting in a cumbersome and inefficient public health data sharing process.

[0004] At present, there is no effective solution to the problem of a cumbersome and inefficient public health data sharing process in the related art. SUMMARY

[0005] The embodiments of the present application provide a method for sharing public health data and a storage medium to at least solve the problem of a cumbersome and inefficient public health data sharing process in the related art.

[0006] In a first aspect, the embodiments of the present application provide a method for sharing public health data, which comprises:

[0007] A distributed ledger based on a blockchain generates a corresponding on-chain digital identity for each participating subject. The blockchain stores encrypted data bound to the on-chain digital identity, which is encrypted based on an access policy for public health data, and the access policy is generated based on a pre-set user attribute condition;

[0008] Detecting a user access request;

[0009] In response to the detected user access request, parsing the access user attribute; in the case where the access user attribute is detected to comply with the access policy, sending a decryption key of the encrypted data to an access user based on the on-chain digital identity indicated by the user access request.

[0010] In some embodiments, the distributed ledger based on the blockchain generates a corresponding on-chain digital identity for each participating subject, comprising:

[0011] Embed a subject name of the participating subject into a preset identifier prefix to obtain identification information of the participating subject;

[0012] Generate a public-private key pair, encapsulate a subject public key in the public-private key pair with the identification information to obtain encapsulation data, encrypt the encapsulation data, and store the encrypted data on the distributed ledger as the on-chain digital identity.

[0013] In some embodiments, the method further comprises:

[0014] Collecting Internet of Things device sensing data through an edge computing node and uploading the Internet of Things device sensing data to the blockchain;

[0015] On the blockchain, analyzing the Internet of Things device sensing data to generate real-time spatio-temporal data, and generating fine-grained attributes of the participating subject based on the real-time spatio-temporal data and acquired public health dynamic parameters;

[0016] Signing the fine-grained attributes based on a subject private key in a public-private key pair of the on-chain digital identity to obtain verifiable credentials;

[0017] In the case of detecting the user access request, obtaining the subject public key from the blockchain and verifying the verifiable credentials based on the subject public key; in the case of verification passing, analyzing the access user attributes.

[0018] In some embodiments, the method further comprises:

[0019] Dividing the encrypted data to determine structured data and unstructured data;

[0020] Storing the unstructured data in an off-chain distributed file system and uploading a file hash value of the unstructured data and the structured data to the blockchain for storage;

[0021] The blockchain is divided into multiple independent storage shards, including an index storage shard carrying an index value and an unstructured storage shard allocated for the unstructured data; the blockchain stores the structured data to the index storage shard and stores the file hash value of the unstructured data to the unstructured storage shard.

[0022] In some embodiments, the method further comprises:

[0023] According to the preset public health service type, each blockchain node on the blockchain is assigned to multiple namespaces, and a unique identifier is generated for each namespace;

[0024] For each of the aforementioned namespaces, a consensus mechanism is customized according to the corresponding public health service type; wherein, the blockchain nodes within the namespace share the encrypted data based on the unique identifier and using the corresponding consensus mechanism;

[0025] The blockchain node verifies the header message in the received blockchain network message based on the unique identifier. If the header message is verified, the blockchain node processes the blockchain network message.

[0026] In some embodiments, the namespace includes a temporary namespace, and generating a unique identifier for each of the namespaces includes:

[0027] The blockchain nodes monitor new events added on the chain.

[0028] Upon detecting a new event on the chain, a temporary namespace is set on the blockchain, and a corresponding unique identifier is dynamically generated for the temporary namespace.

[0029] In some embodiments, setting the temporary namespace on the blockchain upon detecting a new event on the chain includes:

[0030] If there are multiple newly added events detected on the blockchain, a dynamic weight value is obtained for each newly added event on the blockchain, and an event detection index for the newly added event on the blockchain is calculated based on the dynamic weight value; wherein, the dynamic weight value is generated by a smart contract deployed on the blockchain.

[0031] When the event detection metric reaches a preset threshold, the temporary namespace is set on the blockchain.

[0032] In some embodiments, after assigning each blockchain node on the blockchain to multiple namespaces and generating a unique identifier for each namespace, the method further includes:

[0033] On the blockchain, the frequency of periodic operations and storage capacity usage of each namespace are statistically analyzed.

[0034] If the frequency of the periodic operation is detected to be lower than a preset threshold, and / or the storage capacity occupancy reaches a preset threshold, then the encrypted data in the corresponding namespace will be migrated to a long-term storage node in the blockchain, and the namespace will be deleted via the blockchain node.

[0035] In some embodiments, the method further includes:

[0036] Within the namespace, via the blockchain node, privacy verification calculations are performed on the encrypted data based on the received zero-knowledge proofs. If the privacy verification calculations pass, the encrypted data is stored on the blockchain.

[0037] In some embodiments, the public health data includes metadata associated with the on-chain digital identity.

[0038] Secondly, embodiments of this application provide a public health data sharing device, comprising:

[0039] The storage module is used for a blockchain-based distributed ledger to generate corresponding on-chain digital identities for each participating entity; the blockchain stores encrypted data bound to the on-chain digital identities, and the encrypted data is obtained by encrypting public health data based on an access policy, which is generated based on preset user attribute conditions.

[0040] The request detection module is used to detect user access requests;

[0041] The access module is used to respond to the detected user access request, parse the access user attributes, and if the access user attributes are found to match the access policy, send the decryption key of the encrypted data to the access user based on the on-chain digital identity indicated by the user access request.

[0042] Thirdly, embodiments of this application provide a storage medium storing a computer program that, when executed by a processor, implements the public health data sharing method described in the first aspect above.

[0043] Compared to related technologies, the present application provides a method and storage medium for sharing public health data. This method uses a blockchain-based distributed ledger to generate corresponding on-chain digital identities for each participating entity. The blockchain stores encrypted data bound to these on-chain digital identities. This encrypted data is obtained by encrypting public health data based on an access policy, which is generated based on preset user attribute conditions. The method detects user access requests; responds to the detected user access requests by parsing the access user attributes; and if the access user attributes match the access policy, the method sends the decryption key of the encrypted data to the access user based on the on-chain digital identity indicated in the user access request.

[0044] Based on this, decentralized technology is used to achieve secure data sharing and fine-grained access control. Attribute-based encryption algorithms are employed to encrypt public health data into a form that can only be decrypted by users who meet specific access policy conditions (such as "public health management personnel + regional permissions"), ensuring data privacy during storage and transmission. This access policy, along with the data hash value, is written into the blockchain, allowing any node to verify data ownership and access rules through on-chain DID, eliminating the friction costs of cross-institutional identity verification. This approach can meet emergency needs while avoiding rigid access permissions, ultimately improving sharing efficiency while reducing the risk of leakage, effectively solving the problem of cumbersome and inefficient public health data sharing processes.

[0045] Details of one or more embodiments of this application are set forth in the following drawings and description to make other features, objects and advantages of this application more readily apparent. Attached Figure Description

[0046] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0047] Figure 1 This is a hardware structure block diagram of a terminal for a public health data sharing method according to an embodiment of this application;

[0048] Figure 2 This is a flowchart of a method for sharing public health data according to an embodiment of this application;

[0049] Figure 3 This is a schematic diagram of the architecture of a trusted public health data sharing system according to an embodiment of this application;

[0050] Figure 4 This is a structural block diagram of a public health data sharing device according to an embodiment of this application. Detailed Implementation

[0051] To make the objectives, technical solutions, and advantages of this application clearer, the application is described and illustrated below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the application. All other embodiments obtained by those skilled in the art based on the embodiments provided in this application without inventive effort are within the scope of protection of this application. Furthermore, it is understood that although the efforts made in such a development process may be complex and lengthy, for those skilled in the art related to the content disclosed in this application, modifications to design, manufacturing, or production based on the technical content disclosed in this application are merely conventional technical means and should not be construed as insufficient disclosure of the content of this application.

[0052] In this application, the reference to "embodiment" means that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment that is mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described in this application may be combined with other embodiments without conflict.

[0053] Unless otherwise defined, the technical or scientific terms used in this application shall have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. The terms “a,” “an,” “an,” “the,” and similar words used in this application do not indicate quantity limitation and may indicate singular or plural. The terms “comprising,” “including,” “having,” and any variations thereof used in this application are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that includes a series of steps or modules (units) is not limited to the listed steps or units, but may also include steps or units not listed, or may include other steps or units inherent to these processes, methods, products, or devices. The terms “connected,” “linked,” “coupled,” and similar words used in this application are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. “Multiple” used in this application means two or more. “And / or” describes the relationship between related objects, indicating that three relationships may exist; for example, “A and / or B” can represent: A alone, A and B simultaneously, and B alone. The terms “first,” “second,” “third,” etc., used in this application are merely to distinguish similar objects and do not represent a specific ordering of the objects.

[0054] The method embodiments provided in this example can be executed on a terminal, computer, or similar computing device. Taking running on a terminal as an example,Figure 1 This is a hardware structure block diagram of a terminal for a public health data sharing method according to an embodiment of this application. For example... Figure 1 As shown, terminal 10 may include one or more ( Figure 1 Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. Optionally, the terminal may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the terminal described above. For example, terminal 10 may also include components that are larger than those described above. Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0055] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the public health data sharing method in this embodiment of the invention. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, thereby implementing the above-described method. The memory 104 may include high-speed random access memory and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0056] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0057] This embodiment provides a method for sharing public health data. Figure 2 This is a flowchart of a method for sharing public health data according to an embodiment of this application, such as... Figure 2 As shown, the process includes the following steps:

[0058] Step S210: Based on the distributed ledger of the blockchain, generate corresponding on-chain digital identities for each participating entity; the blockchain stores encrypted data bound to the on-chain digital identities, and the encrypted data is obtained by encrypting public health data based on access policies, which are generated based on preset user attribute conditions.

[0059] In this step, leveraging the decentralized nature of blockchain, a unique and trustworthy on-chain digital identity is constructed for each participant in public health data (including but not limited to medical institutions, research institutions, equipment, and individual users). Access policies are then used to dynamically encrypt and control access to the data. Specifically, the blockchain distributed ledger generates a unique decentralized identifier (DID) for each participant through a smart contract protocol; this is the aforementioned on-chain digital identity. The DID contains metadata such as user identity fingerprint, business attribute tags (e.g., "Public Health Management Center - Beijing"), and permission levels, and is bound to the encrypted data. For example, in an infectious disease surveillance scenario, a hospital's dataset might be labeled "Sensitive - Infectious Disease," and its encrypted hash value and access policy (e.g., "Requires approval from the Public Health Management Center + institution qualification verification") would be written into the blockchain smart contract.

[0060] On the other hand, the generation of encrypted data relies on a preset access policy, which dynamically adjusts based on user attribute conditions (such as role, geographical location, and time range). For example, using an attribute-based encryption algorithm (CP-ABE), data is encrypted into a form that can only be decrypted by users who meet specific attribute combinations. In practice, blockchain nodes generate decryption key fragments based on user attributes (such as "doctor + infectious disease prevention and control position") and ensure key security through a threshold mechanism. This design not only ensures data privacy but also guarantees the credibility of identity and data binding through the immutability of the blockchain, solving the risks of identity forgery or data tampering in traditional centralized systems. Furthermore, the dynamic update mechanism allows access policies to change according to business needs (such as temporarily granting data permissions) and automatically triggers policy changes through smart contracts, avoiding the inefficiency and security risks of manual intervention.

[0061] More specifically, in this embodiment, a set of specific attributes is defined for each user, such as their institution, role, and projects, and these attributes are stored in the blockchain. When a user's attributes change, the update method in the smart contract is called to synchronize these attribute changes in real time. Furthermore, based on actual needs, different attribute conditions are combined using logical operators to form complex logical expressions as complex access strategy conditions. For example, the access strategy is expressed as:

[0062] (policy (and (or ("Institution" = "A") ("Institution" = "B")) (or ("Role" = "Researcher") ("Role" = "SeniorResearcher")) ("Project" = "ProjectVirus")));

[0063] Only users meeting the conditions specified in the above access policy can decrypt the encrypted data. The specific implementation steps for data encryption are as follows: First, select appropriate parameters, such as elliptic curves and hash functions, based on the system's security requirements. Then, generate a master key; the Trust Authority (TA) is responsible for generating the master key and public parameters, and making the public parameters public. Finally, encrypt the data using the CP-ABE algorithm combined with the access policy. This step generates ciphertext containing the policy, ensuring that only users meeting specific attribute combinations can successfully decrypt the data. The encrypted data and its metadata are processed by a smart contract and recorded on the blockchain.

[0064] In an optional embodiment, the aforementioned public health data includes metadata associated with on-chain digital identities. A standardized digital metadata format is defined, containing key fields such as data fingerprint, name, description, type, tag, subject, acquisition method, and usage method.

[0065] For example, the metadata of a dataset about infectious disease research might include: "Name: Infectious Disease Research Report", "Type: Research Report", and "Tag: Sensitive". This metadata is recorded on the blockchain in the form of smart contracts, and the metadata of each dataset is associated with a unique decentralized identifier (DID) to ensure the uniqueness and traceability of the data.

[0066] Step S220: Detect user access requests.

[0067] Step S230: In response to the detected user access request, parse the access user attributes; if the access user attributes are found to conform to the access policy, send the decryption key of the encrypted data to the access user based on the on-chain digital identity indicated by the user access request.

[0068] In steps S220 to S230 above, user access requests are captured by listening to smart contract events or off-chain API interfaces, and the identity identifier (such as DID) and operation type (such as "read infectious disease data") in the request are extracted. Subsequently, the parsing module calls the identity authentication contract in the blockchain node to verify whether the user attributes meet the preset access policy. For example, when a user requests access to "Beijing 2025 H1N1 case data", the system needs to confirm whether the user's attributes include conditions such as "public health management center staff + Beijing-Tianjin-Hebei region permissions + data usage authorization" to check whether the user's attributes meet the requirements of the access policy; this process can also be combined with zero-knowledge proof (ZKP) technology, so that users can complete the verification without exposing complete identity information, thus balancing privacy and efficiency.

[0069] If a user's attributes meet the access policy, the system will trigger a decryption key distribution process. Based on the user's attribute set, the system will obtain the corresponding private key from the trust center. The on-chain verification will then check whether the requested data access permissions match the user's private key. If the attributes match, the private key will be used to decrypt the data.

[0070] Specifically, in scenarios where Attribute-Based Encryption (ABE) collaborates with blockchain, the user data access process strictly follows a logical closed loop of attribute verification, key distribution, on-chain permission matching, and data decryption. When a user initiates a data access request, the system first parses their attribute set (such as role, organization, permission level, etc.) and compares it with the access policy embedded during data encryption. For example, in a public health scenario, infectious disease data might be configured with an access policy of "public health management center staff + Beijing-Tianjin-Hebei region permissions + data usage authorization." If the user's attribute set satisfies this logical combination (e.g., verifying identity through zero-knowledge proof without exposing complete attributes), the decryption key distribution process is triggered. At this point, a trust center (such as an attribute authorization agency) generates a corresponding private key based on the user's attributes. This private key is distributed across blockchain nodes using a threshold mechanism or multi-party computation (MPC) to avoid single-point-of-failure risks. Subsequently, the system verifies whether the user's requested data access permissions match their private key through a smart contract: the on-chain access policy is dynamically verified against the attribute tags in the private key, such as checking whether the user holds metadata such as "sensitive data access permission" or "time validity." If the attributes match, the private key will be used to decrypt the data. The specific process relies on the CP-ABE (Ciphertext Policy Attribute Base Encryption) Decrypt algorithm—the user's attribute set must satisfy the ciphertext access tree structure (such as AND / OR threshold logic) to reconstruct valid decryption parameters, ultimately completing data decryption. This process achieves fine-grained access control and ensures the traceability of operation logs through the immutability of the blockchain, solving the hidden dangers of permission abuse and data leakage in traditional centralized systems.

[0071] In related technologies, public health data sharing relies on centralized institutions for identity authentication, permission approval, and data decryption authorization. This results in cross-institutional collaboration involving lengthy paper-based approval processes (such as public health management centers needing to apply for hospital data at each level), manual review processes (such as verifying visitor qualifications), and multiple key transmissions (such as transmitting data access permissions through physical media). This can easily lead to data silos due to process breaks or permission conflicts.

[0072] In comparison, the embodiments of this application, through the aforementioned public health data sharing method, achieve secure data sharing and fine-grained access control via decentralized technology; employing an attribute-based encryption algorithm, public health data is encrypted into a form decryptable only by users meeting specific access policy conditions (such as "public health management center staff + regional permissions"), ensuring data privacy during storage and transmission; this access policy, along with the data hash value, is written into the blockchain, enabling any node to verify data ownership and access rules through on-chain DID, eliminating the frictional costs of cross-institutional identity verification, thereby meeting both emergency needs and avoiding rigid access permissions, ultimately improving sharing efficiency while reducing the risk of leakage, effectively solving the problem of cumbersome and inefficient public health data sharing processes.

[0073] In some embodiments, the aforementioned blockchain-based distributed ledger, which generates corresponding on-chain digital identities for each participating subject, may further include the following steps:

[0074] The entity name of the participating entity is embedded with a preset identifier prefix to obtain the identification information of the participating entity; a public-private key pair is generated, and the entity's public key and identification information in the public-private key pair are encapsulated to obtain encapsulated data; the encapsulated data is encrypted and stored on the chain as an on-chain digital identity based on the distributed ledger.

[0075] In the process of generating on-chain digital identities for participating entities within a blockchain-based distributed ledger, a new step utilizes structured identifier design, asymmetric encryption technology, and data encapsulation mechanisms to construct a trustworthy, unique, and traceable identity authentication system. Specifically, the process first standardizes identity definition by embedding identifier prefixes into the entity's name: the system pre-defines a set of business-related identifier prefixes (e.g., "did:healthcare" for the public health sector) and appends the entity's name (e.g., "Beijing Center for Disease Control and Prevention") as a suffix to the prefix, generating semantically readable and unique identification information. For example, did:example:123456789abcdefghi. In this identifier, the "example" part can be customized to easily identifiable information, such as an organization name or user nickname, while "123456789abcdefghi" is a unique identifier for a specific entity generated through a complex encryption algorithm. This design not only ensures global uniqueness within the namespace (avoiding conflicts between different organization names) but also enables rapid identification of business attributes through prefix classification; for example, the prefix "Public Health Management Center" can be directly associated with public health data governance rules.

[0076] Subsequently, the system binds an asymmetric encryption public-private key pair to the identification information. Using asymmetric encryption algorithms (such as RSA or ECC), it generates a public and private key pair for each participating entity, and integrates the public key with the identification information's related metadata, packaging it into a DID document. After digesting the packaged DID document using a hash function (such as SHA-256), the digest value is permanently recorded on the blockchain. Simultaneously, a smart contract is written to implement full lifecycle management of the DID record (including creation, updating, and cancellation). Thus, when medical institutions merge, the contract can automatically update the metadata associated with their DIDs without requiring manual synchronization of data across multiple institutions.

[0077] By embedding the entity names of participating entities, such as organization names or user nicknames, into identifier prefixes through the above embodiments, the readability of identities can be effectively improved compared to semantically meaningless random IDs. Furthermore, this approach not only meets the needs of multi-level and multi-attribute identity management in public health scenarios, but also constructs a decentralized trust infrastructure through the consensus mechanism and encryption technology of blockchain, effectively preventing security risks such as identity theft and data leakage.

[0078] In some embodiments, the above-mentioned response to a detected user access request, parsing the access user attributes, may further include the following steps:

[0079] IoT device sensor data is collected via edge computing nodes and uploaded to the blockchain. On the blockchain, this data is parsed to generate real-time spatiotemporal data. Based on this data and acquired public health dynamic parameters, fine-grained attributes of participating entities are generated. The fine-grained attributes are signed using the entity's private key from the public-private key pair of the on-chain digital identity, resulting in a verifiable credential. Upon detecting a user access request, the entity's public key is retrieved from the blockchain, and the verifiable credential is verified using this key. If verification is successful, the accessing user's attributes are parsed.

[0080] In this step, verifiable credentials (VCs) are used to address the need for attribute information management in collaborative research. For example, in medical research collaborations, to prove a researcher's professional qualifications or past research experience, relevant information can be encapsulated in a verifiable credential. When issuing a credential about a doctor's research experience, the credential details the specific projects they participated in and their roles, and the issuer signs the credential using their private key. When the recipient needs to verify this information, they confirm it by checking the validity of the credential, verifying the signature, and assessing the credential's relevance.

[0081] The aforementioned fine-grained attributes refer to hierarchical descriptions of the identity, permissions, or behavioral characteristics of participating entities (such as users, devices, and organizations), with each attribute description having N levels, where N is a positive integer greater than 1. These fine-grained attributes can be obtained from off-chain multi-source trusted data sources. Furthermore, these attributes typically contain multi-dimensional contextual information and can be adjusted in real-time based on the acquired dynamic business scenario information. This dynamic business scenario information refers to real-time, variable, and context-sensitive data related to business operations, environmental states, or the behavior of participating entities, used to dynamically adjust permissions, resource allocation, or process logic. Its core characteristic is automatic updating with changes in business needs or the environment, rather than static presets.

[0082] Specifically, edge computing nodes deployed near the devices first complete the real-time acquisition and local preprocessing of IoT sensor data, and then upload the processed valid data to the blockchain network. After receiving the data, the blockchain nodes parse the original sensor information (such as device location, timestamp, sensor readings, etc.) through built-in smart contracts, dynamically generate real-time data streams with spatiotemporal tags, and simultaneously acquire externally input public health dynamic parameters. Finally, the smart contracts integrate real-time spatiotemporal data with public health parameters, and use preset algorithm models to perform multi-dimensional analysis on participating entities (such as personnel, equipment, or regions), outputting fine-grained attribute labels with accurate spatiotemporal dimensions and environmental adaptability (such as individual health risk index, regional safety score, or device trust level). More specifically, edge computing nodes collect real-time spatiotemporal data from IoT devices (such as environmental sensors and positioning tools) and transmit it to blockchain nodes using lightweight encryption protocols (such as AES-GCM). The blockchain nodes then generate attributes by combining geographical location, timestamps, and dynamic parameters. This allows for the creation of more detailed composite attribute tags by integrating real-time geographical location with public health dynamic parameters such as data generation timestamps and data sensitivity levels (e.g., Class A / Class B infectious disease data as defined in the Law on Prevention and Control of Infectious Diseases). For example, in high-risk infectious disease scenarios, dynamic composite attributes containing tags such as "high-frequency contact area - short-term validity - close contact data access" are automatically generated for authorized personnel participating in trajectory data analysis.

[0083] Meanwhile, a multi-attribute authority (MA-ABE) architecture is adopted, with attribute authorization maintained in a distributed manner by public health management agencies, hospitals, communities, and other parties to avoid single points of failure. For example, community health centers can dynamically update the health risk association labels of specific individuals (such as lifting high-risk contact status), while simultaneously updating the permissions across the entire network through a blockchain consensus mechanism. Each attribute update generates a unique transaction hash, and historical version traceability is achieved through the Merkle proof chain. Combined with smart contract automatic triggering rules, such as automatically invoking the attribute revocation contract and updating the access permissions when an individual's health indicator continuously falls below a preset threshold, the system can be integrated.

[0084] Thus, the structured encapsulation of credentials includes fine-grained attributes such as specific project participation roles and professional qualifications (e.g., "participating in a vaccine research and development project, with the role of a clinical researcher"), which differs from the broad role labels such as "doctor" and "researcher" in related technologies.

[0085] For the signature verification mechanism, the issuer (such as a hospital) signs the verifiable credential using the principal's private key, and the recipient (such as a research institution) can query the issuer's public key through the blockchain and verify the signature to ensure the authenticity of the credential.

[0086] It should also be noted that when a user's attributes change (such as a doctor being promoted to chief physician), the hospital can call the VC update interface through a smart contract to update the content of the verifiable credentials. The new credentials automatically overwrite the old ones. Specifically, the new credentials contain the "chief physician" attribute and are signed and uploaded to the blockchain, while the old credentials automatically become invalid, thus achieving real-time synchronization of permissions. This eliminates the need for manual application to update permissions, solving the problem of low permission synchronization caused by update cycles lasting several days.

[0087] Through the above embodiments, considering the sensitive nature of public health data and the frequent collaboration among multiple institutions, labels such as institution type and business domain are added to the DID format (e.g., did:publichealth:Infectious Diseases-Beijing Municipal Public Health Emergency Management Center). Combined with dynamically generated fine-grained attributes, medical professional attributes are encapsulated through verifiable credentials, thereby realizing the innovative application of general DID technology in vertical fields. Furthermore, the dynamic attributes of participating entities, such as business roles, geographical scope, and time permissions, are encoded into verifiable credentials, which can effectively avoid the rigidity of permissions in traditional static identity authentication (such as username / password).

[0088] In some embodiments, the process of storing the encrypted data may further include the following steps:

[0089] The encrypted data is divided into structured and unstructured data. Unstructured data is stored in an off-chain distributed file system, and the file hash values ​​of the unstructured data and the structured data are uploaded to the blockchain for storage. The blockchain is divided into multiple independent storage shards, including index storage shards carrying index values ​​and unstructured storage shards allocated for unstructured data. The blockchain stores structured data in the index storage shard and stores the file hash values ​​of the unstructured data in the unstructured storage shard.

[0090] Specifically, the encrypted public health data is first divided into structured data (such as case statistics tables, vaccination rates, and other formatted data with fixed fields) and unstructured data (such as CT images, epidemiological research reports, and other files without regular formats).

[0091] For structured data, this embodiment employs a graph database or relational database (such as MySQL). These databases can effectively manage and query complex relational networks and support rapid retrieval and analysis. Leveraging the characteristics of blockchain technology, key metadata (such as patient IDs and diagnosis results) is encrypted and stored on the blockchain, associated with a decentralized identifier (DID). Simultaneously, structured data is sharded and indexed (e.g., a composite index of patient ID + diagnosis time) to support medical trend analysis. For unstructured data (such as large files like CT images and X-rays), traditional on-chain storage methods are unsuitable due to their capacity limitations. This embodiment chooses IPFS as an off-chain storage solution. In this mode, only the file's hash value is recorded on the blockchain, which not only ensures data uniqueness and verifiability but also improves storage efficiency.

[0092] Off-chain storage primarily relies on distributed file systems such as the InterPlanetary File System (IPFS). All unstructured data is first uploaded to the IPFS network, where it obtains a unique hash value, which is then recorded on the blockchain. Users can easily access these files through smart contract interfaces. In this model, only the file's hash value is recorded on the blockchain, ensuring not only data uniqueness and verifiability but also improved storage efficiency. By calling the smart contract interface, users can conveniently and quickly access files stored in IPFS. Each request is verified by the smart contract, ensuring that only authorized users can access the corresponding data, further enhancing data security and privacy protection.

[0093] The specific implementation steps for off-chain storage management are as follows: First, upload the file to the IPFS network. After successful upload, IPFS returns a unique hash value. Define a smart contract to store the hash value; for example, define a `storeFileHash` method to store the hash value, taking the hash as the method parameter. The specific contract is shown below:

[0094] event FileStored(string indexed fileHash, uint256 timestamp);

[0095] function storeFileHash(string memory _fileHash) public {

[0096] require(bytes(fileInfos[_fileHash].hash).length == 0, "Hash alreadyexists");

[0097] fileInfos[_fileHash] = FileInfo({

[0098] hash: _fileHash,

[0099] timestamp: block.timestamp

[0100] });

[0101] emit FileStored(_fileHash, block.timestamp);

[0102] }

[0103] Ultimately, the contract is stored on the blockchain by calling the smart contract API interface.

[0104] During data storage, the entire blockchain network is divided into multiple independent storage shards, each responsible for efficient read and write operations on a specific type of data. Specifically, blockchain shards are configured according to the characteristics of different data types (structured / unstructured). Structured data, due to its frequent read and write operations and complex query requirements, is allocated to indexed storage shards with high-performance index support; unstructured data, due to its larger size and lower access frequency, is allocated to unstructured storage shards specifically designed for large file storage.

[0105] On the other hand, to handle large files exceeding a certain size (e.g., 1MB) (such as CT images and X-rays), this invention employs an efficient block-based upload strategy. The specific implementation steps are as follows: First, file segmentation is performed. When processing large files such as CT images or X-rays, the front end divides the file into multiple fixed-size blocks (e.g., 1MB). For example, if the file size is 180MB, it will be divided into 180 slices, each 1MB in size, and these slices will be numbered. Next, hash calculation and recording are performed: each slice independently calculates its Merkle root hash value. Subsequently, these hash values ​​are recorded on the blockchain, forming a complete file fingerprint. This not only ensures the uniqueness and verifiability of the data but also improves storage efficiency. For example, if a public health management center needs to quickly verify whether a large number of close contact CT images have been tampered with, block hashing can verify only the slices of suspected cases without downloading the entire file, improving verification efficiency. When verifying the integrity of a file, this can be done by comparing the hash value on the blockchain with the hash value of the actual file. Specifically, only the root hash values ​​of the two are compared first; if an anomaly is found, the slice hashes are then compared further. If the above comparison results indicate that the two match, it proves that the document has not been tampered with, ensuring the security and integrity of the data.

[0106] The above embodiments organically combine four technologies—graph database, IPFS, blockchain sharding, and block hashing—to form a storage system for public health data, rather than simply layering them. Addressing the sensitivity and compliance requirements of medical data, dual encryption (combining DID association and attribute encryption) is employed when storing key metadata on-chain, while IPFS content addressing ensures data immutability during off-chain storage. This achieves an innovative application of general-purpose storage technology in the medical field.

[0107] In some embodiments, the above-described method for sharing public health data further includes the following steps:

[0108] According to the preset public health service types, each blockchain node on the blockchain is assigned to multiple namespaces, and a unique identifier is generated for each namespace. For each namespace, a consensus mechanism is customized according to the corresponding public health service type. Among them, the blockchain nodes within the namespace share encrypted data based on the unique identifier and the corresponding consensus mechanism. The blockchain nodes verify the header messages in the received blockchain network messages based on the unique identifier. If the header message verification is successful, the blockchain nodes process the blockchain network messages.

[0109] This step provides a method for partitioning public health research data space through namespace information configured on nodes. Transactions and corresponding data between members within each namespace are processed only by the relevant nodes within that namespace, and consensus verification and data storage are completed according to preset consensus rules. For example, the infectious disease data namespace only allows public health management center nodes to participate in consensus, and external institutions cannot access it.

[0110] Specifically, regarding the namespace planning and configuration process, a namespace planning scheme is formulated during the system deployment phase based on the classification and needs of public health services. Blockchain nodes are divided into namespaces according to the type of public health service (e.g., infectious diseases, occupational diseases). The scope of services covered by each namespace, the types of participating nodes, and the corresponding permission settings are determined.

[0111] For example, for infectious disease data namespaces, it is explicitly stated that only relevant nodes of public health management centers and nodes of specific research institutions involved in infectious disease research can join. Then, through the blockchain's node configuration mechanism, namespace information is assigned to each node. In the node's initialization configuration file, a namespace identifier and related connection parameters are added to ensure that the node can accurately identify its own namespace and establish communication connections with other nodes within that namespace.

[0112] Compared to related technologies that often divide data storage areas by institution or region without logically isolating them based on public health service types (such as infectious diseases and occupational diseases), this application's embodiment dynamically creates namespaces based on business attributes (such as data sensitivity and usage scenarios) through the aforementioned process. This facilitates data categorization by business and permission control by space. Blockchain nodes are divided into independent namespaces according to public health service types (such as infectious diseases, occupational diseases, and maternal and child health), with data within each space only accessible to the corresponding business node. For example, the "Infectious Disease Data Namespace" only includes nodes from public health management centers and infectious disease hospitals, while the "Occupational Disease Data Namespace" is limited to nodes from the occupational health department of the National Health Commission. This physically cuts off cross-business data penetration paths, thereby achieving business-dimensional isolation.

[0113] Regarding the consensus mechanism customization and deployment process, for each namespace, a corresponding consensus mechanism is customized based on its business characteristics and data processing needs, allowing for the deployment of different consensus mechanisms according to the characteristics of public data. Taking the infectious disease data namespace as an example, due to the high requirements for data timeliness and accuracy, an optimized version of the Practical Byzantine Fault-Tolerant (PBFT) consensus algorithm can be used. For low-frequency data namespaces such as those related to chronic disease management, the more energy-efficient Proof-of-Stake (PoS) algorithm is used to save node computing resources.

[0114] During the deployment of the consensus algorithm, the set of nodes participating in the consensus is clearly defined; only nodes belonging to that namespace are eligible to participate. Each namespace only allows specific nodes to participate in the consensus (e.g., the infectious disease space whitelist includes the IP addresses of public health management center nodes), and external nodes cannot insert malicious blocks. For example, when a hacker attacks a hospital node, because that node is not on the infectious disease space whitelist, it cannot tamper with the public health management center's data consensus process. Simultaneously, parameters for the consensus algorithm are set, such as a node number threshold and message propagation timeout, to ensure efficient and stable consensus within that namespace.

[0115] Regarding data storage and access control, when data is stored within a namespace, nodes store the data locally or in a distributed storage system according to preset rules, and record the data's index information on the blockchain. Data access control is also managed based on namespaces; only nodes belonging to the same namespace can access the corresponding data under specific permission conditions (such as verification through attribute-based encryption authorization mechanisms). When an external node attempts to access data within the infectious disease data namespace, the blockchain network will reject the access request according to the namespace's isolation rules.

[0116] Specifically, namespace isolation rules include, but are not limited to: data isolation, where data in different namespaces is independent and cannot directly access data in other namespaces; operation isolation, where operations (such as read, write, and update) are limited to nodes within the current namespace; and consensus isolation, where each namespace has an independent consensus mechanism to ensure data consistency and reliability. In related technologies, all nodes participate in unified consensus, while the embodiments of this application are optimized for business characteristics (such as the need for real-time consensus on infectious disease data), thereby effectively improving the efficiency and security of consensus for highly sensitive data.

[0117] Based on the above scheme, the blockchain network can set rules in the underlying protocol to prohibit direct communication and data access across namespaces, thereby restricting cross-namespace interaction. The specific operation is as follows:

[0118] Step a: Add a verification mechanism for the message source namespace to the node's communication protocol stack. Each namespace has a unique identifier (such as namespaceID) that is used to distinguish different business domains or data types (such as infectious disease data, occupational disease data, etc.).

[0119] In step b, nodes are assigned to a specific namespace during initialization, and each node has an associated namespace identifier.

[0120] Step c: Each message transmitted over the network contains a header, which includes the sender's namespace identifier (senderNamespaceID).

[0121] Step d: When a node receives a message, it first checks whether the message header contains a valid namespace identifier.

[0122] Step e: When a received message comes from another namespace, the message is discarded without any processing.

[0123] Step f: At the data query and transaction operation level, the smart contract will perform namespace legality checks on the data and operations involved to ensure that all operations are performed within the same namespace and prevent illegal operations across namespaces.

[0124] In related technologies, access control is only implemented at the data access layer, without isolation at the underlying levels such as message transmission and contract execution. In contrast, the above embodiment achieves end-to-end verification of namespace legitimacy from message header to smart contract execution. Specifically, through a three-tiered isolation system of message header verification, smart contract verification, and a consensus node whitelist, for example, when an external organization attempts to access infectious disease data by tampering with the message header, it is first intercepted by the node message verification layer. If it manages to access the contract layer, the smart contract will verify the namespace legitimacy again. Finally, the consensus layer, lacking the necessary permissions for that node, refuses to generate a block, forming multiple layers of protection, unlike the single access control of related technologies.

[0125] Furthermore, message-level isolation is achieved by including a senderNamespaceID header in each network message. Receiving nodes discard messages with a mismatch in the source namespace (e.g., if a message sent by an occupational disease node contains namespaceID: infectious disease, the infectious disease node will reject it directly), preventing cross-namespace data injection. Contract-level control is achieved by smart contracts automatically verifying the consistency between the caller's namespace and the data's namespace before executing data operations. For example, when a pharmaceutical company node calls a smart contract to query infectious disease data, the contract detects that its namespace is "Pharmaceutical Company-R&D," which does not match the data's namespace "Infectious Disease-Public Health Management," and immediately rejects the request. This approach is more effective than post-auditing in preventing risks in advance.

[0126] In some embodiments, the namespaces mentioned above include temporary namespaces, and the generation of unique identifiers for each namespace may further include the following steps:

[0127] The system monitors new events on the blockchain via blockchain nodes. When a new event is detected, a temporary namespace is set up on the blockchain, and a corresponding unique identifier is dynamically generated for the temporary namespace.

[0128] Specifically, blockchain nodes monitor new events on the chain in real time. Key new triggering events can include: business operation events, such as the EmergencyDataShare event defined in the smart contract (e.g., submitting a target pathogen characteristic fragment), which automatically parses event parameters (including data type, emergency parameters, and a list of involved institutions); permission change events, which are synchronized to the entire network through the AttributeUpdated event when node attributes are dynamically updated (e.g., a hospital is temporarily included in the joint prevention and control system), triggering namespace expansion; and time threshold events, which are triggered by preset time conditions (e.g., when the emergency response level for a public health event is raised to Level I), automatically triggering the namespace creation process by an on-chain timer contract (implemented using Chainlink Keepers).

[0129] Upon detecting new on-chain events, the system temporarily creates a namespace on the blockchain. This temporary namespace can employ a hierarchical structure, dividing public health data into four levels: "Global - Regional - Service Node - Medical Institution." For example, when a top-tier hospital needs to temporarily share a batch of health intervention records, a temporary namespace named "Health Intervention-202308-XX Hospital" is dynamically generated and stored on the blockchain using the NMT root hash. Combined with a dynamic routing algorithm, the namespace hierarchy is automatically adjusted based on data access frequency, such as elevating the frequently accessed "Health Intervention-202308" namespace to a second-level directory.

[0130] Furthermore, namespace identifiers are dynamically added through node configuration files to perform dynamic generation of unique identifiers, ensuring their global uniqueness and traceability. Specifically, a three-level namespace identifier can be automatically generated based on the event parameters of newly added events on the chain, in the format: temp:{event type}:{geographical range}:{timestamp}. Double hash encoding is used to ensure uniqueness: first, the event parameters are hashed using SHA-256, and then the final identifier is generated by combining it with the blockchain height, avoiding name conflicts. Geographic information encoding (such as using latitude and longitude hashes in the GCJ-02 coordinate system) is embedded to achieve precise binding between the namespace and the actual prevention and control area. For example: temp:Covid-19:hangzhou:2002508121430 (a temporary namespace triggered in Hangzhou at 14:30 on August 12, 2025). This process can also be combined with consensus mechanisms (such as PoW or PBFT) to verify the legitimacy of the event and use cryptographic algorithms (such as hash functions) to ensure the security of the identifier. Ultimately, the generated unique identifier is bound to a temporary namespace and recorded on the blockchain. Based on the list of institutions in the event (such as "Hangzhou Public Health Management Center + 3 designated hospitals"), the node identity is verified through on-chain DID, and eligible nodes are automatically added to the namespace, generating a node whitelist (stored in the on-chain sharded database LevelDB). This ultimately achieves resource isolation and dynamic permission management, such as temporarily opening emergency response channels in public health data sharing.

[0131] In related technologies, blockchain namespaces (such as static namespaces in consortium blockchains) typically need to be pre-configured and fixed in the long term. However, this application, through the above embodiments, dynamically generates temporary namespaces by listening to on-chain events and assigning unique identifiers. This enables the rapid creation of dedicated spaces when new business needs are added. For example, in the event of a sudden outbreak of a new infectious disease, temporary namespaces can be created in real time and participating nodes can be configured without reconstructing the blockchain architecture to add storage areas. Thus, event-driven dynamic namespace management solves the problem of rigid resource allocation in traditional solutions that cannot adapt to instantaneous business needs (such as short-term collaboration and temporary data isolation). It realizes dynamic configuration of storage areas and effectively improves the flexibility and scalability of storage area settings.

[0132] In some embodiments, the above-mentioned setting up a temporary namespace on the blockchain upon detecting a new event on the chain may further include the following steps:

[0133] If multiple new on-chain events are detected, the dynamic weight value assigned to each new on-chain event is obtained, and the event detection index of the new on-chain events is calculated based on the dynamic weight value. The dynamic weight value is generated by a smart contract deployed on the blockchain. When the event detection index reaches a preset index threshold, a temporary namespace is set on the blockchain.

[0134] When the blockchain system detects multiple new events, the smart contract dynamically generates a weight value for each event (the weight calculation is based on parameters such as business urgency, the sensitivity level of the event's associated data, and the permissions of the participating entities). The smart contract defines the weight-related parameters and calculation logic; for example, it quantifies "event urgency (level 1-5)" and "data sensitivity (level 1-3)," with the weight value = (urgency level × 0.6) + (sensitivity level × 0.4). When an event is triggered, the smart contract automatically reads the event's associated parameters (e.g., "level 5 urgency + level 3 sensitivity") and calculates the weight. The system then calculates a comprehensive event detection index based on this weight value: Σ(event feature value × dynamic weight) / total number of events. If the calculated event detection index reaches a preset threshold, it automatically triggers an on-chain transaction to create a temporary namespace. This process ensures full-node consensus verification through the deterministic execution of the smart contract, guaranteeing response efficiency while preventing the abuse of on-chain resources.

[0135] In some embodiments, after assigning each blockchain node on the blockchain to multiple namespaces and generating a unique identifier for each namespace, the above-described method for sharing public health data further includes the following steps:

[0136] On the blockchain, the frequency of periodic operations and storage capacity usage of each namespace are counted. If the frequency of periodic operations is found to be lower than a preset threshold, and / or the storage capacity usage reaches a preset threshold, the encrypted data in the corresponding namespace is migrated to the long-term storage node in the blockchain, and the namespace is deleted through the blockchain node.

[0137] In this embodiment, a self-destructing smart contract is added to monitor the read / write operation frequency and storage capacity usage of each namespace in the blockchain system in real time over a certain period. When the periodic operation frequency of any namespace is detected to be lower than a preset operation threshold or the storage usage reaches a preset capacity threshold, the smart contract automatically triggers an encrypted data migration process. This process fragments the encrypted data within the namespace and transmits it to a long-term storage node (such as an IPFS cluster) in the blockchain network. After data integrity verification is completed on-chain, the consensus node executes the namespace deletion operation, simultaneously releasing on-chain storage resources and updating the state database. For example, if a namespace remains unused for more than 7 days, the mechanism automatically deletes the namespace. To ensure data integrity, the namespace data is migrated to a long-term storage node before destruction, thereby ensuring data recoverability.

[0138] In some embodiments, the above-described method for sharing public health data further includes the following steps:

[0139] Within the namespace, encrypted data is subjected to privacy verification calculations based on received zero-knowledge proofs via blockchain nodes. If the privacy verification calculations pass, the encrypted data is stored on the blockchain.

[0140] Specifically, to further enhance data privacy protection, this embodiment employs cryptographic commitments combined with a Trusted Execution Environment (TEE), such as Intel SGX, to hide state data and transaction bodies on the blockchain. When sending a transaction, the user must include a blinding factor, using a cryptographic commitment to encrypt the information in the transaction body into ciphertext, and verify the transaction and its blinding factor. Furthermore, sensitive data is decrypted and computed within the TEE, and the results can be verified on-chain using zero-knowledge proofs (zk-SNARKs), ensuring that data is usable but not visible.

[0141] Regarding the cryptographic commitment generation and verification process, when a user initiates a data transaction or operation, a blind factor is first generated, typically a random number. Using a cryptographic commitment algorithm (such as Pedersen commitment), sensitive information in the transaction (such as patient diagnostic data, key indicators of research projects, etc.) is combined with the blind factor to generate a commitment ciphertext. The user sends the commitment ciphertext, the blind factor, and the related transaction request to the blockchain network. Upon receiving the transaction request, the blockchain node verifies the commitment ciphertext and the blind factor according to preset cryptographic commitment verification rules. During verification, the node uses the same cryptographic commitment algorithm to recalculate the commitment ciphertext based on the received blind factor and known relevant parameters, and compares it with the received commitment ciphertext. If they match, the verification passes, indicating that the sensitive information in the transaction has not been tampered with during transmission; otherwise, the transaction request is rejected.

[0142] For data processing within a Trusted Execution Environment (TEE), verified transaction requests involving sensitive data computations are sent to nodes equipped with a TEE (such as Intel SGX) for processing. Within the TEE, the ciphertext of the commitment is first decrypted to obtain the original sensitive data. Because the TEE provides hardware-level security, it prevents external malicious programs from stealing the decryption process and sensitive data. After obtaining the sensitive data, computational operations are performed according to specific business logic. For example, in statistical analysis of infectious disease data, statistical calculations are performed on patient diagnostic data within the TEE to obtain statistical results such as incidence rates and transmission trends. After the calculations are completed, the results are encrypted, ready for verification using zero-knowledge proofs.

[0143] To verify and upload zero-knowledge proofs (zk-SNARKs) to the blockchain, zero-knowledge proof technology is used to verify the correctness of computation results without disclosing the specific content of sensitive data. Within the TEE (Trusted Execution Environment), a zero-knowledge proof is generated based on the computation result and the original encrypted data. The zero-knowledge proof contains a series of proof parameters that demonstrate the computation result is derived from correct input data and computational logic, without revealing any information about the input data. The encrypted computation result and the zero-knowledge proof are then sent to the blockchain network. Upon receiving this information, blockchain nodes verify the computation result and proof according to the zero-knowledge proof verification algorithm. During verification, nodes do not need to know the original sensitive data; they only need to determine the legality of the computation result based on the parameters in the zero-knowledge proof and the preset verification rules. If the verification passes, the encrypted computation result is recorded on the blockchain; if the verification fails, the computation result is rejected, ensuring the authenticity and reliability of the data on the blockchain.

[0144] The present application will now be described and illustrated through specific embodiments. Figure 3 This is a schematic diagram of the architecture of a trusted public health data sharing system according to an embodiment of this application, such as... Figure 3 As shown, this blockchain-based public health trusted data space architecture includes trusted identity management, secure data storage, and privacy data protection.

[0145] The identity trust management sub-framework comprises two main modules: a distributed digital identity management system and an attribute-based encrypted authorization mechanism. These two modules work together to ensure information authorization and efficient management in a public health research environment. The data security storage sub-framework includes two main modules: an efficient hybrid storage model and on-chain / off-chain collaborative data storage. These two modules work together to ensure the security, integrity, and efficient management of public health research data. The privacy data protection sub-framework includes: namespace-based data sharing isolation and privacy-preserving computation based on cryptography and trusted hardware.

[0146] The above embodiments effectively address the challenges of identity and access control, trusted data storage, and privacy protection in public health data sharing platforms, ensuring data sharing security and comprehensively resolving security issues. Furthermore, through a distributed digital identity management system and user access policies, fine-grained access control of data is achieved, ensuring data security and realizing granular access control. An efficient hybrid storage model and on-chain / off-chain collaborative storage technology improve data storage efficiency and security, meeting the storage needs of different types of data and strengthening secure storage. Privacy-preserving computation based on cryptography and trusted hardware, as well as namespace-based data sharing isolation, effectively protect data privacy and prevent data leakage.

[0147] It should be noted that the steps shown in the above process or in the flowchart of the accompanying figures can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0148] This embodiment also provides a public health data sharing device for implementing the above embodiments and preferred embodiments, which will not be repeated hereafter. As used below, the terms "module," "unit," "subunit," etc., can refer to a combination of software and / or hardware that performs a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0149] Figure 4 This is a structural block diagram of a public health data sharing device according to an embodiment of this application, such as... Figure 4As shown, the device includes: a storage module 41, a request detection module 42, and an access module 43; wherein:

[0150] Storage module 41 is used for a blockchain-based distributed ledger to generate corresponding on-chain digital identities for each participating entity; the blockchain stores encrypted data bound to the on-chain digital identities, and the encrypted data is obtained by encrypting public health data based on an access policy, which is generated based on preset user attribute conditions.

[0151] Request detection module 42 is used to detect user access requests;

[0152] Access module 43 is used to respond to a detected user access request, parse the access user attributes, and if the access user attributes are found to be in accordance with the access policy, send the decryption key of the encrypted data to the access user based on the on-chain digital identity indicated by the user access request.

[0153] In some embodiments, the aforementioned public health data sharing device further includes an isolation module; the isolation module is used to allocate each blockchain node on the blockchain to multiple namespaces according to a preset public health business type, and generate a unique identifier for each namespace; for each namespace, a consensus mechanism is customized according to the corresponding public health business type; wherein, the blockchain nodes within the namespace share encrypted data based on the unique identifier and using the corresponding consensus mechanism.

[0154] It should be noted that the above modules can be functional modules or program modules, and can be implemented by software or hardware. For modules implemented by hardware, the above modules can reside in the same processor; or the above modules can be located in different processors in any combination. Specific examples in this embodiment can be found in the examples described in the above embodiments and optional implementations, and will not be repeated in this embodiment.

[0155] This embodiment also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0156] Optionally, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.

[0157] Optionally, in this embodiment, the processor can be configured to perform the following steps via a computer program:

[0158] S1, a distributed ledger based on blockchain, generates corresponding on-chain digital identities for each participating entity; the blockchain stores encrypted data bound to the on-chain digital identities, and the encrypted data is obtained by encrypting public health data based on access policies, which are generated based on preset user attribute conditions.

[0159] S2 detects user access requests.

[0160] S3, in response to the detected user access request, parses the access user attributes; if the access user attributes are found to match the access policy, sends the decryption key of the encrypted data to the access user based on the on-chain digital identity indicated by the user access request.

[0161] It should be noted that the specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementations, and will not be repeated here.

[0162] Furthermore, in conjunction with the public health data sharing methods in the above embodiments, this application embodiment can provide a storage medium for implementation. This storage medium stores a computer program; when executed by a processor, the computer program implements any of the public health data sharing methods in the above embodiments.

[0163] Those skilled in the art should understand that the technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments have been described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0164] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A method of sharing public health data, characterized by, The method comprises: Based on the distributed ledger of the blockchain, the corresponding on-chain digital identity of each participating subject is generated; the blockchain stores encrypted data bound to the on-chain digital identity, which is encrypted based on an access policy on public health data, and the access policy is generated based on a preset user attribute condition; Detecting a user access request; In response to the detected user access request, the access user attribute is parsed; if it is detected that the access user attribute meets the access policy, the decryption key of the encrypted data is sent to the access user based on the on-chain digital identity indicated by the user access request.

2. The sharing method of claim 1, wherein, The distributed ledger based on the blockchain generates a corresponding on-chain digital identity for each participating subject, comprising: Embedding the subject name of the participating subject into a preset identifier prefix to obtain identification information of the participating subject; Generating a public-private key pair, encapsulating the subject public key in the public-private key pair with the identification information to obtain encapsulation data; encrypting the encapsulation data and storing it on the distributed ledger as the on-chain digital identity.

3. The sharing method of claim 2, wherein, The response to the detected user access request includes: Collecting Internet of Things device sensing data through an edge computing node and uploading the Internet of Things device sensing data to the blockchain; On the blockchain, real-time space-time data is generated by parsing the Internet of Things device sensing data, and the fine-grained attribute of the participating subject is generated according to the real-time space-time data and the acquired public health dynamic parameters; Based on the subject private key in the public-private key pair of the on-chain digital identity, the fine-grained attribute is signed to obtain a verifiable credential; In the case of detecting the user access request, the subject public key is obtained from the blockchain, and the verifiable credential is verified based on the subject public key; if the verification is passed, the access user attribute is parsed.

4. The sharing method of claim 1, wherein, The storage process of the encrypted data comprises: Dividing the encrypted data to determine structured data and unstructured data; The unstructured data is stored in an off-chain distributed file system, and the file hash value of the unstructured data and the structured data are uploaded to the blockchain for storage; Wherein, the blockchain is divided into multiple independent storage shards, the independent storage shards include index storage shards carrying index values, and unstructured storage shards allocated for the unstructured data; the blockchain stores the structured data to the index storage shards, and stores the file hash value of the unstructured data to the unstructured storage shards.

5. The sharing method of claim 1, wherein, The method further comprises: According to a preset public health business type, each blockchain node on the blockchain is allocated to a plurality of namespaces, and a unique identifier is generated for each namespace; For each of the namespaces, a consensus mechanism is customized according to the corresponding public health business type; wherein, the blockchain nodes in the namespace adopt the corresponding consensus mechanism to share the encrypted data based on the unique identifier. Verifying, via the blockchain node, a header message in a received blockchain network message based on the unique identifier, and processing, by the blockchain node, the blockchain network message if the header message verification is passed.

6. The sharing method of claim 5, wherein, The namespaces include temporary namespaces, and the unique identifiers are generated for the respective namespaces, including: Listening, via the blockchain node, to on-chain new events; In a case where the on-chain new events are listened to, setting the temporary namespaces on the blockchain, and dynamically generating corresponding unique identifiers for the temporary namespaces.

7. The sharing method of claim 6, wherein, The setting of the temporary namespaces on the blockchain in a case where the on-chain new events are listened to includes: If there are multiple on-chain new events listened to, obtaining dynamic weight values assigned to the respective on-chain new events, calculating an event detection index of the on-chain new events based on the dynamic weight values, and wherein the dynamic weight values are generated by a smart contract deployed on the blockchain; In a case where the event detection index reaches a preset index threshold, setting the temporary namespaces on the blockchain.

8. The sharing method of claim 5, wherein, After the respective blockchain nodes on the blockchain are allocated to the multiple namespaces and the unique identifiers are generated for the respective namespaces, the method further includes: On the blockchain, counting a periodic operation frequency and a storage capacity occupation of each of the namespaces; If it is detected that the periodic operation frequency is lower than a preset frequency threshold and / or the storage capacity occupation reaches a preset occupation threshold, migrating encrypted data in a corresponding namespace to a long-term storage node in the blockchain, and deleting the namespace via the blockchain node.

9. The sharing method of claim 5, wherein, The method further includes: In the namespace, performing, via the blockchain node, a privacy verification calculation on the encrypted data based on a received zero-knowledge proof, and storing the encrypted data on the blockchain if the privacy verification calculation is passed.

10. A storage medium, characterized by The storage medium has a computer program stored therein, and the computer program is configured to execute the sharing method of public health data according to any one of claims 1 to 9 when running. The storage medium has a computer program stored therein, and the computer program is configured to execute the sharing method of public health data according to any one of claims 1 to 9 when running.

Images