Blockchain AI-powered methods and systems for privacy auditing of medical insurance fund data traceability

Abstract

This invention relates to the field of traceability auditing and privacy protection technology for medical insurance fund data, specifically to a blockchain-based AI-powered method and system for traceability and privacy auditing of medical insurance fund data. It achieves data encapsulation and self-auditing by defining Executable Audit Semantic Units (EASUs), constructs a two-layer blockchain architecture to handle transactions and solidify audit rules, and leverages federated learning, secure enclaves, and zero-knowledge proof technologies to complete triggered deep auditing while protecting data privacy. This method and system enable reliable traceability of audit data, dynamic rule evolution, and verifiable audit results, solving the problem of balancing privacy protection and audit effectiveness in medical insurance fund auditing, and improving audit accuracy and security.

Description

Technical Field

[0001] This invention relates to the field of traceability auditing and privacy protection technology for medical insurance fund data, and more specifically, to a blockchain AI-based method and system for traceability privacy auditing of medical insurance fund data. Background Technology

[0002] Auditing of medical insurance funds is a core technical area for ensuring fund security and standardizing medical service practices. Its core requirement is to achieve synergy between data traceability, audit compliance, and privacy protection. With the expansion of medical insurance data and the improvement of privacy protection regulations, traditional auditing models face severe challenges.

[0003] Existing technologies mostly adopt a centralized audit architecture, which centralizes data storage and processing, making them prone to privacy leaks. Audit rules are mostly statically preset, making it difficult to adapt to the dynamic changes in new violation patterns in medical insurance business. Furthermore, they rely on plaintext data for audit analysis, failing to ensure audit depth while protecting patient information and medical institutions' trade secrets. In addition, the verification of audit results depends on raw data, and the credibility of privacy protection verification mechanisms is insufficient, resulting in insufficient audit credibility.

[0004] To address the aforementioned shortcomings, this invention proposes a blockchain-based AI-powered method and system for tracing and auditing the privacy of medical insurance fund data. This system integrates blockchain, AI, and privacy computing technologies to create a unified auditing solution. Summary of the Invention

[0005] To address the shortcomings of existing technologies, the purpose of this invention is to provide a blockchain-based AI-powered method and system for tracing and auditing the privacy of medical insurance fund data.

[0006] To achieve the above objectives, the present invention provides the following technical solution:

[0007] The blockchain-based AI-powered privacy auditing method for medical insurance fund data traceability includes the following steps:

[0008] Step 1: Generation and self-auditing of executable audit semantic units: Define the executable audit semantic unit EASU as the basic carrier for data circulation and auditing. The EASU is a composite entity that encapsulates data, rules and verification basis. By defining the EASU in a structured manner and executing the generation and self-auditing process, the initial audit trace is formed.

[0009] Step 2: Transaction processing and rule emergence solidification based on a two-layer blockchain: Construct a functionally decoupled two-layer blockchain architecture, including a transaction layer chain and an audit consensus layer chain. Achieve collaborative work through a cross-chain communication protocol. Rely on federated learning algorithms to mine global strong correlation patterns under privacy protection. Solidify these patterns into audit rules through a consensus process and update them to the global rule base.

[0010] Step 3, Triggered Privacy Audit and Zero-Knowledge Proof Verification: When the self-audit detects anomalies or requires in-depth auditing, the target EASU set and corresponding AI audit model are retrieved, a zero-knowledge audit task is constructed and executed in a secure enclave network to obtain the audit results, generate a zero-knowledge proof and broadcast it to the blockchain for verification by all parties, ensuring privacy protection and audit effectiveness.

[0011] The present invention also provides a blockchain AI medical insurance fund data traceability privacy audit system, including an executable audit semantic unit generation and self-auditing module, a transaction processing and rule emergence solidification module based on a two-layer blockchain, and a trigger-based privacy audit and zero-knowledge proof verification module;

[0012] The executable audit semantic unit generation and self-audit module is used to structurally define EASU, extract key business data and perform encryption, signing, smart contract matching and model fingerprint association operations, encapsulate EASU and broadcast it to the blockchain, and at the same time support verification nodes to complete basic compliance self-audit and form audit traces by executing smart contracts.

[0013] The transaction processing and rule emergence and solidification module based on the two-layer blockchain is used to deploy the transaction layer chain and the audit consensus layer chain, realize cross-chain collaborative communication, run federated learning algorithms to mine global patterns, initiate the consensus process of rule hypothesis proposals, compile the passed rules into smart contract templates and update them to the entire network rule base simultaneously, and realize the dynamic evolution of audit rules.

[0014] The triggered privacy audit and zero-knowledge proof verification module is used to retrieve the target EASU and the corresponding AI audit model, construct a zero-knowledge audit task and send it to the secure enclave network, receive the audit results and zero-knowledge proofs generated by the enclave network, broadcast the proofs and public conclusion assertions to the blockchain, and provide a verification interface for all parties to complete the validity verification of the audit conclusions.

[0015] Furthermore, the structured definition of EASU in step one is a quadruple, which includes encrypted core business data ciphertext, verifiable credentials, attached smart contract, and AI audit model fingerprint. The verifiable credentials are generated by the data source node by signing the data digest and metadata with a private key. The attached smart contract encapsulates basic compliance rules, and the AI ​​audit model fingerprint points to a specific version of the registered AI audit model.

[0016] Furthermore, the EASU generation and self-audit execution process described in step one includes: extracting key data fields from the business system and encrypting them; calculating the digest of the encrypted data and metadata and signing it to generate a verifiable credential; instantiating and attaching a smart contract according to the transaction type and calling the rule template; associating the corresponding AI audit model fingerprint; encapsulating the EASU and broadcasting it to the blockchain; and having network verification nodes complete the basic compliance self-audit by executing the smart contract.

[0017] Furthermore, the transaction layer chain mentioned in step two focuses on the real-time processing and storage of front-end audit data, and adopts a high-throughput consensus mechanism; the audit consensus layer chain focuses on the consensus management of back-end core audit elements, and adopts a consensus mechanism that emphasizes finality and voting weight. The two types of consensus nodes are configured according to preset qualification requirements and perform corresponding duties.

[0018] Furthermore, the rule emergence and solidification process described in step two includes: the audit consensus layer releases rule mining tasks, each participating node performs federated learning training locally and generates zero-knowledge proofs, the aggregation node verifies the proofs and securely aggregates the parameters to obtain a global pattern recognition model, based on the model, strong correlation patterns are discovered and rule hypothesis proposals are formed, and after being reviewed and voted on by the consensus nodes, they are compiled into smart contract templates and updated to the global rule base.

[0019] Furthermore, the secure enclave network described in step three is jointly maintained by multiple trusted institution nodes, possesses an isolated and verifiable execution environment, ensures the integrity of the environment through a remote proof mechanism, employs a key management scheme to decrypt the model and process encrypted data within the enclave, and securely erases all plaintext intermediate data after the task is completed.

[0020] Furthermore, the zero-knowledge proof mentioned in step three is used to prove the validity of the AI ​​audit model, the correspondence of data encryption, the compliance of the calculation process, and that the audit results meet preset conditions. After the proof is generated, it is broadcast to the blockchain along with the public conclusion assertion. Verifiers can confirm the validity of the audit conclusion through a preset verification algorithm without obtaining sensitive information.

[0021] Compared with the prior art, the present invention has the following beneficial effects:

[0022] 1. Employing EASU's structured encapsulation and self-auditing mechanism, core business data is encrypted and bound to verifiable credentials, smart contracts, and model fingerprints, achieving "data as an auditor." Data flow is encrypted throughout and its source is traceable. Verification nodes complete basic compliance checks through smart contracts, solving the problems of passive data and easy privacy leakage in traditional auditing, while providing a reliable initial trace for subsequent audits, ensuring the authenticity and integrity of audit data;

[0023] 2. Based on a two-layer blockchain architecture and a federated learning rule emergence mechanism, the transaction layer chain ensures efficient storage of high-frequency data, the audit consensus layer chain realizes rule consensus solidification, and federated learning mines globally strong correlation patterns under privacy protection and transforms them into audit rules. This design solves the shortcomings of traditional static and rigid audit rules, realizes dynamic evolution of audit rules, improves the ability to identify new types of medical insurance violations, and balances audit efficiency and consensus security through cross-chain collaboration.

[0024] 3. Triggered auditing is conducted by combining secure enclaves with zero-knowledge proof technology. Secure enclaves provide an isolated execution environment to ensure computational security, while zero-knowledge proofs enable privacy-free verification of the compliance of the audit process and the validity of the results. This addresses the privacy risks of plaintext data processing in deep auditing while allowing audit conclusions to be verified by multiple parties without exposing sensitive information, thus balancing audit depth and privacy protection and enhancing audit credibility. Attached Figure Description

[0025] Figure 1 A flowchart for a blockchain-based AI-powered privacy audit method for tracing medical insurance fund data.

[0026] Figure 2 This is a flowchart of the steps for generating and self-auditing EASU in this invention;

[0027] Figure 3 A structural diagram of a blockchain-based AI-powered privacy audit system for tracing and tracing medical insurance fund data. Detailed Implementation

[0028] Example 1, refer to Figure 1 The blockchain AI-based privacy auditing method for tracing medical insurance fund data in this embodiment specifically includes the following steps:

[0029] Step 1: Generation and self-auditing of executable audit semantic units.

[0030] To address the pain points of passive data processing and external interpretation of meaning in traditional auditing, this method first defines the Executable Audit Semantic Unit (EASU) as the basic carrier for data flow and auditing. The following steps complete the generation and self-auditing of the EASU, laying the data foundation for subsequent auditing processes. This step atomically encapsulates data, rules, and verification criteria into a composite entity, rather than a simple data packet.

[0031] S11, EASU's structured definition:

[0032] An EASU can be formally defined as a quadruple:

[0033] ;

[0034] in:

[0035] This refers to the encrypted core business data after homomorphic or selective encryption, such as encrypted disease diagnosis codes and medical expenses.

[0036] VC stands for Verifiable Credential. It is a credential generated by a data source node (such as a medical institution) after digitally signing the data digest and its metadata (such as timestamps and business serial numbers) using its private key. It is used to prove the authenticity and integrity of the data source.

[0037] SC stands for Attached Smart Contract, which is a pre-compiled piece of code logic that can be executed by the blockchain virtual machine, encapsulating the logic for... One or more fundamental compliance rules representing the business. For example, a rule can be expressed as an assertion that ciphertext attributes satisfy a specific constraint relationship.

[0038] It is a cryptographic hash value that serves as the fingerprint of the associated AI audit model. It points to a unique identifier for a specific version of the AI ​​audit model that has been formally registered on the system audit consensus chain.

[0039] S12, EASU generation and self-audit execution steps:

[0040] When a medical insurance fund transaction (such as expense settlement) occurs, such as Figure 2 As shown, the generation module automatically performs the following steps:

[0041] S121. Extract key data fields from the business system. These key data fields include, but are not limited to, patient identification (encrypted), disease diagnosis code (ICD-10 standard), medical service item code, drug code, cost amount, and settlement time; apply homomorphic encryption algorithm. generate The homomorphic encryption algorithm specifically adopts the Paillier algorithm, with a key length of 2048 bits. The encryption key is uniformly generated and distributed by the auditing and supervision party through the key management center, and the key distribution adopts a PKI-based secure transmission protocol.

[0042] S122, Calculation The digest of the data and its related metadata is generated using the SHA-256 algorithm. The metadata specifically includes the data collection timestamp (UTC format), the business transaction number (using a combination of medical institution code, date, and sequence number), and the data source node identifier; the private key of the data source node is also used. The signature is generated using the ECDSA algorithm (elliptic curve selection: secp256r1). ;in," "" indicates data concatenation. The private key of the data source node is securely stored by the node itself, while the public key is pre-registered on the audit consensus layer chain.

[0043] S123. Based on the transaction type (e.g., outpatient settlement, inpatient settlement, drug procurement settlement, etc.), the corresponding rule template is retrieved from the rule base. The rule base adopts a distributed storage architecture, deployed on each node of the transaction layer chain and kept synchronized. The rule template is instantiated into a specific smart contract code SC. The smart contract is developed based on the Solidity language and adapted to the Ethereum Virtual Machine (EVM) execution environment. The SC is designed to handle encrypted data. (Or after specific agent re-encryption conversion) compliance verification is performed. Agent re-encryption uses the BS98 re-encryption algorithm to realize the ciphertext conversion from the regulator's public key to the smart contract's temporary public key.

[0044] S124. Obtain the hash value of the AI ​​audit model currently in effect for this type of transaction, which has been registered with the consensus master. Associated with the corresponding AI audit model fingerprint.

[0045] S125, encapsulates EASU and broadcasts it to the transaction layer blockchain network.

[0046] After completing the above steps, any network verification node that receives the EASU can automatically verify the basic compliance of transactions by executing its SC, realizing the self-auditing capability of Data-as-Auditor. The verification result, together with the EASU itself, is recorded on the blockchain to form an immutable audit trace, which will be used as the basis for subsequent blockchain consensus management and rule mining.

[0047] Step 2: Transaction processing and rule emergence solidification based on a two-layer blockchain.

[0048] Building upon the EASU generation and self-auditing completed in Step 1, this step constructs a two-layer blockchain network to collaboratively process high-frequency transactions and achieve deep consensus. It also leverages privacy computing to realize the emergent discovery and consensus solidification of audit rules, forming a dynamically evolving audit rule system that provides rule support for subsequent precise auditing.

[0049] S21. Construction and Functional Allocation of a Two-Layer Blockchain:

[0050] This method employs a functionally decoupled two-layer blockchain architecture. Through layered deployment, it achieves precise matching of core requirements across different audit stages, avoiding the conflict between throughput and consensus security inherent in a single blockchain network. This two-layer architecture is not a simple network overlay, but rather achieves efficient data and instruction collaboration through a pre-defined cross-chain communication protocol. The transaction layer focuses on real-time processing and notarization of front-end audit data, while the audit consensus layer focuses on consensus management of back-end core audit rules and models. The two networks work together organically to form a complete trusted audit infrastructure, specifically composed of the following two functionally defined blockchains:

[0051] Transaction Layer Chain: Employs a high-throughput consensus mechanism, specifically the optimized Practical Byzantine Fault Tolerance (PBFT) algorithm. By optimizing the view switching mechanism, consensus latency is reduced to less than 500ms. The block generation interval is set to 2 seconds, and each block can hold a maximum of 1000 EASU data. The number of network nodes is configured to be no less than 4 and an odd number. Node admission requires identity authentication through the audit consensus layer chain. It is dedicated to efficiently processing the generation, broadcasting, verification, and storage of EASU data. Its core function is to ensure low-latency and highly reliable evidence storage of audit traces.

[0052] Audit consensus layer chain: It adopts a consensus mechanism that emphasizes finality and voting weight, specifically the Delegated Proof-of-Stake (DPoS) algorithm. The consensus nodes are composed of representatives from medical insurance regulatory agencies, medical institutions, and third-party auditing institutions. This embodiment sets up a total of 21 consensus nodes, and the voting weight of the nodes is linked to the node qualification level. The block generation interval is set to 10 seconds, which is mainly used to store core audit elements such as AI audit model metadata and audit rule templates. It is specifically used to reach consensus on changes to two types of core audit elements: registration and version update of AI audit models (detailed in step 3), and proposal and solidification of audit rules.

[0053] S22, Rule Emergent Discovery Steps under Privacy Protection:

[0054] The rule-emergent engine initiates a global pattern mining process periodically or triggered by specific events. This process is conducted under strict privacy protection:

[0055] S221. The audit consensus layer publishes a rule mining task description T, which defines the type of pattern to be mined (such as drug-diagnosis association), but does not involve specific sensitive data.

[0056] S222. Each participating node i (medical institution) locally uses its own plaintext data (or authorized ciphertext) corresponding to historical EASU data to run the local training step in the federated learning algorithm. Specifically, the federated learning algorithm is the FedAvg algorithm for horizontal federated learning; the objective function... Specifically, it is set as the cross-entropy loss function, with the expression being: The aim is to optimize the model parameters θ so that they can identify strong association patterns in the data with a confidence level exceeding a threshold γ. For tags, To predict probabilities, γ is preset to 0.85 and can be adjusted through chain voting at the audit consensus layer; nodes only calculate local gradients or model parameter updates. The gradient was calculated using stochastic gradient descent (SGD) with a learning rate of 0.01.

[0057] S223, Node i generates a local update value. Zero-knowledge proof of its contribution to the overall model The zero-knowledge proof uses the Groth16 proof system, and the statement of the proof is " "It is based on the training data corresponding to task T and is honestly calculated through the FedAvg local training steps; the public reference string (CRS) required in the generation process is uniformly generated and distributed by the audit consensus layer chain before the task starts, and the generation algorithm adopts a verifiable random function (VRF); this proof is used to prove that its calculation is honestly executed for task T and does not use data outside the task description."

[0058] The core parameters of the Groth16 proof system are as follows:

[0059] Elliptic curve: bn254 (also known as alt_bn128) is selected. This is the most widely supported elliptic curve in the Ethereum and other blockchain ecosystems. It has good compatibility and computational efficiency and is suitable for the verification logic of Solidity smart contracts.

[0060] Number of circuit constraints: For auditing a single medical insurance transaction, the number of circuit constraints is controlled within the range of 10^4 to 10^5 to balance the proof generation speed and audit accuracy.

[0061] Trusted setup: The setup is completed using multi-party secure computation (MPC), with participants including the medical insurance bureau, the health commission, and a third-party auditing agency (no fewer than 5 parties). The threshold is set to 3 / 5, meaning that at least 3 parties must participate in the trusted setup to prevent single point of malicious activity.

[0062] Performance metrics: Proof generation time ≤ 500ms / piece, verification time ≤ 10ms / piece, meeting the requirements for real-time auditing of batch transactions.

[0063] S224, Node will Submitted to the audit consensus layer. The aggregation node (which may be a regulator) verifies all. Then, safely aggregate. Through multiple iterations, a global pattern recognition model was finally obtained. .

[0064] S23. Steps for proposing rule assumptions and solidifying consensus:

[0065] S231, Use Analyzing global data features (compiling and submitting encrypted digests locally on each node) reveals strong correlation patterns. For example, it identifies patterns such as "Under diagnosis A, the probability of using drug B is P, and..." ( (This is a preset high confidence threshold, such as 0.95).

[0066] S232. The system automatically encodes the pattern into a rule hypothesis proposal RH, which includes a pattern description, a confidence level P, and cryptographic statistical evidence supporting the pattern. And zero-knowledge proofs for verifying the validity of evidence. The proposal was submitted to the audit consensus layer.

[0067] S233, consensus nodes (medical insurance bureau, expert committee, etc.) review RH. Nodes can be based on... Verify the validity of evidence without decryption. After review, the node initiates a vote.

[0068] S234. If the vote passes, RH is officially adopted as the new auditing rule. This rule is automatically compiled into a standard smart contract code template. This will be updated in the entire EASU generation rule base. Afterwards, newly generated EASU rules will be embedded... Or its references, enable the dynamic, consensus-driven evolution of audit rules. The rule solidification process can be formally represented as:

[0069] ;

[0070] in, The consensus voting function is as follows: consensus nodes must vote on RH within 24 hours, and it is considered passed if more than 2 / 3 of the consensus nodes agree. The rule compilation function represents the code that uses a parser (such as ANTLR) to convert the natural language-described rules into Solidity smart contract code. The parser is built on an LL(1) grammar and supports automatic identification of condition judgments, threshold comparisons, and other logic in the rules and their conversion into corresponding contract code. The Global_Rule_Library is the global rule library, and its updates use a chain-style version control mechanism. After each update, the version number, update time, and consensus node signature are recorded. The solidified rules will be synchronized to each node for use in subsequent EASU rule template calls, realizing the dynamic evolution of audit rules.

[0071] Step 3: Triggered privacy audit and zero-knowledge proof verification.

[0072] When the EASU self-audit in Step 1 detects anomalies, or when regular in-depth audits are required, the triggered privacy audit process in this step is initiated. Based on the audit rules established in Step 2 and trusted data on the blockchain, this step performs complex AI analysis with end-to-end data encryption and produces verifiable audit conclusions using zero-knowledge proof technology, achieving a balance between privacy protection and audit effectiveness.

[0073] S31. Audit Task Generation and Security Enclave Execution Steps:

[0074] S311. The system retrieves the relevant target EASU set from the transaction layer chain based on the audit objectives (such as reviewing transactions in a specific time period or of a specific type). .

[0075] S312, according to each Model fingerprints Obtain the verifiable description and its ciphertext of the corresponding, consensus-registered AI audit model M from the audit consensus layer chain. .

[0076] S313. Construct a zero-knowledge auditing task ZKAT: .in It is a publicly available description of the audit logic, specifying how to use model M on the data. Perform analysis (such as fraud rating).

[0077] S314. Send ZKAT to a secure enclave network jointly maintained by multiple trusted institutional nodes (such as different regulators). The secure enclave is built using Intel SGX technology, and the enclave hardware must be certified by TCB (Trusted Computing Base). The operating system running in the enclave is a customized lightweight Linux system, which retains only the necessary computing and communication components. The enclave provides an isolated and verifiable execution environment. The integrity of the environment is guaranteed by a remote proof mechanism. The remote proof adopts an integrity report signed by ECDSA, and the verifier is the audit consensus layer node.

[0078] S315. Within the enclave, first use the private key shared by the regulator to decrypt. Model M is obtained, where the shared private key is managed using a threshold cryptography scheme (Shamir secret sharing), jointly held by three supervisory nodes, and requires private key fragmentation from at least two nodes to complete decryption; then, a temporary key dedicated to the enclave is used to... The process involves performing proxy re-encryption or homomorphic operations. If homomorphic operations are used, they are performed based on the additive homomorphic property of the Paillier algorithm. This enables M to perform calculations on the processed data. Specifically, the AI ​​audit model M is a classification model based on random forest, with 100 decision trees and each tree having a depth of no more than 10 levels. Finally, the audit result Result is obtained (such as a fraud label list or risk score, with the risk score ranging from 0 to 100 points, and a score ≥80 points indicating high risk).

[0079] The generation logic, specific format, and corresponding standards of Result are defined as follows:

[0080] I. Risk Score: A weighted fusion algorithm is used to generate the risk score. The core logic is to synthesize the output results of each decision tree in the random forest model, assign weights according to the classification accuracy of each decision tree (higher accuracy results in higher weights, with a total weight of 1), and obtain the final risk score through weighted summation. The score calculation expression is as follows: (in Let J be the weight of the j-th decision tree. (This is the original output score of the j-th decision tree). Specifically, it is an integer score from 0 to 100, with the following scoring criteria: 0-49 points for low risk, 50-79 points for medium risk, and 80-100 points for high risk.

[0081] II. Fraud Label List: Based on the types of medical insurance fraud behaviors specified in documents such as the "Guiding Opinions on Several Issues Concerning the Handling of Criminal Cases of Medical Insurance Fraud," standardized labels are generated in conjunction with the audit rules solidified in Step II. The specific form is a four-tuple list of "Unique Transaction Identifier - Fraud Label Type - Violation Basis - Confidence Level." The fraud label types include, but are not limited to, eight core types: fictitious medical service items, duplicate charges, overcharging, drug / consumable substitution, impersonation for medical treatment, and fraudulent hospitalization. Each label corresponds to a unique code (e.g., 01-Fictitious Medical Service Item). The violation basis is the audit rule ID and specific clause summary corresponding to the label. The confidence level is the model's judgment of the label's credibility (a decimal between 0 and 1, with a threshold of 0.8; only labels with a confidence level ≥ 0.8 are included in the list). For example, a fraud label list entry for a transaction can be represented as: EASU20260114001-01-Fictitious Medical Service Item-Rule2026003-Clause 3-0.92.

[0082] S32. Steps for generating and verifying zero-knowledge proofs on-chain:

[0083] Enclave networks do not directly output plaintext results that could potentially leak sensitive information; instead, they generate a zero-knowledge proof. This proof demonstrates that the following statement is true:

[0084] There exists a valid model M and a set of data. , so that:

[0085] 1. The hash of M equals (Right now (corresponding model)

[0086] 2. The encryption form is ;

[0087] 3. According to the publicly available logic Perform calculation The result obtained is Result;

[0088] 4. The Result meets the preset audit conclusion condition C (for example, there is a risk score greater than the threshold). ).

[0089] This proof The generation utilizes zero-knowledge proof systems such as zk-SNARK or zk-STARK. This embodiment employs the zk-STARK zero-knowledge proof system, with the core parameters as follows:

[0090] Finite field: selection It has a sufficiently large field size to ensure security, while also being compatible with efficient Fast Fourier Transform operations to improve proof generation efficiency.

[0091] Error correction code: Reed-Solomon code is selected, with the code rate set to 1 / 2 to balance proof size and fault tolerance;

[0092] Hash function: SHA-256 (or Keccak-256) is selected to maintain consistency with existing hash algorithms in the blockchain, which facilitates the on-chain storage and verification of audit results;

[0093] Performance metrics: proof generation time ≤ 10s / proof (acceptable in high-complexity scenarios), verification time ≤ 500ms / proof, proof size controlled at ≤ 10KB / proof for easy storage and transmission.

[0094] The proof process can be abstractly represented as:

[0095] ;

[0096] Among them, CRS is the system's common reference string, which is generated by the audit consensus layer chain through the multi-party secure computation (MPC) protocol. The participants are all consensus nodes, and the security of the generation process is verified through zero-knowledge proof.

[0097] This is a temporary decryption key used within the enclave. It is randomly generated by the enclave hardware, with a generation entropy value ≥ 256 bits. The key is only valid during the execution of the current zero-knowledge audit task and is completely erased through a hardware-level secure erasure mechanism after the task ends. The specific process is as follows:

[0098] Generation mechanism: The key is dynamically generated by a hardware random number generator (HRNG) within the enclave at the start of each zero-knowledge audit task, with an entropy value of no less than 256 bits, ensuring the unpredictability and uniqueness of the key. This key is only valid within the current enclave instance, is not exported outside the enclave, and is not reused across tasks.

[0099] Usage mechanism: Used for Perform proxy re-encryption or homomorphic decryption (selected based on the zero-knowledge auditing task requirements) to enable the AI ​​auditing model to perform computations on the decrypted (or transformed) data within the enclave. This generates zero-knowledge proofs. hour, As one of the private inputs (witnesses), it is used to prove:

[0100] The correctness of the data decryption or conversion process; the key used conforms to the task description. No unauthorized data or operations were introduced during the calculation process.

[0101] Destruction Mechanism: After the zero-knowledge audit task is completed, the enclave immediately initiates a secure erasure process.

[0102] Erase target: All intermediate plaintext data (including decrypted data) ,Model Audit Results wait);

[0103] Erasure standard: Complies with NISTSP800-88 erasure specification, employs multiple overwrite and memory zeroing mechanism.

[0104] After generating the proof, all plaintext intermediate data within the enclave (including) It is immediately and safely erased in a manner that conforms to NIST SP800-88 standards.

[0105] S321, Enclave Network will And publicly available conclusions and assertions (such as the number of fraudulent transaction tags > 0) are broadcast to the blockchain;

[0106] S322. Any validator (including the auditee) can utilize the verification algorithm. Input CRS and public parameters and To verify the validity of this proof, the verification formula is as follows:

[0107] ;

[0108] If IsValid returns true, all parties can be assured that the audit conclusion is correct and that the entire calculation process did not disclose any original data or model details, thus achieving verifiable confidential calculation.

[0109] Example 2, refer to Figure 3 The blockchain AI medical insurance fund data traceability privacy audit system in this embodiment includes an executable audit semantic unit generation and self-auditing module, a transaction processing and rule emergence solidification module based on a two-layer blockchain, and a trigger-based privacy audit and zero-knowledge proof verification module.

[0110] The Executable Audit Semantic Unit (EASU) generation and self-auditing module's core function is to generate Executable Audit Semantic Units (EASUs) that encapsulate data, rules, and verification criteria, and then perform self-auditing. By structurally defining the EASU four-tuple (encrypted core data, verifiable credentials, attached smart contract, and AI audit model fingerprint), it extracts key data from the business system and homomorphically encrypts it to generate trusted credentials for the data source, a compliance smart contract matching the business type, and associates it with the registered AI audit model. After encapsulation, it is broadcast to the blockchain. Simultaneously, it supports network verification nodes in automatically verifying basic compliance by executing the smart contract within the EASU, forming an immutable initial audit trace and providing a trusted data foundation for subsequent audits.

[0111] The transaction processing and rule emergence and solidification module based on a two-layer blockchain is responsible for constructing and coordinating the transaction layer chain and the audit consensus layer chain to achieve efficient transaction processing and dynamic evolution of audit rules. The transaction layer chain adopts an optimized PBFT consensus mechanism to handle the generation, broadcasting, verification, and storage of EASUs with low latency; the audit consensus layer chain manages the registration and updating of AI audit models and the consensus of audit rules through the DPoS consensus mechanism. Relying on federated learning algorithms, it mines globally strong correlation patterns under privacy protection, generates rule hypothesis proposals, and after review and voting by consensus nodes, the approved proposals are compiled into smart contract templates and updated to the global rule base, realizing the emergent discovery and consensus solidification of audit rules.

[0112] Triggered Privacy Audit and Zero-Knowledge Proof Verification Module: This module initiates precise auditing under privacy protection and outputs verifiable conclusions when anomalies are detected by self-auditing or when in-depth auditing is required. First, it retrieves the target EASU set, obtains the corresponding consensus-registered AI audit model, constructs a zero-knowledge audit task, and sends it to a secure enclave network. Within the enclave, the model is decrypted and encrypted data is processed. Audit results, such as risk scores and fraud label lists, are calculated using the AI ​​audit model. Subsequently, a zero-knowledge proof (proving that the audit process is compliant, the results are valid, and no sensitive information is leaked) is generated and broadcast to the blockchain for verification by all parties. This ensures both data privacy and the credibility and traceability of the audit conclusions.

[0113] Through the detailed description of the above embodiments, the blockchain AI-based medical insurance fund data traceability privacy auditing method and system of the present invention achieves atomic encapsulation and self-auditing of audit data through EASU, completes transaction processing and dynamic rule evolution based on a two-layer blockchain architecture, and achieves in-depth auditing and verifiable conclusion output under privacy protection by leveraging secure enclaves and zero-knowledge proof technology. Its core advantage lies in the deep integration of blockchain's trusted evidence storage, AI's intelligent analysis, and the security protection of privacy computing, effectively resolving the contradiction between privacy protection and audit effectiveness in traditional medical insurance auditing. It achieves a closed-loop process for data traceability, rule evolution, privacy protection, and audit verification, providing efficient, reliable, and compliant technical support for the secure supervision of medical insurance funds.

[0114] The above formulas are all dimensionless calculations, and the preset parameters in the formulas should be set by those skilled in the art according to the actual situation.

[0115] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0116] It should be understood that in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0117] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0118] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0119] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0120] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

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

Claims

1. A blockchain-based AI-powered method for privacy auditing of medical insurance fund data traceability, characterized in that: The method flow is as follows: Step 1: Generation and self-auditing of executable audit semantic units: Define the executable audit semantic unit EASU as the basic carrier for data circulation and auditing. The EASU is a composite entity that encapsulates data, rules and verification basis. By defining the EASU in a structured manner and executing the generation and self-auditing process, the initial audit trace is formed. The EASU is formally defined as a quadruple: ； in, This indicates the encrypted core business data after homomorphic or selective encryption processing. VC stands for Verifiable Credential, which is a credential generated by a data source node using its private key to digitally sign the data digest and its metadata. SC stands for Attached Smart Contract, which is a pre-compiled piece of code logic that can be executed by the blockchain virtual machine, encapsulating the logic for... One or more basic compliance rules for the business it represents; It is a cryptographic hash value that serves as the associated AI audit model fingerprint, pointing to a unique identifier of a specific version of the AI ​​audit model that has been formally registered on the system audit consensus chain; The EASU generation and self-audit execution process includes: extracting key data fields from the business system and encrypting them, calculating the digest of the encrypted data and metadata and signing it to generate a verifiable credential, instantiating and attaching a smart contract according to the transaction type and calling the rule template, associating the corresponding AI audit model fingerprint, encapsulating the EASU and broadcasting it to the blockchain, and the network verification node completing the basic compliance self-audit by executing the smart contract. Step 2: Transaction processing and rule emergence solidification based on a two-layer blockchain: Construct a functionally decoupled two-layer blockchain architecture, including a transaction layer chain and an audit consensus layer chain. Achieve collaborative work through a cross-chain communication protocol. Rely on federated learning algorithms to mine global strong correlation patterns under privacy protection. Solidify these patterns into audit rules through a consensus process and update them to the global rule base. The transaction layer chain focuses on the real-time processing and storage of front-end audit data, and adopts a high-throughput consensus mechanism; the audit consensus layer chain focuses on the consensus management of back-end core audit elements, and adopts a consensus mechanism that emphasizes finality and voting weight. The two types of consensus nodes are configured according to preset qualification requirements and perform corresponding responsibilities. Step 3, Triggered Privacy Audit and Zero-Knowledge Proof Verification: When the self-audit detects anomalies or requires in-depth auditing, the target EASU set and corresponding AI audit model are retrieved, a zero-knowledge audit task is constructed and executed in a secure enclave network to obtain the audit results, generate a zero-knowledge proof and broadcast it to the blockchain for verification by all parties, ensuring privacy protection and audit effectiveness.

2. The blockchain AI-based privacy auditing method for medical insurance fund data traceability according to claim 1, characterized in that, The structured definition of EASU in step one is a quadruple, which includes encrypted core business data ciphertext, verifiable credentials, attached smart contract, and AI audit model fingerprint. The verifiable credentials are generated by the data source node by signing the data digest and metadata with a private key. The attached smart contract encapsulates basic compliance rules, and the AI ​​audit model fingerprint points to a specific version of the registered AI audit model.

3. The blockchain AI-based privacy auditing method for medical insurance fund data traceability according to claim 1, characterized in that, The rule emergence and solidification process described in step two includes: the audit consensus layer releases rule mining tasks, each participating node performs federated learning training locally and generates zero-knowledge proofs, the aggregation node verifies the proofs and securely aggregates the parameters to obtain a global pattern recognition model, based on this model, strong correlation patterns are discovered and rule hypothesis proposals are formed, and after being reviewed and voted on by the consensus nodes, they are compiled into smart contract templates and updated to the global rule base.

4. The blockchain AI-based privacy auditing method for medical insurance fund data traceability according to claim 1, characterized in that, The secure enclave network described in step three is jointly maintained by multiple trusted institution nodes, possesses an isolated and verifiable execution environment, ensures the integrity of the environment through a remote proof mechanism, employs a key management scheme to decrypt the model and process encrypted data within the enclave, and securely erases all plaintext intermediate data after the task is completed.

5. The blockchain AI-based privacy auditing method for medical insurance fund data traceability according to claim 1, characterized in that, The zero-knowledge proof mentioned in step three is used to prove the validity of the AI ​​audit model, the correspondence of data encryption, the compliance of the calculation process, and that the audit results meet the preset conditions. After the proof is generated, it is broadcast to the blockchain along with the public conclusion assertion.

6. A blockchain-based AI-powered privacy auditing system for medical insurance fund data traceability, used to implement the blockchain-based AI-powered privacy auditing method for medical insurance fund data traceability as described in any one of claims 1-5, characterized in that, The system includes a module for generating and self-auditing executable audit semantic units, a module for transaction processing and rule emergence solidification based on a two-layer blockchain, and a module for trigger-based privacy auditing and zero-knowledge proof verification. The executable audit semantic unit generation and self-audit module is used to structurally define EASU, extract key business data and perform encryption, signing, smart contract matching and model fingerprint association operations, encapsulate EASU and broadcast it to the blockchain, and at the same time support verification nodes to complete basic compliance self-audit and form audit traces by executing smart contracts. The transaction processing and rule emergence and solidification module based on the two-layer blockchain is used to deploy the transaction layer chain and the audit consensus layer chain, realize cross-chain collaborative communication, run federated learning algorithms to mine global patterns, initiate the consensus process of rule hypothesis proposals, compile the passed rules into smart contract templates and update them to the entire network rule base simultaneously, and realize the dynamic evolution of audit rules. The triggered privacy audit and zero-knowledge proof verification module is used to retrieve the target EASU and the corresponding AI audit model, construct a zero-knowledge audit task and send it to the secure enclave network, receive the audit results and zero-knowledge proofs generated by the enclave network, broadcast the proofs and public conclusion assertions to the blockchain, and provide a verification interface for all parties to complete the validity verification of the audit conclusions.

Images