Intelligent Management Method and System for the Entire Process of Chronic Disease Data Based on Multi-Source Medical Data Fusion

Abstract

This invention provides a method and system for intelligent management of chronic disease data throughout the entire process based on the fusion of multi-source medical data. By deploying identity anchoring chains and policy consensus chains respectively, it achieves decentralized management of the DID identity lifecycle and access policies. Combined with zero-knowledge proof technology, it completes the verification of identity validity and policy compliance only without exposing sensitive attribute information. With the help of a trusted execution environment and a one-time lightweight access token, it ensures the secure transmission and audit traceability of access authorization. This invention can effectively prevent single points of failure and collusion attacks, improve the mutual trust of multi-party data and the dynamic policy adaptation capability, and realize the secure collaboration and compliant circulation of chronic disease data among multiple institutions.

Description

Technical Field

[0001] This invention relates to the field of blockchain medical data access control technology, and in particular to a method and system for intelligent management of chronic disease data throughout the entire process based on the fusion of multi-source medical data. Background Technology

[0002] In the fields of chronic disease management and multi-source medical data access control, with the rapid growth in demand for medical big data, distributed collaborative diagnosis and treatment, and data compliance governance, data security, privacy protection, and flexible policy governance have become the core technology development directions for the industry. Current mainstream technical solutions mostly employ technologies such as blockchain smart contracts, distributed identity (DID) modeling, and attribute-based access control (ABAC) to attempt to improve data security and system scalability in a decentralized manner. In terms of technological trends, the industry is promoting the combination of consortium blockchains and distributed identity systems, striving to achieve identity authentication and access control in multi-institutional collaborative environments. However, in actual deployments, identity credentials and access policies remain highly coupled, and access control is often concentrated in a single smart contract or centralized gateway node, limiting flexibility and scalability in cross-institutional scenarios. Typical implementations of access control in healthcare blockchains include: registering and managing identity credentials on-chain using DID technology, automatically allocating access permissions through smart contracts, and directly binding user identity and data permissions based on role or attribute models. These solutions are generally suitable for internal institutions or limited collaborative environments. However, for chronic disease management involving multiple stakeholders such as hospitals, community centers, and telemedicine platforms, numerous technical bottlenecks remain. The processes of identity authentication and permission allocation are interconnected, and policy adjustments must synchronously affect all platforms, making it difficult to dynamically adjust access control rules. The original attribute plaintext needs to be uploaded to the contract for verification, leading to sensitive information leakage and compliance pressure. Weak policy consensus mechanisms make it difficult to support frequent evolution of clinical operations and federated policy governance, limiting system resilience and security. Summary of the Invention

[0003] In order to solve the above-mentioned technical problems, this invention provides a method and system for intelligent management of chronic disease data throughout the entire process based on the fusion of multi-source medical data.

[0004] The technical solution of this invention is implemented as follows: a method for intelligent management of chronic disease data throughout the entire process based on multi-source medical data fusion, comprising: S1: Initially deploy two dedicated consortium blockchains based on a multi-institutional collaborative environment: Identity Anchor Chain (IAL) and Policy Consensus Chain (PCL). IAL uses a lightweight distributed identity protocol to record the DID identifier, registration timestamp, revocation status, and public key hash of each participant, and is only used to prove the existence and lifecycle status of identities. PCL is jointly operated and maintained by collaborating institutions and is used to publish and version-manage fine-grained access policy templates encoded in Structured Policy Description Language (SPDL), along with policy hashes, effective times, reviser signatures, and multi-signature consensus signatures, forming a verifiable policy governance infrastructure on the chain. S2: For access requests from patients, doctors, community centers, or remote platforms, obtain their locally held distributed identity private key, attribute credential set, and policy hash corresponding to the chronic disease data resource to be accessed. Based on the above information, construct the input parameter set of the zero-knowledge proof circuit, where the circuit logic is designed to verify three conditions: the DID is in a valid state in IAL, the attribute credential meets the requirements of the latest version of SPDL policy pointed to by the corresponding policy hash in PCL, and the current request does not exceed the context constraints defined by the policy. S3: Using zk-SNARK technology, the circuit constructed in step S2 is compiled into a non-interactive zero-knowledge proof that can be efficiently verified, generating a compact proof package that includes proof π and public inputs (DID identifier, policy hash, resource metadata), ensuring that the cryptographic binding verification of identity validity and policy compliance is completed without exposing the original attribute plaintext. S4: Submit the zero-knowledge proof package generated in step S3 to the gateway node. The gateway calls the IAL smart contract to verify whether the DID is in an unrevoked state, and synchronously obtains the latest policy version associated with the corresponding policy hash and its multi-signature confirmation record from PCL to form an on-chain state consistency verification result, which serves as the prerequisite input for subsequent trusted execution environment verification. S5: Input the on-chain state consistency verification result obtained in step S4 and the zero-knowledge proof π into the off-chain trusted execution environment (TEE), execute the proof verification algorithm in the isolated security context, determine whether π passes the verification and whether all public inputs match the current on-chain state. If it passes, output the verification success signal and trigger the one-time lightweight access token (LAT) generation instruction. S6: In response to the verification success signal in step S5, generate a one-time lightweight access token (LAT) that binds the resource ID, the hash of this proof, and an encrypted random number. This token does not contain any plaintext information about the user's identity or attributes, but only carries an expiration timestamp and an encrypted encapsulation of the zk-SNARK output commitment, which is used to achieve permission transfer with minimal information disclosure. S7: Distribute the lightweight access token (LAT) generated in step S6 to the target data service node. The service node uses the locally cached IAL and PCL lightweight synchronization data to perform offline fast verification to determine whether the LAT is valid and whether its associated proof hash can be traced back to the valid on-chain policy and identity status through the local mapping relationship, thereby deciding whether to open the access channel for the corresponding chronic disease data resource. S8: Automatically triggers the writing of event logs to the immutable ledger of IAL or PCL every time a policy update, DID revocation, or LAT issuance and usage operation occurs. Supports cross-chain auditing and tracing based on DID identifier or policy hash, forming a full-link verifiable trust chain covering identity lifecycle, policy evolution path, and access behavior trajectory.

[0005] The present invention also provides an intelligent management system for the entire process of chronic disease data based on the fusion of multi-source medical data, which uses the above-mentioned intelligent management method for the entire process of chronic disease data based on the fusion of multi-source medical data to perform intelligent management of chronic disease data.

[0006] The intelligent management method and system for the entire process of chronic disease data based on multi-source medical data fusion provided by this invention has the following beneficial effects: (1) This invention effectively decouples the strong binding relationship between user identity identifiers and access permissions by constructing a dual-chain collaborative architecture of identity anchor chain and policy consensus chain. In this scheme, IAL only carries minimal identity metadata to ensure the verifiability and immutability of identity status, while PCL focuses on the version governance of fine-grained access policies and multi-institutional consensus decision-making, so that the permission rules can evolve independently without affecting the stability of the identity system. Combined with the structured policy description language, multi-dimensional context conditions (such as roles, time windows, access frequency, and behavior history) are formally encoded, and a multi-signature consensus mechanism is introduced to ensure the legality and traceability of policy release. This significantly improves the democracy, transparency and adaptability of policy formulation in complex medical collaboration scenarios, and provides a highly flexible and auditable permission infrastructure for the dynamic doctor-patient collaboration relationship in chronic disease management. (2) This invention introduces an off-chain verification mechanism based on zero-knowledge proof and trusted execution environment, which realizes efficient permission determination under high privacy strength. The requester generates zk-SNARK proof locally, which can complete the cryptographic verification of DID validity, policy compliance and context constraint satisfaction without disclosing any original attribute certificate. The gateway node uses TEE to realize the fast verification of the proof, avoiding the upload of sensitive attributes to the chain or exposure to public contract logic, fundamentally preventing attribute reasoning attacks and identity association tracking. At the same time, the resource access decoupled authorization is realized through one-time lightweight access token (LAT). The service node can complete the token verification based on the locally cached chain state in the offline state, which greatly reduces the frequency of on-chain interaction and network latency, and significantly improves the system throughput and response real-time performance. It is especially suitable for high-frequency, asynchronous, low-trust-based chronic disease data sharing scenarios among multiple institutions. (3) This invention designs an end-to-end event logging and audit tracing mechanism, which supports tracing the complete access control lifecycle by DID or policy hash, enhancing the system's interpretability, compliance controllability, and federated governance capabilities. All critical operations (including policy revision, DID revocation, LAT issuance and use) are automatically recorded in the corresponding chain's immutable ledger, forming a complete behavioral audit trail. Combined with policy version management and canary release support, different medical institutions can pilot new policies in local areas before gradually promoting them, effectively avoiding the risk of service interruption caused by global policy mutations. This mechanism not only meets the strict regulatory requirements in the healthcare field (such as GDPR and HIPAA), but also provides solid data support for cross-organizational responsibility definition, abnormal behavior detection, and post-event accountability. Attached Figure Description

[0007] Figure 1 The flowchart shows the intelligent management method for the entire process of chronic disease data based on multi-source medical data fusion according to the present invention. Figure 2 This is a sub-flowchart of the intelligent management method for the entire process of chronic disease data based on multi-source medical data fusion according to the present invention; Figure 3 This is another sub-flowchart of the intelligent management method for the entire process of chronic disease data based on multi-source medical data fusion of the present invention. Detailed Implementation

[0008] Embodiments of the present invention are described in detail below, examples of which are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0009] The following disclosure provides many different embodiments or examples for implementing different structures of the invention. To simplify the disclosure, specific examples of components and arrangements are described below. Of course, these are merely examples and are not intended to limit the invention. Furthermore, reference numerals and / or letters may be repeated in different examples; such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed.

[0010] like Figure 1 As shown, this invention provides an intelligent management method for the entire process of chronic disease data based on the fusion of multi-source medical data, specifically including: S1: Initially deploy two dedicated consortium blockchains based on a multi-institutional collaborative environment: Identity Anchor Chain (IAL) and Policy Consensus Chain (PCL). IAL uses a lightweight distributed identity protocol to record the DID identifier, registration timestamp, revocation status, and public key hash of each participant, and is only used to prove the existence and lifecycle status of identities. PCL is jointly operated and maintained by collaborating institutions and is used to publish and version-manage fine-grained access policy templates encoded in Structured Policy Description Language (SPDL), along with policy hashes, effective times, reviser signatures, and multi-signature consensus signatures, forming a verifiable policy governance infrastructure on the chain. S2: For access requests from patients, doctors, community centers, or remote platforms, obtain their locally held distributed identity private key, attribute credential set, and policy hash corresponding to the chronic disease data resource to be accessed. Based on the above information, construct the input parameter set of the zero-knowledge proof circuit, where the circuit logic is designed to verify three conditions: the DID is in a valid state in IAL, the attribute credential meets the requirements of the latest version of SPDL policy pointed to by the corresponding policy hash in PCL, and the current request does not exceed the context constraints defined by the policy. S3: Using zk-SNARK technology, the circuit constructed in step S2 is compiled into a non-interactive zero-knowledge proof that can be efficiently verified, generating a compact proof package that includes proof π and public inputs (DID identifier, policy hash, resource metadata), ensuring that the cryptographic binding verification of identity validity and policy compliance is completed without exposing the original attribute plaintext. S4: Submit the zero-knowledge proof package generated in step S3 to the gateway node. The gateway calls the IAL smart contract to verify whether the DID is in an unrevoked state, and synchronously obtains the latest policy version associated with the corresponding policy hash and its multi-signature confirmation record from PCL to form an on-chain state consistency verification result, which serves as the prerequisite input for subsequent trusted execution environment verification. S5: Input the on-chain state consistency verification result obtained in step S4 and the zero-knowledge proof π into the off-chain trusted execution environment (TEE), execute the proof verification algorithm in the isolated security context, determine whether π passes the verification and whether all public inputs match the current on-chain state. If it passes, output the verification success signal and trigger the one-time lightweight access token (LAT) generation instruction. S6: In response to the verification success signal in step S5, generate a one-time lightweight access token (LAT) that binds the resource ID, the hash of this proof, and an encrypted random number. This token does not contain any plaintext information about the user's identity or attributes, but only carries an expiration timestamp and an encrypted encapsulation of the zk-SNARK output commitment, which is used to achieve permission transfer with minimal information disclosure. S7: Distribute the lightweight access token (LAT) generated in step S6 to the target data service node. The service node uses the locally cached IAL and PCL lightweight synchronization data to perform offline fast verification to determine whether the LAT is valid and whether its associated proof hash can be traced back to the valid on-chain policy and identity status through the local mapping relationship, thereby deciding whether to open the access channel for the corresponding chronic disease data resource. S8: Automatically triggers the writing of event logs to the immutable ledger of IAL or PCL every time a policy update, DID revocation, or LAT issuance and usage operation occurs. Supports cross-chain auditing and tracing based on DID identifier or policy hash, forming a full-link verifiable trust chain covering identity lifecycle, policy evolution path, and access behavior trajectory.

[0011] Step S1: Initialize and deploy two dedicated consortium blockchains based on a multi-institutional collaborative environment: the Identity Anchor Chain (IAL) and the Policy Consensus Chain (PCL). IAL uses a lightweight distributed identity protocol to record the DID identifier, registration timestamp, revocation status, and public key hash of each participant, and is used only to prove the existence and lifecycle status of identities. PCL is jointly operated and maintained by collaborating institutions and is used to publish and version-manage fine-grained access policy templates encoded in Structured Policy Description Language (SPDL), along with policy hashes, effective times, reviser signatures, and multi-signature consensus signatures, forming a verifiable on-chain policy governance infrastructure. Specifically, this includes: S1.1: Based on the needs of multi-institutional collaborative governance, a blockchain network topology supporting consortium blockchain mode is constructed. The initial set of participating nodes is processed for identity authentication and network access authorization to establish a trusted communication foundation layer with multi-centralization characteristics. The master control node group is initialized using the PBFT consensus mechanism, the genesis block is generated and the inter-chain interoperability interface is configured, and a dual-chain operating environment with cross-chain event listening capability is output as a shared underlying architecture for the Identity Anchor Chain (IAL) and the Policy Consensus Chain (PCL). Under the constraints of multi-institutional collaborative governance, the input conditions include the unique institutional identifier of the initial set of participating nodes, the preset identity authentication public key library, the consortium blockchain network parameter set, and the security policy constraint vector. A node identity authentication method based on the X.509 certificate chain (parameters: institution public key certificate, issuing CA chain, certificate revocation list) is adopted to realize on-chain access identity verification and key pair binding for the initial participating node set, and generate an authentication receipt data structure for subsequent network topology construction. Furthermore, by using a network access authorization method based on access control lists (ACLs) and role mapping matrices (parameters: node identifier list, role level definition, permission mapping table), multi-level permission initialization configuration of nodes in the consortium blockchain network is realized, and an access authorization mapping table containing node role tags and permission vectors is obtained; Furthermore, a master node group initialization method based on the Byzantine Fault Tolerant PBFT consensus algorithm (parameters: initial node set, view number, message signature key set) is adopted to realize the election of master node group and the synchronization of view state, and generate a genesis block data packet containing master node ID, view number and initial state hash; Furthermore, by configuring the algorithm (parameters: chain identifier set, event listening strategy, interface call protocol) through the cross-chain interoperability interface, an inter-chain event listening and state synchronization mechanism between the Identity Anchor Chain (IAL) and the Policy Consensus Chain (PCL) is implemented, and an interface registry that supports cross-chain event push is generated. Through the above-mentioned identity authentication, access authorization, master node initialization and cross-chain interface configuration processing methods, the result of the previous step is transformed into a dual-chain operating environment with cross-chain event listening capabilities, realizing the output of a multi-centralized trusted communication infrastructure layer that supports the consortium blockchain model. For example, in a collaborative environment of five tertiary hospitals and two community centers, the input node set contains seven institutional nodes, each equipped with a 256-bit elliptic curve public key pair, and the corresponding X.509 certificate chain is issued by the national root CA. During the node identity authentication phase, a Certificate Revocation List (CRL) is loaded and on-chain signature verification is performed, outputting a receipt data structure indicating that all nodes have passed authentication. During the access authorization phase, the tertiary hospital nodes are configured as "policy governance nodes" and the community centers as "data access nodes" based on the role mapping matrix, and an ACL mapping table containing role tags and permission vectors is generated. For example, the permission vector for the tertiary hospital nodes is {policy publication = 1, policy modification = 1, data access = 1}. The PBFT initialization phase sets the view number. The message signing key length is The process involves electing three master nodes and generating the genesis block, with the initial state hash being... Both block timestamps and view numbers are bound. During the cross-link configuration phase, the event listening policies for IAL and PCL are registered as "policy change events and identity revocation events." The interface call protocol is based on gRPC for inter-chain state push, generating an interface registry that supports dual-chain state synchronization. This environment has been tested and can stably transmit data per second between nodes. The event message has a cross-chain listening latency of less than [amount missing]. Milliseconds significantly improve the consistency guarantee capability of cross-institutional strategies and identity status; S1.2: In the dual-chain operating environment generated in step S1.1, deploy the Identity Anchor Chain (IAL) and perform lightweight DID protocol stack integration processing on it to support distributed identity modeling compliant with the W3C DID standard; generate asymmetric key pairs based on elliptic curve cryptography, and write the DID identifier, registration timestamp, revocation status, and public key hash of each participant (patient, doctor, community center, remote platform) as unique on-chain evidence storage fields into the block, without storing any attribute or permission information, and outputting an identity evidence storage ledger used only to verify the existence and lifecycle status of the identity, ensuring minimal on-chain identity credentials and compliance with privacy protection; In the dual-chain operating environment generated in step S1.1, the blockchain basic communication channel parameters provided by the network topology and PBFT master control node group are received, including cross-chain event listening interface configuration, node identity authentication credentials and genesis block fingerprint, as input conditions for deploying the Identity Anchor Chain (IAL). A lightweight DID protocol stack integration method is adopted (parameters: conforming to the W3C DID standard, supporting JSON-LD document structure, and having a built-in DID method parser) to achieve on-chain identity modeling functionality that conforms to the global distributed identity specification and construct a unique decentralized identification document for each participant; the protocol stack is loaded as a plugin in the node runtime environment to ensure interface compatibility with the underlying consortium blockchain SDK; Furthermore, an asymmetric key pair for the participants is generated through an elliptic curve cryptography system (parameter: ECDSA, curve type secp256k1), realizing an identity signature and verification mechanism based on a public-private key structure. The public key is digested by SHA-256 to obtain a fixed-length hash value, which is used as an on-chain notarization field to eliminate the risk of theft caused by the exposure of the original public key in plaintext. Furthermore, the registration transaction template in the DID protocol stack is invoked to form a structured registration data packet consisting of the participant's DID identifier, registration timestamp (Unix Epoch format), initial revocation status value, and public key hash. This data packet is then encapsulated using Merkle leaf nodes and broadcast to the latest block after the IAL genesis block, efficiently writing it into the consortium blockchain ledger file system. Furthermore, the transaction verification engine is used to perform contract-level syntax verification and block-level consensus confirmation on the above-mentioned registration transactions to ensure that only the DID core identifier field and lifecycle management information are included, without carrying any attribute or permission data. This physically isolates identity elements and permission elements, achieving the compliance goals of minimizing the on-chain presence of identity credentials and protecting privacy. By using distributed evidence storage writing and verification processing, the registration transaction result of the previous step is transformed into a persistent identity evidence storage ledger, realizing on-chain trusted recording of the identity existence and lifecycle status of multiple participating institutions in the consortium blockchain environment. For example, in a consortium blockchain network consisting of 5 hospital nodes and 2 community health center nodes, a unique ID is generated for each institution using the "did:example" registration mode of the W3C DID standard, such as "did:example:123456789abcdef". An asymmetric key pair with a private key length of 256 bits and a public key length of 512 bits is generated using the ECDSA secp256k1 curve. A 64-character hexadecimal public key hash is obtained by digesting the public key using SHA-256. In the registration transaction construction, the registration timestamp is set to 1695897600, the revocation status is 0 (not revoked), and no attribute information is attached. This transaction is treated as a Merkle leaf node, confirmed by PBFT consensus, and written to block 2 of the IAL ledger at height #102. The block only retains four fields: DID identifier, timestamp, revocation status, and public key hash; no permission data is included. Field verification results show that in cross-organizational authentication requests, the node can complete the verification of the existence of the DID within 200ms without any leakage of sensitive attributes, which greatly improves the efficiency and security of cross-domain trust establishment. S1.3: Based on the identity storage ledger built in step S1.2, define and deploy smart contracts to manage the DID state change process, perform on-chain transaction encapsulation processing for DID registration, update, and revocation operations to achieve tamper-proof audit traceability of the identity lifecycle; the contract logic includes a multi-signature approval mechanism, requiring at least two-thirds of the collaborating parties to sign and confirm institutional-level DID change requests before they can take effect, and output identity governance contract instances with anti-collusion attack capabilities to ensure identity state consistency and non-repudiation in cross-domain scenarios; S1.4: In the dual-chain operating environment provided in step S1.1, the Policy Consensus Chain (PCL) is deployed independently, and the embedded integration processing of the Structured Policy Description Language (SPDL) parsing engine is performed on it to support the formal expression and version management of fine-grained access policies; based on the SPDL encoding rules, the policy semantics are converted into a machine-readable policy object model. Each policy object contains policy hash, effective time, reviser signature and multi-signature consensus signature fields, and a policy version snapshot is formed by organizing through Merkle tree, outputting an on-chain policy governance framework that supports policy canary release and rollback; In the dual-chain operating environment provided in step S1.1, the independent deployment method of the strategy chain (parameters: blockchain network topology, PBFT consensus node group) is adopted to realize the node initialization and chain parameter configuration of the strategy consensus chain (PCL). Based on the embedded engine integration algorithm (parameters: Structured Policy Description Language (SPDL) parser, on-chain storage interface driver), the SPDL parsing engine is embeddedly integrated into PCL, and the core module supporting syntax tree construction and semantic checking is loaded. Furthermore, by using the SPDL encoding rule mapping method (parameters: lexical unit table, policy semantic domain definition), the policy semantics are transformed into a machine-readable object model, and a policy object dataset containing policy hash, effective time, reviser signature, and multi-signature consensus signature is obtained. Furthermore, a Merkle tree organization algorithm (parameters: array of policy objects, hash function type SHA-3, branch factor setting value) is used to build version snapshots of policy objects and generate a root hash index for each policy version for fast on-chain verification and version rollback. By using the on-chain policy governance framework generation method (parameters: PBFT multi-signature consensus service interface, event listener), the policy version snapshot from the previous step is transformed into an on-chain policy governance framework that supports canary releases and rollbacks, thereby achieving verifiability and federated evolution capabilities for policy version management. For example, in a multi-source medical chronic disease data collaboration scenario, the Policy Consensus Chain (PCL) is deployed in a consortium blockchain network structure with 5 hospital nodes and 2 community medical nodes. The PBFT consensus group is set with 4 master nodes and 3 backup nodes, and the fault tolerance threshold is 2. The SPDL parsing engine parameter settings support the parsing of 50 atomic predicates. The lexical unit table includes predicate type identifiers, logical operators, and parameter field descriptions. A policy statement, such as "Access type ∈ {hypertension follow-up} and practicing hospital level = tertiary", is converted into an object model by the SPDL parser: the policy hash is calculated by SHA-3, generating a 256-bit digest value; the effective time field is recorded with a Unix timestamp; the reviser signature is generated using the Elliptic Curve Digital Signature Algorithm (ECDSA), which can verify the identity anchor corresponding to the reviser's institutional public key.

[0012] All policy object versions are organized using a Merkle tree, with a branching factor of 4. The policy object array is arranged in version time sequence, and the root node hash is calculated using the following formula:

[0013] in, For Merkel tree root hash value, and These are the hash values ​​of the left and right subtrees, respectively. This is the concatenation operator. Ultimately, the PCL policy governance framework supports rollback verification of any historical version based on the root hash. When an on-chain policy is published, it can be distributed to select nodes in a canary manner, achieving dynamic policy evolution and cross-organizational consistency. In actual testing, the policy parsing time was reduced to one-third of the original, and the version snapshot verification time was controlled within milliseconds, improving the efficiency and flexibility of on-chain management of access control policies. S1.5: Based on the on-chain policy governance framework built in step S1.4, configure a multi-agency joint operation and maintenance mechanism to perform PBFT-based multi-signature consensus verification processing on the policy release and update process to ensure that policy changes must be jointly approved by the collaborating agencies before they can be put on the chain; each policy submission triggers on-chain event log recording, generating an immutable audit trail containing policy hash, revision timestamp and consensus signature set, and outputting a policy consensus chain (PCL) instance that supports federated policy collaborative evolution, providing an authoritative data source for policy compliance verification in subsequent zero-knowledge proof circuits.

[0014] Step S2: For access requesters from patients, doctors, community centers, or remote platforms, obtain their locally held distributed identity private key, attribute credential set, and policy hash corresponding to the chronic disease data resource to be accessed. Based on the above information, construct a zero-knowledge proof circuit input parameter set, where the circuit logic is designed to verify three conditions: the DID is valid in the IAL, the attribute credential meets the requirements of the latest version of the SPDL policy pointed to by the corresponding policy hash in the PCL, and the current request does not exceed the context constraints defined by the policy. Specifically, this includes: S2.1: Based on the Distributed Identity (DID) registered by the requester in a multi-agency collaborative environment, obtain the DID private key and identity public key hash stored locally in security, and use the Elliptic Curve Digital Signature Algorithm (ECDSA) to generate a temporary challenge value for this access session to sign it, so as to generate a verifiable identity holding certificate, which serves as the input premise for identity control ownership verification in the zero-knowledge proof circuit. S2.2: Perform structured parsing on the set of attribute credentials held locally by the requester, extract multi-dimensional attribute vectors including physician qualification certificate code, practicing institution, professional title level, historical access frequency summary and time-series behavioral fingerprint, and use hash chain encoding to convert each attribute item into a fixed-length cryptographic commitment value to generate an attribute commitment vector, which serves as the original input data for subsequent policy compliance verification. For the set of attribute credentials held locally by the access requester, a structured parsing method (parameters: attribute credential data stream, parsing template rule set) is used to realize the unified field extraction and semantic mapping function for multi-source heterogeneous medical attributes; Furthermore, through a multi-dimensional attribute vector construction algorithm (parameters: physician qualification certificate code field, practicing institution identifier field, professional title level field, historical access frequency log, and time-series behavior fingerprint set), the indexed mapping and vectorized expression of different types of medical attributes are realized, and a fixed-dimensional attribute feature matrix data result is obtained. Furthermore, a hash chain encoding method (parameters: attribute feature matrix, hash function family {SHA-256, SM3}, salt value generation strategy) is adopted to convert each attribute item into a fixed-length cryptographic commitment value and generate a hash chain node sequence to ensure the integrity and immutability of attribute data in the chain verification process. Furthermore, by using an attribute commitment vector synthesis algorithm (parameters: hash chain node sequence, vector concatenation index table), all attribute commitment values ​​are aggregated in an ordered manner, and a single multidimensional attribute commitment vector is generated as the original input data for subsequent policy compliance verification. By using the hash chain encoding and vector synthesis processing methods described above, the parsed attribute features are transformed into tamper-proof attribute commitment data, thereby achieving privacy protection and data consistency assurance in the policy matching process. For example, in a multi-institutional collaborative access control scenario, the set of attribute credentials held locally by a doctor user includes: a physician qualification certificate code of "CN-MED-4389275", a practicing institution identification code of "HOSP-3101", a professional title of "attending physician", historical access frequency logs recording 12 accesses to hypertension follow-up data in the past 30 days, and a time-series behavioral fingerprint set generated by the operation mode of their terminal device. The parsing module maps the above data into an attribute feature matrix according to preset template rules, where the physician qualification certificate code is mapped to... Dimension, the identifier of the practicing institution is mapped to Dimensions, professional title levels are mapped as Dimension, access frequency summary mapping to Dimension, temporal behavioral fingerprint mapping is Dimension. For each dimension's plaintext attribute value, the SHA-256 hash function is used to calculate its commitment value. For example, the commitment value calculation formula for the physician qualification certificate code "CN-MED-4389275" is as follows: ,in This is the SHA-256 function. The five attribute commitment values ​​are concatenated sequentially according to the index table to form the attribute commitment vector. This commitment vector serves as the input to the zero-knowledge proof circuit policy compliance verification submodule. In subsequent verification phases, this commitment vector can be Boolean-matched with the SPDL policy conditions in the policy consensus chain, thereby completing permission verification under cross-domain access control without exposing the original attributes. S2.3: Based on the type of chronic disease data resource to be accessed and its corresponding clinical business scenario, retrieve and obtain the fine-grained access policy hash value bound to the resource from the system metadata directory, and query the latest version of the SPDL policy template recorded in the policy consensus chain (PCL) according to the policy hash, parse out the policy logic expression, context constraints and multi-signature reviser signature chain contained therein, and form a policy benchmark input set for constructing the policy matching judgment rules in the circuit; S2.4: Utilize the Structured Policy Description Language (SPDL) parsing engine to perform syntax tree expansion on the policy baseline input set, extract the atomic predicate conditions in the policy (such as 'practice location ∈ {tertiary hospital}', 'number of violation records < 1', 'daily access limit ≤ 5'), and map each predicate to a computable Boolean logic gate. Combine this with the corresponding fields in the attribute commitment vector to construct a policy compliance verification sub-circuit and output the intermediate results of policy satisfaction determination. After receiving the policy baseline input set output in step S2.3, the structured policy description language (SPDL) parsing engine (parameters: supports atomic predicate parsing, Boolean logic generation, and context constraint extraction) is used to perform syntax tree expansion analysis on the SPDL policy template. Furthermore, through the predicate extraction module (parameters: syntax tree node type = conditional expression, operator set = {∈, <, ≤, =}), all atomic predicate conditions are extracted from the strategy template and a list of predicate conditions is formed, such as "practice location ∈ {tertiary hospital}", "number of violation records < 1", "daily access limit ≤ 5", resulting in a structured set of atomic conditions; Furthermore, by using the logic gate mapping method (parameter: gate type Boolean mapping table = {∈→ set containing gate, <→ comparison gate, ≤→ comparison gate, =→ equivalent gate}), the predicate condition is mapped to the circuit computable Boolean logic gate, and the input port binding relationship corresponding to the attribute commitment vector field is generated, resulting in an executable policy compliance verification gate-level network; Furthermore, for predicate conditions involving numerical comparisons, numerical constraint calculation formulas are used through the comparison submodule within the circuit: ,in This is the value after the attribute commitment vector is unsealed. For SPDL template constants, To establish a precision tolerance threshold, the system verifies the equality or magnitude relationship between the encrypted value and the strategy value, and outputs a Boolean decision signal. Furthermore, by using a Boolean logic aggregator (parameters: logic mode = AND, input sequence = all atomic predicate decision results), the output signals of each predicate logic gate are aggregated and calculated to obtain intermediate results of policy satisfaction determination, which serve as the policy verification branch for subsequent zero-knowledge proof circuit input. Through the above-mentioned SPDL parsing, atomic predicate extraction, Boolean logic mapping and numerical constraint verification processing, the policy benchmark input set formed in the previous step is transformed into an executable policy compliance verification sub-circuit, realizing the non-exposure matching judgment between policy logic and visitor attribute commitment data. For example, in a chronic disease follow-up data access scenario, the SPDL policy template contains three atomic conditions: practice location ∈ {Grade A Tertiary Hospital}, number of violation records < 1, and daily access limit ≤ 5 records. After loading the template, the parsing engine maps the first condition to a Boolean gate containing the set; the second condition to a Boolean gate for numerical comparison, with the input bound to the commitment value of the number of violation records in the attribute commitment vector; and the third condition to a Boolean gate for numerical comparison, with the input bound to the commitment value of the number of daily accesses. The numerical comparison gate uses a formula... Verify that the number of violation records is less than 1, among which The number of violation records to be unblocked. Set to 0.0001 to ensure integer precision; the daily access restriction gate uses the formula. Verify that the number of daily visits does not exceed 5, among which This represents the number of daily visits required for unblocking. The Boolean outputs of all conditions are aggregated by an AND logic aggregator. If the result is true, the intermediate result of the policy satisfaction determination is compliant, and the process proceeds to the next step of constructing the zero-knowledge proof circuit input, achieving deterministic verification of the access request compliance in the encrypted state. S2.5: Integrate identity holding proof, attribute commitment vector, intermediate results of policy satisfaction determination, and context parameters of this request (such as timestamp, device fingerprint, resource ID) to construct a complete set of zero-knowledge proof circuit input parameters. Perform domain adaptation normalization on the parameter set to convert it into a sequence of finite field elements suitable for the zk-SNARK front-end compiler, generating a standardized circuit input tensor that can be called in the next step.

[0015] like Figure 2As shown, step S3 involves using zk-SNARK technology to compile the circuit constructed in step S2 into an efficiently verifiable non-interactive zero-knowledge proof, generating a compact proof package containing proof π and common inputs (DID identifier, policy hash, and resource metadata). This ensures that cryptographic binding verification of identity validity and policy compliance is completed without exposing the original attribute plaintext. Specifically, this includes: S3.1: Based on the zero-knowledge proof circuit logic constructed in step S2, the arithmetic constraint relationship in the circuit is formally modeled using the R1CS (Rank-1 Constraint System) representation method. The three conditions of DID validity verification, attribute satisfaction judgment and context constraint check are transformed into a set of quadratic equation constraint system, which serves as the basic mathematical structure for zk-SNARK proof generation to support parameter generation in the subsequent trust setting stage. Based on the normalized circuit input tensor generated in step S2, this tensor is used as the input set for structured modeling, and the R1CS (Rank-1 Constraint System) representation method is adopted (parameter: finite field). (Variable set V, circuit gate constraint number M), to realize formal modeling of arithmetic constraint relationships in zero-knowledge proof circuits; Furthermore, by constraining the mapping function The identity validity verification conditions are transformed into a system of constraint equations, where each constraint consists of three parts: a left linear combination, a right linear combination, and a target product, satisfying... ,in This represents a linear combination of left-hand factors. This represents a linear combination of factors on the right. The output is a linear combination of the target values; Furthermore, through the attribute satisfaction judgment module, the atomic predicates in the SPDL policy logic are mapped to the arithmetic equivalent form of Boolean logic gates. For example, the predicate "number of violation records < 1" can be transformed into a finite field comparison constraint, in the following form: ,in The variable is the number of violation records. As an auxiliary variable with non-negativity of the difference, it enables a computable mapping from predicate logic to R1CS; Furthermore, through the context constraint checking module, the timestamp, device fingerprint, and resource ID constraints of the access session are modeled as finite-domain consistency verification constraints. For example, the condition that the access frequency within a time window ΔT is ≤k can be encoded as:

[0016] in This is a record of the frequency of the i-th access. This represents the total number of visits within the statistical period. By modeling the R1CS under the three conditions of identity validity, attribute compliance and context constraints, the standardized circuit input tensor of the previous step is transformed into a set of quadratic equation constraint systems that can be directly processed by the zk-SNARK compiler, thus realizing the mathematical structure preparation for the zero-knowledge proof generation stage. For example, in a multi-institutional collaborative scenario for chronic diseases, a limited domain selection is set for a cardiovascular specialist's request to access hypertension follow-up data. ,in It is a 256-bit prime number; the variable set V contains the DID validity flag. (Value 1 indicates validity), Attribute Commitment Summary and access session timestamp Identity validity constraints are established as follows: Attribute compliance constraints are established as The context constraint is within the statistical window ΔT = 86400 seconds. ≤ 5. After processing by R1CS, a system containing 45 constraint equations is generated, of which identity validity accounts for 3 equations, attribute satisfaction accounts for 15 equations, and time and device consistency accounts for 27 equations. The final output is a constraint system data structure that can be directly entered into the zk-SNARK trusted setup process, ensuring that the proof generation efficiency is significantly improved and the security meets the cross-agency access control requirements in this scenario. S3.2: Based on the R1CS constraint system, perform a Trusted Setup Ceremony to generate a Common Reference String (CRS) using structured random numbers. This CRS includes a Proving Key for proving the generated CRS and a Verification Key for verifying the CRS. The Proving Key encapsulates the cryptographic encoding of the original constraint system, enabling the prover to generate a valid proof without exposing private inputs, thereby establishing the security foundation of the zk-SNARK protocol. In step S3.2, the input condition is the R1CS constraint system established in step S3.1. The constraint system already includes three types of quadratic equation relationships: DID validity determination, attribute satisfaction determination, and context constraint verification, which serve as the mathematical foundation for constructing the zk-SNARK trusted settings. A structured random number generation method (parameters: secure seed length λ, secure hash function type SHA-3) is used to initialize and generate the Common Reference String (CRS). Furthermore, through a secure multi-party computation protocol (parameters: number of participants m, randomness refresh rounds r), cross-institutional random entropy aggregation is achieved, and entropy pool data that meets the zero-knowledge proof security parameter standard is obtained, which is used to avoid trust risks caused by a single participant controlling the random source; Furthermore, the Proving Key (PK) and Verification Key (VK) are constructed synchronously using the CRS generation algorithm (parameters: R1CS constraint system matrices A, B, C, and safety entropy pool), generating the following mathematical relationship:

[0017] in For public reference strings, PK is the encryption encoding matrix that encapsulates the original constraint system, and VK is the verification matrix that verifies the constraints against the public input. Furthermore, a key consistency verification method (parameters: hash function H, signature algorithm ECDSA) is used to perform bidirectional hash verification of PK and VK, and generate a unique fingerprint. This serves as a version consistency identifier for subsequent proof generation and verification phases; Through the aforementioned trusted setup ritual, the R1CS structure from the previous step is transformed into a structure containing PK, VK, and The public reference parameter set enables secure initialization and tamper-proof protection for zero-knowledge proof protocols; For example, in a collaborative access scenario for chronic disease data, the R1CS constraint system consists of 512 variables and 1024 constraints. The security parameter λ is set to 256 bits, the number of participants m is 5, and the random refresh rounds r are 3. Each participant generates a 256-bit local random number in the secure multi-party computation protocol, which is then aggregated and processed by SHA-3 to form a secure entropy pool. This entropy pool, along with the constraint system matrices A, B, and C, is input to the CRS construction algorithm, generating a PK size of 15MB and a VK size of 2MB. A consistent fingerprint is obtained through ECDSA signature and hash verification. This ensures that in the subsequent Groth16 proof generation, the verification logic of the access control circuit fully corresponds to the current on-chain policy and identity state, effectively improving the verification efficiency and security in cross-chain scenarios. S3.3: Obtain the private input dataset held locally by the access requester, including the temporary challenge value of the distributed identity private key signature, the plaintext of the attribute credential and its metadata, and combine it with the public input (DID identifier, policy hash, resource metadata) determined in step S2. Inject the private input into the R1CS variable assignment process, calculate a set of legal assignment vectors that satisfy all constraints, and use it as the prerequisite state for generating zero-knowledge proof. S3.4: Based on the valid assignment vector obtained in step S3.3 and the Proving Key generated in step S3.2, execute the Groth16 proof algorithm to generate a non-interactive proof, and output a short and publicly verifiable proof π; this proof π cryptographically promises that the private input satisfies the R1CS constraint system, while not revealing any plaintext information about attribute credentials or identity keys, forming a zero-knowledge assertion on identity validity and policy compliance; S3.5: The generated proof π is packaged with the common inputs (DID identifier, policy hash, resource metadata) into a compact proof package. It is then serialized using the ASN.1 structured encoding rules to generate a standardized binary format proof payload, which facilitates network transmission and gateway node parsing, ensuring high availability and interoperability even in low-bandwidth medical collaboration environments.

[0018] like Figure 3 As shown, step S4 involves submitting the zero-knowledge proof package generated in step S3 to the gateway node. The gateway calls the IAL smart contract to verify whether the DID is in an unrevoked state and synchronously obtains the latest policy version associated with the corresponding policy hash and its multisignature confirmation record from PCL, forming an on-chain state consistency verification result, which serves as the prerequisite input for subsequent trusted execution environment verification. Specifically, this includes: S4.1: Based on the compact proof package output in step S3, obtain the set of common input parameters contained therein, namely the Distributed Identity Identifier (DID), the policy hash corresponding to the resource to be accessed, and the resource metadata, as the index key for on-chain state query, so as to locate the corresponding on-chain evidence storage information in the Identity Anchor Chain (IAL) and the Policy Consensus Chain (PCL). S4.2: Execute the IAL smart contract call operation on the DID identifier, parse the registration timestamp, revocation status field and public key hash value of the DID on the identity anchor chain based on the lightweight DID protocol specification, calculate and output the DID validity assertion, that is, the boolean on-chain verification result of 'the DID is not revoked and is within the valid life cycle'; S4.3: Based on the policy hash as the unique index, initiate a read-only query request to the Policy Consensus Chain (PCL) to obtain the latest version snapshot of the corresponding fine-grained access policy template, including its structured policy description language (SPDL) encoded content, effective timestamp, reviser's digital signature and consensus signature set jointly signed by multiple institutions, forming the basis for verifying the integrity and authority of the policy. After obtaining the common input parameter set and DID validity assertion of steps S4.1 and S4.2, the on-chain read-only query method (parameters: policy hash index key, access mode=READ_ONLY, chain channel=PCL) is used to realize the targeted read operation of the policy consensus chain node; Furthermore, by using a structured strategy retrieval algorithm (parameters: index key = strategy hash, parsing mode = SPDL_FULL_PARSE), on-chain strategy template location based on hash value is achieved, and the encoded version number and data location reference of the current strategy object stored on the chain are obtained; Furthermore, by using the SPDL parsing and deserialization method (parameters: encoding set = on-chain SPDL binary stream, parsing stack depth control = 64 layers), the complete decoding of the policy object content is achieved, and a policy semantic representation result containing atomic predicate set, context constraint set and version metadata is generated; Furthermore, by using a digital signature verification method (parameters: signature algorithm = ECDSA, hash algorithm = SHA-256, public key set = reviser's public key set), the reviser's signature field in the policy object is cryptographically verified one by one, and a Boolean vector of signature validity is obtained. Furthermore, a multi-signature consensus verification algorithm (parameters: threshold ratio = 2 / 3, multi-signature set size = number of collaborating institutions) is used to perform threshold verification on the consensus signature set of the policy object and generate a consensus signature status code. By using policy integrity verification and authority confirmation processing, the decoding results and signature verification results of the previous step are converted into on-chain policy version snapshot data, which includes SPDL encoded content, effective timestamp, reviser signature status and multi-signature consensus status, to achieve an immutable authority verification basis for the latest policy under the policy hash index. For example, in a multi-institutional chronic disease data collaboration environment, the policy hash is set to "0xA12F...", and the on-chain read-only query method is used to locate the storage reference of the policy object at block height 58216. Through SPDL parsing and deserialization methods, the 2048-byte SPDL binary stream is decoded into 34 atomic predicates and 5 context constraints, including... , Conditions such as these are considered. During the digital signature verification process, a message digest is calculated based on the reviser's signature field. The ECDSA signature verification algorithm verifies the validity of the signature with public key ID "MEDAUTH-031" and returns a true value. The multi-signature consensus verification algorithm sets a threshold of 6 valid signatures when the current number of collaborating institutions is 9. If the on-chain signature set contains 7 verified signature records, it outputs the status code "CONSENSUS_OK". The final generated policy version snapshot data records the SPDL parsing content, the effective timestamp "2024-05-18T09:32:54Z", the reviser signature state vector {true,true,false,...}, and the multi-signature status code "CONSENSUS_OK", providing an authoritative basis for the subsequent policy consistency comparison in S4.4. S4.4: Perform a consistency comparison between the DID validity assertion returned by IAL and the latest policy version snapshot returned by PCL, verify whether the DID and policy hash in the current public input both point to a valid on-chain stored entity, and determine whether the multi-signature consensus state of the policy snapshot meets the preset threshold, generating a unified on-chain state consistency verification result. Based on the DID validity assertion output in step S4.2 and the latest policy version snapshot data obtained in step S4.3, a two-way cross-validation method (parameters: DID identifier string, public key hash value, policy hash, SPDL policy snapshot object) is adopted to realize the verification function of whether the DID in the public input matches the on-chain stored entity. Furthermore, by using a hash consistency comparison algorithm (parameters: public key hash on the IAL chain, public key hash in the request public input), the consistency of the public key hash value associated with the DID identifier is verified, and a boolean consistency result is obtained to confirm the validity of the identity-side trust anchor. Furthermore, the policy hash mapping verification method (parameters: PCL on-chain policy hash, public input policy hash) is used to verify whether the policy referenced by the access request is consistent with the currently effective policy version on the chain, and to generate a policy hash consistency judgment value to ensure that the trust anchor point on the permission side is correct. Furthermore, a multi-signature threshold detection algorithm (parameters: multi-signature set in the policy snapshot, preset threshold N) is adopted to determine whether the number of joint signatures from multiple institutions meets the threshold condition. By calculating the signature count and comparing the result with the threshold, a multi-signature status code is generated to reflect the integrity of the on-chain policy consensus. By using on-chain state fusion processing, the identity validity boolean assertion, the policy hash consistency judgment value, and the multi-signature status code are combined to form a unified on-chain state consistency verification record, thereby achieving the effect of synchronous consistency verification of identity trust anchor and permission trust anchor. For example, in a chronic disease collaborative management system, the input conditions are: DID identifier "did:example:abcd1234", public key hash recorded on the IAL chain is "h_pub_1a2b", public key hash in the request public input is also "h_pub_1a2b", policy hash is "hash_policy_XYZ", latest policy version snapshot hash on the PCL chain is "hash_policy_XYZ", multisignature set size is 5, and preset multisignature threshold N is 3. A hash consistency comparison algorithm is used to compare the two public key hashes, obtaining a consistency result of True. A policy hash mapping verification method is used to perform an equivalence check on the two policy hashes, with a result of True. A multisignature threshold detection algorithm is used to compare the signature set size of 5 with the threshold of 3, formally represented as...

[0019] If the comparison result is True, a multi-signature status code "PASS" is generated. Through on-chain state fusion processing, the identity consistency (True), policy consistency (True), and multi-signature status code "PASS" are combined to form a verification record {ID_OK=True,Policy_OK=True,MultiSig="PASS"}, and the on-chain state consistency verification result is output. This achieves the synchronous consistency determination of identity and permissions in cross-organizational access control, ensuring that the subsequent TEE verification stage can rely on a real and tamper-proof on-chain context. S4.5: Encapsulate the on-chain state consistency verification result into a structured verification credential, including the DID validity flag, policy version hash, multisignature confirmation status code, and timestamp of this query. This credential serves as the pre-trust anchor input for the Trusted Execution Environment (TEE) to perform zero-knowledge proof verification in subsequent step S5, ensuring that the off-chain verification logic relies on a real, synchronous, and tamper-proof on-chain context.

[0020] Step S5: The on-chain state consistency verification result obtained in step S4 and the zero-knowledge proof π are input together into the off-chain trusted execution environment (TEE). The proof verification algorithm is executed in an isolated security context to determine whether π passes verification and whether all common inputs match the current on-chain state. If successful, a verification success signal is output, and a one-time lightweight access token (LAT) generation instruction is triggered. Specifically, this includes: S5.1: Based on the on-chain state consistency verification results output in step S4, including the smart contract verification receipt of the DID not being revoked in the Identity Anchor Chain (IAL) and the latest version of the SPDL policy multisignature confirmation record pointed to by the corresponding policy hash in the Policy Consensus Chain (PCL), obtain the zero-knowledge proof π and its public input set (DID identifier, policy hash, resource metadata) as joint input parameters of the Trusted Execution Environment (TEE) to construct the joint verification premise of cross-chain state and cryptographic proof; S5.2: Load a pre-deployed zk-SNARK verification key VK within the secure enclave of the Trusted Execution Environment (TEE). This verification key is generated through a trusted setup ceremony based on the zero-knowledge proof circuit constructed in step S2 and pre-registered to the TEE firmware image through a secure channel. Use VK to perform a non-interactive verification algorithm on the input proof π, calculate the Boolean output value of the verification function Verify(VK, common input, π), and determine whether the proof is cryptographically valid. In a Trusted Execution Environment (TEE), a pre-deployed zk-SNARK verification key VK is loaded as input in a secure enclave, using a secure key loading protocol (parameters: key identifier VK_ID, secure channel type TLS, firmware image verification hash). This enables read-only secure loading of the verification key; Furthermore, through a key integrity verification algorithm (parameters: Signature Certificate This enables dual verification of the source and content of the verification key during the loading process, and obtains the key validity flag VK_valid. Furthermore, the non-interactive zero-knowledge proof verification algorithm Verify(parameters: VK, public input set, proof π) is invoked to determine the cryptographic compliance of the input proof π and generate a Boolean verification function output value. ; Furthermore, an arithmetic constraint mapping method is employed (parameter: R1CS mapping matrix). A finite field parameter q is used to achieve constraint consistency matching between the common input and the verification key, and to obtain the constraint satisfaction index. ; Boolean logic fusion processing method (parameter: , This transforms the verification output from the previous step into unified cryptographic validity judgment data, achieving a highly reliable verification effect of zero-knowledge proof in a TEE isolated environment. For example, in a multi-institutional access control scenario for chronic diseases, the TEE secure enclave loads a pre-registered VK via a TLS 1.3 secure channel. The key identifier is VK_HEALTH_ACCESS, and the firmware image verification hash is a 32-byte SHA-3 digest. After verification by the manufacturer's signing certificate, VK_valid is set to true. The public input set pub_inputs contains the DID identifier (64 bytes), the policy hash (32 bytes), and resource metadata (resource ID is 1205, timestamp is 1678903210). In the TEE, verification is performed using the Verify function of the Groth16 protocol.

[0021] in, This is a compact proof generated from step S3.4, where VK corresponds to the Verification Key associated with the Proving Key in step S3.2. Arithmetic constraints are mapped onto a finite field. Completed within the period, of which To find the prime order that matches R1CS, a mapping matrix is ​​used. Constraint satisfaction is obtained Boolean logic fusion processing:

[0022] A result of true indicates that π is cryptographically valid and all public inputs match the on-chain state. The final output is a TEE verification success signal, which triggers the LAT generation process. In this embodiment, the entire verification process takes less than 85 milliseconds, significantly improving the real-time performance and security of cross-institutional chronic disease data access. S5.3: Perform a logical AND operation on the Boolean output value of the verification function obtained in step S5.2 and the on-chain state consistency verification result provided in step S4. Based on the fusion judgment result, perform a consistency matching detection: if the verification function output is true and all public inputs are consistent with the latest state on the current IAL / PCL chain, then confirm that this access request has passed the double trust anchor verification and form a reliable verification success signal. The Boolean value of the verification function output in step S5.2 and the on-chain state consistency verification certificate encapsulated in step S4 are used together as joint judgment input to form a double trust anchored verification dataset. A Boolean logic fusion method (parameter: logical operator = AND) is used to perform joint matching calculations between the output of the verification function and the validity flag of the on-chain state, and the matching result is temporarily stored as a consistency matching Boolean value; Furthermore, through a field-level mapping comparison algorithm (parameters: the mapping key includes DID identifier and policy version hash), a field-by-field precise comparison between the common input set and the latest state snapshot on the chain is achieved to obtain the matching judgment vector for each input field; Furthermore, by using the vector consistency evaluation method (parameter: decision vector length = number of common input fields), a full consistency judgment on the matching results of all fields is achieved, and a consistency evaluation index matrix is ​​generated; Furthermore, through a joint decision aggregation algorithm (parameter: fusion basis = Boolean logic operation and consistency evaluation matrix), the comprehensive calculation of matching Boolean values ​​and consistency evaluation index matrix is ​​realized, and the final dual trust anchor verification Boolean signal is generated. By using dual trust anchoring verification logic, the verification function result of the previous step and the on-chain state consistency verification certificate are transformed into a reliable verification success signal, thereby achieving joint compliance confirmation of identity and policy in cross-domain access control. For example, in a multi-institutional collaborative scenario for chronic disease management, the DID validity flag in the on-chain state consistency verification credential is 1 (valid), the policy version hash is "hash1234", and the multi-signature confirmation status code is "OK". The verification function's boolean output value is true, the DID identifier in the common input set is "did:example:001", the policy hash is "hash1234", and the resource metadata contains "res001". Boolean logic fusion calculation yields a matching boolean value of true; in the field-level mapping comparison, both the DID identifier and the policy hash match the on-chain snapshot, generating a judgment vector [1,1]; the vector consistency evaluation shows that all fields match (length is 2, all are 1), and all elements of the consistency evaluation matrix are true. The joint judgment aggregation algorithm calculates the logical AND, and the final verification signal is true, triggering a one-time lightweight access token generation process. In this scenario, the access token generation delay does not exceed 10 milliseconds, providing stable cross-institutional access security performance; S5.4: In response to the verification success signal generated in step S5.3, start the generation process of one-time lightweight access token (LAT), call the encrypted random number generator to generate a globally unique encrypted random number nonce, and combine the resource ID, the hash of this proof and the expiration timestamp to construct the token payload, providing structured input for subsequent token encapsulation; S5.5: Perform encrypted encapsulation processing on the token payload generated in step S5.4. Use a symmetric encryption algorithm based on the national cryptographic standard SM4 or AES-256-GCM and encrypt the payload using the pre-shared gateway-service node key to generate an immutable and replay-resistant encrypted encapsulation, which serves as the core component of the final lightweight access token (LAT) and is used to distribute it to the target data service node to complete the permission transfer.

[0023] Step S6: In response to the successful verification signal in step S5, generate a one-time lightweight access token (LAT) containing the bound resource ID, the hash of this proof, and an encrypted random number. This token does not contain any plaintext information about the user's identity or attributes; it only carries an expiration timestamp and an encrypted encapsulation of the zk-SNARK output commitment, used to achieve permission transfer with minimal information disclosure. Specifically, this includes: S6.1: Based on the verification success signal output in step S5, trigger the generation process of the lightweight access token (LAT), obtain the resource identifier (Resource ID), the hash value H(π) of the zero-knowledge proof π and the timestamp T generated by the system clock in the current request context, as input parameters for token construction, to ensure the unique binding relationship between the token and a specific access request; S6.2: A high-entropy encrypted random number R is generated using a Secure Pseudo-Random Number Generator (CSPRNG) as the session key seed for the token. A fixed-length digest H(R) is obtained by performing a SHA-3 hash operation on R to enhance the token's resistance to replay attacks. H(R) is then used as one of the data sources for subsequent encrypted encapsulation, forming an unpredictable core factor for the token. S6.3: Based on the public output commitment of the zk-SNARK verification circuit, execute the HMAC-SHA256 algorithm to calculate the signature tag, so as to realize the state anchoring of the zk-SNARK output result, generate a cryptographic guarantee certificate for the proof of compliance, and serve as a token integrity protection mechanism; S6.4: Combine the resource ID, H(π), T, validity window ΔT and σ into plaintext header fields, use AES-GCM mode to encrypt and encapsulate H(R) and additional data (AD) to generate ciphertext, forming a token payload with authentication encryption attributes, ensuring the secure encapsulation of the session key without exposing the original attributes; S6.5: Construct a structured lightweight access token (LAT) by concatenating the plaintext header and ciphertext, and distribute it to downstream target data service nodes through an HTTPS secure channel. Simultaneously, the hash value of the access token is... Write to the local log buffer for subsequent auditing and revocation status synchronization, completing a closed loop of permission transfer with minimal information disclosure; Upon receiving the plaintext header field and ciphertext from step S6.4... After the dataset is processed, a structured concatenation algorithm is used (parameters: field sequence = {Resource ID, H(π), T, ΔT, σ, ...}). This enables the ordered combination of token structures and the standardization of field positions, thereby forming a lightweight access token instance with a consistent format and parsability. Furthermore, by using the HTTPS secure channel transmission method in the TLS1.3 protocol stack (parameters: certificate chain length ≥ 3, supporting forward secrecy suites), end-to-end encrypted transmission of the generated LAT structure is achieved, and a receipt confirmation acknowledgment from the downstream data service node verified by the MTA signature is obtained; Furthermore, by using a security event log writing algorithm (parameters: hash function type = SHA3-512, index key = H(LAT)), the access token fingerprint information is persisted to the local log buffer, and a linked list structured index record is generated, which is the dependent data for subsequent audit tracing and token revocation status quick retrieval functions. Furthermore, through a dual-buffered log synchronization strategy (parameters: buffer size ≥ 64KB, write latency threshold ≤ 10ms), the local log buffer content is periodically and batch-synchronized to the audit subsystem, and a Merkle root digest is generated to bind the integrity verification result of the current log batch. By using the above processing method, the plaintext header and encrypted payload of the previous step are double-solidified in the secure channel and log system, realizing a closed loop of secure distribution of access tokens and permission transfer under the condition of minimum information disclosure. For example, in the chronic disease management scenario of a multi-source medical data sharing platform, the plaintext header field generated by the gateway node is {Resource ID=RID_20240101, H(π)=sha256hash256bit, T=1704105600, ΔT=600 seconds, σ=hmacsha256tag}, and the ciphertext... After AES-256-GCM encryption, the length is 128 bytes. The token structure concatenation algorithm performs ordered combination according to the field sequence, generating a LAT structure of approximately 256 bytes. A TLS 1.3 secure channel is used, configured with RSA-4096 and ECDHE encryption suites, and identity verification is performed using a chain of certificates issued by the hospital's CA, ensuring that downstream community health nodes correctly receive and verify the LAT. During the log writing phase, the H(LAT) fingerprint is calculated using SHA3-512.

[0024] in, The data is a 256-byte structure, and the hash result is a 512-bit digest value. This digest value is written as an index key to the local log buffer linked list node and synchronized to the audit subsystem within 8ms using a double-buffering mechanism. The audit subsystem uses a Merkle tree to batch encapsulate every 64 log nodes, generates a root hash, and stores it on the consortium blockchain side channel, achieving verifiability and immutability of the entire token distribution process. Ultimately, under this configuration, the latency of cross-institutional chronic disease data access is significantly reduced, and the secure distribution and access control of access tokens are significantly improved.

[0025] Step S7: Distribute the Lightweight Access Token (LAT) generated in step S6 to the target data service node. The service node uses the locally cached IAL and PCL lightweight synchronization data to perform offline fast verification to determine whether the LAT is valid and whether its associated proof hash can be traced back to a valid on-chain policy and identity status through local mapping, thereby deciding whether to open the access channel for the corresponding chronic disease data resource. Specifically, this includes: S7.1: Based on the one-time lightweight access token (LAT) output in step S6, obtain the encrypted random number, bound resource ID, expiration timestamp, and encrypted encapsulation of the zk-SNARK output commitment in its encapsulation structure. Use the local pre-shared key to decrypt the encapsulation body to extract the verifiable public parameter set and obtain the resource identifier, validity period, and proof hash reference value in plaintext form. S7.2: Based on the proof hash reference value extracted in S7.1, and based on the locally maintained lightweight off-chain cache copy—the Identity Anchor Chain (IAL) snapshot index and the Policy Consensus Chain (PCL) version mapping table—a hash path matching query operation is performed to locate the DID identifier corresponding to the proof hash, the identity lifecycle state recorded in IAL, and the latest policy hash and multisignature effective time associated in PCL, and generate an on-chain state consistency view. S7.3: Based on the on-chain state consistency view generated in S7.2, and combined with the validity period range extracted in S7.1, a two-dimensional condition judgment is performed: First, the time verification function is called to compare the current system clock with the expiration timestamp in LAT to confirm that the token is within the valid time window; Second, the policy tracing engine is used to verify whether the SPDL policy version on which the proof hash depends is still the currently effective version of PCL and has not been revoked. If both conditions are met, a preliminary verification pass signal is output. S7.4: In response to the preliminary verification pass signal output by S7.3, trigger the access decision matrix update mechanism in the local security context, dynamically bind the resource ID of this LAT with the client IP fingerprint and device signature, and write it into the short-term memory access log buffer to generate access session record entries with time-series tags, which serve as the input basis for subsequent fine-grained behavior auditing and anomaly detection. S7.5: Based on the session context construction results completed in S7.4, execute the final access path control action: If all pre-verification conditions are met, send an authorization opening instruction to the data resource interface module to open a read-only access channel for the resource ID and limit the amount of data returned in a single session to no more than a preset threshold; otherwise, reject the request and report the abnormal event to the central monitoring node, so as to realize the control of secure data exposure surface based on the principle of least privilege and context awareness mechanism. The resource access binding matrix generated in step S7.4 is loaded into the session context construction result as the input dataset. A policy matching algorithm based on access control lists (ACL) (parameters: resource ID, client IP fingerprint, device feature code) is used to achieve accurate mapping of resource access rules and real-time loading of policy templates. Furthermore, a context-aware access verification algorithm (parameters: session binding matrix, validity window ΔT, policy hash) is used to jointly determine whether the access request meets the time constraint, identity constraint and policy constraint, and obtain the access authorization boolean result set. Furthermore, by calling the scheduling module via the interface (parameters: authorization boolean result set, resource ID), the authorization control of the data resource interface module is realized, and an authorization instruction set containing access mode (read-only), data return threshold upper limit and session tag is generated; Furthermore, by using a data return volume limiting algorithm (parameters: policy template setting threshold, resource data block length), dynamic limiting control of the amount of data that can be returned in a single session is achieved, and a limit parameter configuration file is generated for the interface module to load. The abnormal event reporting mechanism (parameters: triggered when the authorization boolean result set is negative, session binding matrix, failure reason code) transforms rejected request records into structured abnormal event packages and submits them to the central monitoring node to achieve centralized auditing and security situation awareness. Through the above access control links, the session context results of the previous step are transformed into resource access authorization instructions and abnormal event reporting data, so as to realize the control of the security exposure surface of chronic disease data resources based on the principle of least privilege and context adaptive mechanism. For example, in a remote cardiovascular health management platform for a certain region, the resource ID is set to "HBP-Followup-Data-001", the client IP fingerprint is "192.168.0.105", the device signature is a digest of "9A3F...C7" calculated using SHA-256, the validity window ΔT is 3600 seconds, the SPDL template corresponding to the policy hash specifies a daily access limit of 5 entries, and each data block is 512 bytes long. The access control list matching algorithm retrieves the read-only policy corresponding to this resource ID, the authorized boolean result set is true, the interface call scheduling module generates an authorization instruction set and sets the data return threshold. The upper limit value is sent to the data resource interface module through a data return volume limit algorithm. If the number of accesses exceeds 5 or the client device signature does not match the session context, the context-aware access verification algorithm outputs an authorization boolean result of no. The abnormal event reporting mechanism submits an event packet containing the resource ID, the failure reason code "AccessLimitExceeded", and a timestamp to the central monitoring node, achieving a significant improvement in the technical efficiency of detecting and responding to unauthorized access.

[0026] Step S8: Each time a policy update, DID revocation, or LAT issuance and usage operation occurs, an event log is automatically triggered and written to the immutable ledger of IAL or PCL. This supports cross-chain auditing and tracing based on DID identifiers or policy hashes, forming a fully verifiable trust chain covering the identity lifecycle, policy evolution path, and access behavior trajectory. Specifically, this includes: S8.1: Submit a transaction based on the strategy version on the Policy Consensus Chain (PCL), obtain a strategy change transaction package confirmed by joint signatures of multiple institutions, use the Structured Policy Description Language (SPDL) to perform syntax parsing and semantic verification on the strategy content, and generate a strategy change event record containing strategy hash, revision timestamp, effective version number and multi-signature evidence digest, as an immutable log input on the chain; S8.2: For DID registration, update or revocation operations that occur in the Identity Anchor Chain (IAL), extract their on-chain state transition transactions, use the state transition function defined in the lightweight DID protocol to calculate the DID lifecycle stage identifier, and combine the public key hash and timestamp to generate a unique identity event fingerprint, write it to the IAL local ledger and synchronize it to the cross-chain log aggregator to support global auditing; S8.3: Based on the one-time lightweight access token (LAT) generated by the gateway node after the zero-knowledge proof verification is passed, extract the resource ID, proof hash and encrypted random number from its binding information, construct the access authorization event data packet, and use the hash chain structure to forward associate it to the common input set of this zk-SNARK proof to form a permission issuance record that can be traced back to the original access request context. S8.4: Collect identity event fingerprints from IAL, policy change records from PCL, and LAT issuance events into a cross-chain audit log pool, perform data fusion processing based on timestamp sorting and cross-chain anchor alignment, generate a standardized audit event stream, and periodically write the root hash to the side channel verification channels of the two chains after batch packaging through a Merkle tree structure to enhance log integrity protection. S8.5: In response to external audit query requests, based on the DID identifier or policy hash as the retrieval key, locate the corresponding event trajectory chain in the cross-chain log index, call the on-chain stored multi-signature evidence digest, state transition fingerprint and Merkle proof to perform consistency verification, and output a full-link verifiable audit report containing the identity lifecycle graph, policy evolution path and access behavior sequence.

[0027] The present invention also provides an intelligent management system for the entire process of chronic disease data based on the fusion of multi-source medical data, which uses the above-mentioned intelligent management method for the entire process of chronic disease data based on the fusion of multi-source medical data to perform intelligent management of chronic disease data.

[0028] The technical solution of the present invention has been described above with reference to the preferred embodiments shown in the accompanying drawings. However, it will be readily understood by those skilled in the art that the scope of protection of the present invention is obviously not limited to these specific embodiments. Without departing from the principles of the present invention, those skilled in the art can make equivalent changes or substitutions to the relevant technical features, and the technical solutions after these changes or substitutions will all fall within the scope of protection of the present invention.

[0029] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and rules of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for intelligent management of chronic disease data throughout the entire process based on multi-source medical data fusion, characterized in that: Includes the following steps: S1: Initialize and deploy a dedicated consortium blockchain based on a multi-organizational collaborative environment. The dedicated consortium blockchain includes an identity anchoring chain and a policy consensus chain. S2: For access requesters from patients, doctors, community centers, or remote platforms, obtain their locally held distributed identity private key, attribute credential set, and policy hash corresponding to the chronic disease data resource to be accessed, and construct the input parameter set of the zero-knowledge proof circuit. S3: Compile the input parameter set of the zero-knowledge proof circuit into a non-interactive zero-knowledge proof that can be efficiently verified, and generate a compact proof package that includes the zero-knowledge proof and common inputs; S4: Submit the compact proof package to the gateway node. The gateway calls the identity anchoring chain smart contract to verify whether the distributed identity identifier of the access requester is in an unrevoked state, and synchronously obtains the latest policy version associated with the corresponding policy hash and its multi-signature confirmation record from the policy consensus chain to form an on-chain state consistency verification result. S5: Input the on-chain state consistency verification result and the zero-knowledge proof together into the off-chain trusted execution environment, execute the proof verification algorithm in the isolated security context, and if the zero-knowledge proof passes the verification and all public inputs match the current on-chain state, output the verification success signal and trigger the access token generation instruction. S6: Respond to the successful verification signal in step S5 and generate an access token.

2. The intelligent management method for the entire process of chronic disease data based on multi-source medical data fusion according to claim 1, characterized in that, Following step S6, the following is also included: S7: Distribute the access token to the target data service node. The service node uses the locally cached identity anchor chain and policy consensus chain to synchronize data and perform offline fast verification to determine whether the access token is valid and whether its associated proof hash can be traced back to the valid on-chain policy and identity status through the local mapping relationship, thereby deciding whether to open the access channel for the corresponding chronic disease data resource. S8: When a policy is updated, the distributed identity is revoked, or the access token is issued and used, an event log is automatically triggered to be written into the immutable ledger of the identity anchor chain or the policy consensus chain. This supports cross-chain auditing and tracing based on the distributed identity or the policy hash, forming a fully verifiable trust chain that covers the identity lifecycle, policy evolution path, and access behavior trajectory.

3. The intelligent management method for the entire process of chronic disease data based on multi-source medical data fusion according to claim 1, characterized in that, The identity anchoring chain uses a distributed identity protocol to record the distributed identity, registration timestamp, revocation status, and public key hash of each participant, and is only used to prove the existence and lifecycle status of the identity. The policy consensus chain is jointly operated and maintained by the collaborating institutions and is used to publish and version-manage fine-grained access policy templates encoded in a structured policy description language, and includes policy hash, effective time, reviser signature, and multi-signature consensus signature.

4. The intelligent management method for the entire process of chronic disease data based on multi-source medical data fusion according to claim 1, characterized in that, Step S3 specifically includes: Based on the input parameter set of the zero-knowledge proof circuit constructed in step S2, the arithmetic constraint relationship in the circuit is formally modeled using the R1CS representation method. The three conditions of distributed identity validity verification, attribute satisfaction judgment and context constraint check are transformed into a quadratic equation constraint system, and an R1CS constraint system is established. According to the R1CS constraint system, a trusted setup ceremony is performed to generate a public reference string using structured random numbers, including a Proving Key for proving the generation and a Verification Key for verification. Obtain the private input data held locally by the access requester, and combine it with the determined public input to inject the private input into the R1CS variable assignment process to calculate the valid assignment vector; Based on the valid assignment vector and the Proving Key, a non-interactive proof is generated, and a zero-knowledge proof is output. The zero-knowledge proof is packaged and combined with the common input into a compact proof package, and the compact proof package is serialized to generate a standardized binary format proof payload.

5. The intelligent management method for the entire process of chronic disease data based on multi-source medical data fusion according to claim 4, characterized in that, The common inputs include distributed identity identifiers, policy hashes corresponding to the resources to be accessed, and resource metadata.

6. The intelligent management method for the entire process of chronic disease data based on multi-source medical data fusion according to claim 1, characterized in that, Step S4 specifically includes: Based on the compact proof package output in step S3, obtain the distributed identity identifier, the policy hash corresponding to the resource to be accessed, and the resource metadata contained therein; The distributed identity identifier is invoked using an identity anchor chain smart contract. Based on the distributed identity protocol specification, the registration timestamp, revocation status field, and public key hash value of the distributed identity on the identity anchor chain are parsed, and the distributed identity validity assertion is calculated and output. Based on the policy hash as a unique index, a read-only query request is initiated to the policy consensus chain to obtain the latest version snapshot of the corresponding fine-grained access policy template; The distributed identity validity assertion is compared with the latest policy version snapshot to verify whether the distributed identity identifier and policy hash in the current public input both point to a valid on-chain stored entity, and to determine whether the multi-signature consensus state of the policy snapshot meets a preset threshold, thereby generating an on-chain state consistency verification result.

7. The intelligent management method for the entire process of chronic disease data based on multi-source medical data fusion according to claim 6, characterized in that, The latest version snapshot includes the structured policy description language encoded content of the fine-grained access policy template, the effective timestamp, the reviser's digital signature, and the consensus signature set jointly signed by multiple organizations.

8. The intelligent management method for the entire process of chronic disease data based on multi-source medical data fusion according to claim 1, characterized in that, Step S5 specifically includes: Based on the on-chain state consistency verification result output in step S4, obtain the zero-knowledge proof and its common input set, which serve as the joint input parameters of the trusted execution environment; Load a pre-deployed zk-SNARK verification key within the secure enclave of the trusted execution environment, and use the zk-SNARK verification key to perform a non-interactive verification algorithm on the zero-knowledge proof, calculating the Boolean output value of the verification function; The Boolean output value of the verification function is logically ANDed with the consistency verification result of the on-chain state. Based on the result of the fusion judgment, a consistency matching detection is performed, and a verification success signal is generated. In response to the verification success signal, the access token generation process is initiated, the encrypted random number generator is called to generate a globally unique encrypted random number, and the token payload is constructed by combining the resource ID, the current proof hash and the expiration timestamp. The token payload is encrypted and encapsulated using a symmetric encryption algorithm based on the Chinese national standard SM4 or AES-256-GCM, and a pre-shared gateway-service node key is used to encrypt the token payload, generating an immutable and replay-resistant encrypted encapsulation.

9. The intelligent management method for the entire process of chronic disease data based on multi-source medical data fusion according to claim 8, characterized in that, The consistency matching detection is as follows: if the verification function output is true and all public inputs are consistent with the latest state on the current IAL / PCL chain, then the access request is confirmed to have passed the double trust anchor verification, forming a reliable verification success signal.

10. A full-process intelligent management system for chronic disease data based on multi-source medical data fusion, characterized by: The method for intelligent management of chronic disease data throughout the entire process based on multi-source medical data fusion, as described in any one of claims 1-9, is used for intelligent management of chronic disease data throughout the entire process.

Images