Data verification method and system based on direct insurance payment service

Abstract

The invention provides a data verification method and system based on an insurance direct payment service, and belongs to the field of data verification. The problem of low data verification efficiency in the direct insurance payment service is solved; the method specifically comprises the following steps: acquiring medical data, a hash value of the medical data and a digital signature; deploying a permission type block chain network, and compiling and executing an intelligent contract; submitting the claim settlement application to a block chain, and judging whether the claim settlement application is credible; if yes, insured person information, medical data and claim settlement amount in the claim settlement application are extracted; if not, refusing claim settlement; designing a claim settlement payment model and a claim settlement judgment model, and judging whether the insured information, the medical data and the claim settlement amount are reasonable or not, and if yes, performing claim settlement; if not, re-determining the claim settlement amount; according to the invention, various information in the insurance claim settlement process is obtained, an information storage and verification system is established, and the data verification efficiency is improved.

Description

Technical Field

[0001] This invention relates to a data verification method and system for direct insurance payment business, and pertains to the field of data verification. Background Technology

[0002] Existing data verification methods for direct insurance payment transactions have the following shortcomings:

[0003] Insufficient data integrity verification: Some existing verification systems lack mandatory checks on required fields, leading to frequent instances of missing critical information. For example, in some regions' medical insurance settlements, patient identification information or treatment item codes may not be fully recorded, making subsequent auditing and tracing difficult. Secondly, existing systems do not adequately verify data correlation. Multiple data dimensions, such as insured person information, medical records, and expense details, have complex logical relationships. However, current verification methods often only perform simple format checks, neglecting the inherent connections between data, resulting in mismatches in claim items during the claims approval process.

[0004] Limitations of real-time verification: Some existing verification systems do not perform well in real-time verification. When some existing verification systems verify insurance application information in a batch processing mode, this mode results in a significant time lag between data verification and business occurrence, which can cause problems to be not detected and handled in a timely manner, thus greatly reducing the effectiveness of real-time verification.

[0005] Issues with verification accuracy: The rule engines of some existing verification methods lack sufficient intelligence, making it difficult to identify many complex fraudulent behaviors; current verification systems mainly rely on pre-set rules for judgment, lacking the ability to intelligently learn and identify abnormal patterns; in addition, the manual intervention in the verification process also affects the overall accuracy. This approach is not only inefficient, but also prone to introducing subjectivity and inconsistency, leading to an increased risk of incorrect judgments. Summary of the Invention

[0006] To address the shortcomings of existing technologies, the purpose of this invention is to provide a data verification method and system based on direct insurance payment business, aiming to solve the problem of low data verification efficiency in direct insurance payment business.

[0007] To achieve the above objectives, the present invention provides a data verification method based on direct insurance payment business, comprising:

[0008] Obtain structured medical data, calculate the hash value of each set of medical data, and then use the hospital's private key to digitally sign the hash value;

[0009] The project involves insurance companies, hospitals, third-party CA institutions, and regulatory agencies, who deploy a permissioned blockchain network to write and execute smart contracts for evidence storage and verification. Hospitals submit the hash value and digital signature of the medical data corresponding to their claim applications to the blockchain, which packages these data into blocks and synchronizes them to all peer nodes. Upon receiving the claim application, the insurance company determines its credibility. If credible, it extracts the insured's information, medical data, and claim amount; otherwise, it rejects the claim.

[0010] Generate a policy ID for each claim application; design the data input layer, core processing layer, and output layer of the claim payment model; obtain historical claim information and use random forest regression to build a claim judgment model; input the insured's information, medical data, and claim amount into the claim payment model to determine whether the insured's claim amount is reasonable. If reasonable, the claim is processed; if unreasonable, the medical data is substituted into the claim judgment model to redetermine the insured's claim amount.

[0011] Furthermore, the specific steps for deploying a permissioned blockchain network are as follows:

[0012] The insurance company acts as both a peer node and an orderer node.

[0013] Peer nodes: used to store ledgers, execute smart contracts, and initiate claims verification;

[0014] The ledger is the core data storage structure of the blockchain network, consisting of the blockchain and a state database, used to record the claims process and claims status of all claims.

[0015] The blockchain ledger is used to record the transaction history, claim time, and hash values ​​of the medical data involved in each claim.

[0016] The ledger's status database is used to store the latest current claim status for each claim.

[0017] Orderer node: Used to collect the latest claims information from each Peer node, and use a consensus algorithm to sort the received claims information according to the claims time; package the sorted claims information into blocks and broadcast them to all Peer nodes;

[0018] The hospital acts as a peer node;

[0019] A third-party CA institution acts as a CA node;

[0020] CA node: Used to issue digital certificates, which include: holder information, public key, validity period and CA signature;

[0021] Holder information: Used to record the organization name and the organization's node type;

[0022] Public key: Used to detect whether medical data provided by the hospital has been tampered with during the data upload process.

[0023] CA signature: Used to verify the authenticity of digital certificates;

[0024] CA nodes use a PKI system to manage the permissions of all participants in a permissioned blockchain network;

[0025] Regulatory agencies act as read-only nodes to audit on-chain data;

[0026] The audit process includes:

[0027] Based on hash comparison, the authenticity of on-chain data is verified to confirm that the hash value of medical data has not been tampered with during the claims process;

[0028] The legitimacy of the insured hospital's identity is verified based on the data signature.

[0029] Furthermore, the steps for deploying a permissioned blockchain network also include:

[0030] We track the processing cycle of each claim record using Fabric's GetHistoryForKey interface, initialize the GoModule and import the Fabric contract library, and write a smart contract:

[0031] Smart contracts include: smart contracts with evidence storage logic and smart contracts with verification logic;

[0032] Write a smart contract for evidence storage logic:

[0033] Define structured medical data objects and implement the basic framework of a permissioned blockchain network using the contractapi package in the Go language;

[0034] When a hospital submits data, the evidence storage logic smart contract executes the upload time, the validity period of the digital certificate and the CA signature, and the data and signature hash value are verified in a triple manner.

[0035] After passing the triple verification, the evidence storage logic smart contract calls the CreateCompositeKey method to generate a composite primary key for each structured medical data object; and calls the PutState method to write the composite primary key and the structured medical data object into the ledger of the corresponding peer node of the hospital and insurance company in JSON format.

[0036] Write a smart contract with verification logic:

[0037] The verification logic smart contract uses the GetStateByPartialCompositeKey method to query the insured's latest claim record and compares it with the hash value of the ledger and state database stored on the chain to ensure the consistency of on-chain data in the time dimension.

[0038] Furthermore, the specific steps for submitting a claim application to the blockchain are as follows:

[0039] Hospitals use Fabric SDK or API to call smart contracts and submit the hash value and digital signature of medical data to the blockchain; after the claim records are sorted by the Orderer node, they are packaged into blocks and synchronized to all Peer nodes to ensure that the data is immutable and complete the data on-chain and notarization.

[0040] When an insurance company receives a claim from a hospital, it queries the blockchain for the on-chain hash value corresponding to the claim record, recalculates the hash of the claim record submitted by the hospital, and compares it with the on-chain value; then it verifies the hospital's digital signature to determine whether the claim submitted by the hospital is credible.

[0041] If the claim is credible, the insured person's information, medical data, and claim amount will be retrieved from the claim application; if it is not credible, the claim will be rejected.

[0042] Furthermore, the specific steps for designing the data input layer are as follows:

[0043] Data input layer: used to receive claims, policy data, and medical service pricing;

[0044] Design the database table structure for the data input layer:

[0045] iPolicy Table: Stores policy ID, insured information, upload time, medical data, and claim amount;

[0046] Coverage Scope Table: Stores the medical services that are allowed to be insured;

[0047] Exclusion clauses: Store medical services that are not covered by insurance;

[0048] Medical service pricing table: Stores the price range for various medical services;

[0049] Claims Application Form: Stores and records the processing status and details of each claims application.

[0050] Furthermore, the specific steps for defining the core processing layer are as follows:

[0051] Core processing layer: used to define the verification engine, amount calculation engine, and decision engine;

[0052] Verification engine: Used to ensure that applications comply with policy terms and to block invalid or fraudulent requests;

[0053] Verification engine implementation steps:

[0054] The first step is to check the validity of the policy: by querying the policy database, the system verifies whether the policy status is ACTIVE, whether the upload time is within the coverage period, and whether the information of the insured uploaded by the hospital matches the information of the insured on the permissioned blockchain. If any condition fails, the process is terminated and the claim is rejected.

[0055] The second step is to verify the scope of coverage: link the scope of coverage table and the exclusion clause table; use a rule matching function to query the medical data corresponding to the claim application in the scope of coverage table for the medical services that are allowed and not allowed to be covered, and determine the allowed and excluded items in the claim application.

[0056] The third step is to summarize the results: output the policy status and coverage scope as Boolean values ​​and the reasons for refusing to pay out.

[0057] Furthermore, the specific steps for defining the amount calculation engine and the decision engine are as follows:

[0058] Claims calculation engine: Used to calculate the reasonableness of the claim amount in the engine's assessment;

[0059] Steps for implementing the amount calculation engine:

[0060] The first step is to check the policy limit: refer to the medical service pricing table; determine whether the claim amount for the allowed claim items is within the price range of the corresponding medical services in the medical service pricing table; if it exceeds the limit, mark the claim amount as unreasonable.

[0061] The second step is to match pricing rules: if the claim amount exceeds the range, the price range for unreasonable claims will be retrieved from the medical service pricing database; if the claim amount does not exceed the range, this step will be skipped.

[0062] The third step is to calculate the reasonable amount: the lower of the average of the price range of unreasonable claim amounts or the insurance company's predetermined payout amount is used as the suggested amount to ensure that it does not exceed the policy limit and complies with industry pricing standards.

[0063] Decision engine: Used to aggregate the processing results of the verification engine and the amount calculation engine;

[0064] Decision engine implementation steps:

[0065] The first step is process orchestration: the verification engine and the amount calculation engine are called in sequence. If the verification engine returns False, the process is terminated immediately and a rejection is returned.

[0066] The second step is the amount decision: if the verification passes but the amount is unreasonable, the suggested amount from the amount calculation engine will be used.

[0067] The third step is result generation: generate a structured decision, and output the structured decision including: status code, compensation amount, and detailed reason; enter the structured decision into the claim application form.

[0068] Furthermore, the definition of data matching verification with signature hash value is:

[0069] Let the hash value obtained by using the SHA-256 algorithm for medical data A be denoted as hash value A; use the hospital's private key to digitally sign hash value A to obtain signature A.

[0070] Suppose that the received hash value A corresponds to medical data B; calculate the hash value of medical data B, and denote it as hash value B;

[0071] The evidence storage logic smart contract obtains the hospital's private key and uses the ECDSA algorithm to check whether the hash value B matches the signature A;

[0072] Redefining the detection process of the ECDSA algorithm:

[0073] Using the NIST P-256 curve as an elliptic curve, take any point on the elliptic curve as the base point G, and the coordinates of the base point G are (x, y, y). (G) y (G) );

[0074] Let the order of the base point G be n; use the Schof or SEA algorithm to count the number of all valid points vE in the finite field; determine whether vE is a prime number; if vE is a prime number, then the value of n is vE; if vE is not a prime number, then the value of n is the largest prime factor of vE.

[0075] Let the hospital's private key be d, and let the hash value A be H. (A) Let the signature A be (r (A) s (A) Define the process for generating signature A:

[0076] Generate a random number k within the interval [1, (n-1)] using the RFC 6979 algorithm;

[0077] Calculate the elliptic curve point (x) corresponding to k. (k) y (k) );

[0078]

[0079] Calculate r (A) :r (A) =x (k) (mod(n)); where mod represents taking the modulus (i.e., r). (A) The value is x (k) (modulo n); if r(A) If the value of k is zero, then k is regenerated.

[0080] Calculate the modular inverse of k with respect to n, inv(k, n), and calculate s. (A) :

[0081]

[0082] Let the hash value B be H (B) Define the matching and verification process between hash value B and signature A.

[0083] Furthermore, the process of verifying the match between hash value B and signature A is as follows:

[0084] Calculate the public key Q corresponding to the private key d, where Q is expressed as (x (Q) y (Q) ):

[0085]

[0086] Calculate s (A) The modular inverse of n, inv(s) (A) (n);

[0087] Calculate the matching factor u (1) :u (1) =(inv(s) (A) ,n))×H (B) ;

[0088] Calculate the matching factor u (2) :u (2) =(inv(s) (A) ,n))×r (A) ;

[0089] Calculate the fitted elliptic curve point (x) corresponding to hash value B. (B) y (B) ):

[0090]

[0091] Judgment (x) (B) y (B) Is it on an elliptic curve?

[0092] If (x (B) y (B) If the curve lies on an elliptic curve, then determine r. (A) ≡x (B) Does (mod(n)) hold true? If r (A) ≡x (B) If (mod(n)) is true, then the hash value B matches the signature A; if r (A) ≡x (B)If (mod(n)) is not true, then the hash value B does not match the signature A;

[0093] If (x (B) y (B) If the hash value B is not on the elliptic curve, then the hash value B does not match the signature A.

[0094] The data verification system based on direct insurance payment business includes:

[0095] Data acquisition module: used to acquire structured medical data, calculate the hash value of each set of medical data, and then use the hospital's private key to digitally sign the hash value;

[0096] Storage and Verification Module: This module is used to deploy a permissioned blockchain network, write and execute smart contracts for storage and verification logic. Hospitals submit the hash value and digital signature of the medical data corresponding to their claim applications to the blockchain, which packages them into blocks and synchronizes them to all peer nodes. Upon receiving the hospital's claim application, the insurance company determines its credibility. If credible, it extracts the insured's information, medical data, and claim amount from the application; otherwise, it rejects the claim.

[0097] Claims Execution Module: This module generates a policy ID for each claim application; designs the data input layer, core processing layer, and output layer of the claims payment model; acquires historical claims information and uses random forest regression to build a claims judgment model; inputs the insured's information, medical data, and claim amount into the claims payment model to determine whether the insured's claim amount is reasonable. If reasonable, the claim is processed; if unreasonable, the medical data is substituted into the claims judgment model to redetermine the insured's claim amount.

[0098] Compared with the prior art, the beneficial effects of the present invention are:

[0099] Data Immutability: This invention constructs a permissioned blockchain network as the infrastructure for data storage and verification. In this scheme, insurance companies, hospitals, CA institutions, and regulatory agencies jointly participate in maintaining this network. Each participant acts as a node, storing a complete copy of the data. First, medical data is uploaded to the blockchain after hash calculation; any modification to the original data will result in a change in the hash value. Second, the blockchain data structure dictates that confirmed blocks cannot be modified; only new records can be appended. Finally, the network employs a consensus mechanism (such as Raft) to ensure data consistency across all nodes; single-point tampering will be rejected by other nodes. This mechanism fundamentally eliminates the possibility of malicious tampering of medical data during transmission and storage, establishing a solid foundation of data trust for direct insurance payment services.

[0100] Process digitization improves processing efficiency: This invention reconstructs the entire process through digitization: medical data is exported directly from the hospital's HIS system in a structured format (JSON / XML), encrypted and signed, and then stored on the blockchain. The insurance company automatically verifies the data through a smart contract. The entire process eliminates the need for manual transmission and paper materials. This digitized process brings significant efficiency improvements: on the one hand, data digitization reduces information entry and conversion steps; on the other hand, automated verification greatly shortens the review time and improves the service experience for insured individuals.

[0101] The invention utilizes smart contract technology to automate the execution of verification logic and ensure rule immutability. The "triple verification" mechanism (time verification, certificate verification, and hash matching verification) implemented in the contract automatically checks the legality of each claim application, eliminating errors or fraud that may result from human intervention. Furthermore, another security advantage of smart contracts is the isolation of their execution environment. On permissioned blockchain platforms such as Fabric, contracts run in protected containers, isolated from the underlying system and unaffected by external malicious code. The contract execution result is written to the ledger only after consensus confirmation from all relevant nodes, further enhancing the system's resistance to attacks. Attached Figure Description

[0102] Other features, objects, and advantages of the invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0103] Figure 1 This is a schematic diagram of the method of the present invention;

[0104] Figure 2 This is a schematic diagram of the system of the present invention;

[0105] Figure 3 This is a schematic diagram of a claims application broadcast according to the present invention. Detailed Implementation

[0106] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0107] Example 1

[0108] Please see Figure 1 Data verification methods based on direct insurance payment business include:

[0109] Step S1: Obtain structured medical data, calculate the hash value (HASH) of each set of medical data, and then use the hospital's private key to digitally sign the hash value;

[0110] Export structured medical data from the hospital's HIS system (Hospital Management Information System) in JSON or XML format;

[0111] Structured medical data: refers to medical information or electronic medical records that are organized and stored "according to a predefined standardized format";

[0112] The SHA-256 algorithm is used to calculate the hash value of each set of medical data, and then the hash value is digitally signed (such as ECDSA) using the hospital's private key; the private key is generated by the hospital's local HSM (Hardware Security Module) or Trusted Execution Environment (TEE).

[0113] Step S2: Deploy a permissioned blockchain network with insurance companies, hospitals, third-party CA (Certificate Authority) institutions, and regulatory agencies as participants (permissioned blockchain network). Write and execute smart contracts for evidence storage and verification logic. The hospital submits the hash value and digital signature of the medical data corresponding to the claim application to the blockchain, packages it into a block, and synchronizes it to all peer nodes. After receiving the hospital's claim application, the insurance company determines whether the claim application submitted by the hospital is credible. If credible, it extracts the insured person's information, medical data, and claim amount from the claim application; if not credible, it rejects the claim.

[0114] Please see Figure 3 The specific steps of step S2 are as follows:

[0115] Install Fabric binaries (such as fabric-samples), a CA server (fabric-ca), and supporting tools (configtxgen, peer, etc.); deploy a permissioned blockchain network with insurance companies, hospitals, third-party CA authorities (i.e., certificate authorities), and regulatory agencies as participants (in a permissioned blockchain network):

[0116] The insurance company acts as a Peer node and Orderer node (in a permissioned blockchain network);

[0117] Peer nodes: used to store ledgers, execute smart contracts, and initiate claims verification;

[0118] The ledger is the core data storage structure of the blockchain network, consisting of the blockchain and a state database, used to record the claims process and claims status of all claims.

[0119] (In this invention) the blockchain of the ledger: used to store the immutable historical record of all claims, linked into blocks in chronological order, that is, recording the transaction record of each claim, the claim time, and the hash value of the medical data involved in the claim;

[0120] The ledger's status database is used to store the latest claim status for each claim in key-value pairs, i.e., paid out or rejected.

[0121] Orderer nodes are used to collect the latest claims information from each Peer node (i.e., the latest blockchain data corresponding to each Peer node), and use a consensus algorithm (such as Raft) to sort the received claims information according to the claims time; the sorted claims information is packaged into blocks and broadcast to all Peer nodes;

[0122] The hospital acts as a peer node (in a permissioned blockchain network);

[0123] Third-party CA institutions act as CA nodes (in permissioned blockchain networks);

[0124] CA node: Used to issue digital certificates, which include: holder information, public key, validity period and CA signature;

[0125] Holder information: Used to record the institution's name and node type (e.g., institution name: hospital, node type: peer node);

[0126] Public key: Used to detect whether medical data provided by the hospital has been tampered with during the data upload process.

[0127] CA signature: Used to verify the authenticity of digital certificates;

[0128] CA nodes use the PKI (Public Key Infrastructure) system to manage the permissions of all participants in a permissioned blockchain network;

[0129] Regulatory bodies act as read-only nodes (in permissioned blockchain networks) to audit on-chain data (i.e., data stored in permissioned blockchain networks);

[0130] The audit process includes:

[0131] Based on hash comparison, the authenticity of on-chain data is verified to confirm that the hash value of medical data has not been tampered with during the claims process;

[0132] The legitimacy of the insured hospital's identity is verified based on the data signature;

[0133] The GetHistoryForKey interface of Fabric is used to obtain all versions of the key (i.e., the key-value pair in the state database of the ledger) for each Peer node, and to track the processing cycle of each claim record.

[0134] Write a smart contract for evidence storage and verification logic:

[0135] Initialize the Go module (go mod init) and import the Fabric contract library, then write the smart contract:

[0136] Smart contracts include: smart contracts with evidence storage logic and smart contracts with verification logic;

[0137] Write a smart contract for evidence storage logic:

[0138] Define structured medical data objects (including insured person information, hospital information, medical data, SHA-256 hash value of medical data, ECDSA signature, upload time and digital certificate), and implement the basic framework of a permissioned blockchain network through the contractapi package of Go language;

[0139] When a hospital submits data (i.e., structured medical data objects), the evidence storage logic smart contract executes the upload time (allowing a deviation of ±5 minutes to prevent replay attacks), and performs triple verification of the validity period of the digital certificate, CA signature, and the matching of the data with the signature hash value.

[0140] It should be noted that in the process of matching data hash values, data refers to the hash value obtained by using the SHA-256 algorithm on medical data, and signature refers to the digital signature of the hash value using a private key.

[0141] Suppose a hospital uses the SHA-256 algorithm to obtain the hash value of medical data A, denoted as hash value A; the hospital's private key is used to digitally sign hash value A to obtain signature A;

[0142] Suppose an insurance company receives medical data corresponding to hash value A, denoted as medical data B; the insurance company calculates the hash value of medical data B using the SHA-256 algorithm, denoted as hash value B;

[0143] The evidence storage logic smart contract obtains the hospital's private key and uses the ECDSA algorithm to check whether the hash value B matches the signature A;

[0144] Redefining the detection process of the ECDSA algorithm:

[0145] Using the NIST P-256 curve as an elliptic curve, the mathematical expression for the NIST P-256 curve is:

[0146]

[0147] Where b is the curve constant, b is a hexadecimal constant; p is the field prime (used to constrain the range of values ​​of the base point G), p is a large prime number of 256 bits;

[0148] Let any point on the elliptic curve be taken as the base point G, and the coordinates of the base point G be (x, y). (G) y(G) );

[0149] Let the order of the base point G be n; use the Schof or SEA algorithm to count the number vE of all valid points (i.e. points on the elliptic curve) in the finite field; determine whether vE is a prime number; if vE is a prime number, then the value of n is vE; if vE is not a prime number, then the value of n is the largest prime factor of vE.

[0150] Let the hospital's private key be d, and let the hash value A be H. (A) Let the signature A be (r (A) s (A) Define the process for generating signature A:

[0151] Generate a random number k within the interval [1, (n-1)] using the RFC 6979 algorithm;

[0152] Calculate the elliptic curve point (x) corresponding to k. (k) y (k) );

[0153]

[0154] Calculate r (A) :r (A) =x (k) (mod(n)); where mod represents taking the modulus (i.e., r). (A) The value is x (k) (modulo n); if r (A) If the value of k is zero, then k is regenerated.

[0155] Calculate the modular inverse of k with respect to n, inv(k, n), and calculate s. (A) :

[0156]

[0157] Let the hash value B be H (B) Define the process for matching and verifying the hash value B with the signature A:

[0158] Calculate the public key Q corresponding to the private key d, where Q is expressed as (x (Q) y (Q) ):

[0159]

[0160] Calculate s (A) The modular inverse of n, inv(s) (A) (n);

[0161] Calculate the matching factor u (1) :u (1) =(inv(s) (A),n))×H (B) ;

[0162] Calculate the matching factor u (2) :u (2) =(inv(s) (A) ,n))×r (A) ;

[0163] Calculate the fitted elliptic curve point (x) corresponding to hash value B. (B) y (B) ):

[0164]

[0165] Judgment (x) (B) y (B) Is it on an elliptic curve?

[0166] If (x (B) y (B) If the curve lies on an elliptic curve, then determine r. (A) ≡x (B) Does (mod(n)) hold true? If r (A) ≡x (B) If (mod(n)) is true, then the hash value B matches the signature A; if r (A) ≡x (B) If (mod(n)) is not true, then the hash value B does not match the signature A;

[0167] If (x (B) y (B) If the hash value B is not on the elliptic curve, then the hash value B does not match the signature A.

[0168] If a match is found, the triple verification passes; if no match is found, the triple verification fails.

[0169] After passing triple verification, the evidence storage logic smart contract calls the CreateCompositeKey method to generate a composite primary key for each structured medical data object (i.e., a combination of "insured person information + hospital information + SHA-256 hash value of medical data + upload time"). (The role of the composite component is to ensure data uniqueness.) Finally, the PutState method is called to write the composite primary key and the structured medical data object into the ledger of the corresponding peer nodes of the hospital and insurance company in JSON format.

[0170] Write a smart contract with verification logic:

[0171] The verification logic smart contract queries the insured's latest claim record using the GetStateByPartialCompositeKey method and compares the hash value with the hash value of the ledger and state database stored on the chain to ensure the consistency of on-chain data in the time dimension.

[0172] The verification logic smart contract integrates the rich query capabilities of the CouchDB database, and accelerates data retrieval speed through predefined indexes (such as a combined index based on insured person information and upload time);

[0173] Hospitals use Fabric SDK or API to call smart contracts and submit the hash value and digital signature of medical data to the blockchain; after the claim records are sorted by the Orderer node, they are packaged into blocks and synchronized to all Peer nodes to ensure that the data is immutable and complete the data on-chain and notarization.

[0174] When the insurance company receives a claim application from a hospital (i.e., the hospital sends a "structured medical data object" to the insurance company), it queries the blockchain for the on-chain hash value corresponding to the claim record, recalculates the hash of the claim record submitted by the hospital, and compares it with the on-chain value; then it verifies the hospital's digital signature to determine whether the claim application submitted by the hospital is credible.

[0175] If the claim is credible, the insured person's information, medical data, and claim amount will be retrieved from the claim application; if it is not credible, the claim will be rejected.

[0176] Step S3: Generate a policy ID for each claim application; design the data input layer, core processing layer (verification engine, amount calculation engine, decision engine), and output layer of the claim payment model; obtain historical claim information and use random forest regression to build a claim judgment model; input the insured's information, medical data, and claim amount into the claim payment model to determine whether the insured's claim amount is reasonable. If reasonable, proceed with the claim; if unreasonable, substitute the medical data into the claim judgment model to redetermine the insured's claim amount.

[0177] The specific steps of step S3 are as follows:

[0178] Data input layer: used to receive claims, policy data, and medical service pricing;

[0179] Design the database table structure for the data input layer:

[0180] insurance_policies(insurance_policies_table): Stores policy ID, insured information, upload time, medical data, and claim amount;

[0181] policy_coverages(coverages table): Stores the medical services that are allowed to be covered by insurance;

[0182] policy_exclusions (exclusion clauses table): Stores medical services that are not covered by insurance;

[0183] medical_service_pricing (Medical Service Pricing Table): Stores the price range for various medical services;

[0184] claim_requests(claims application form): Stores and records the processing status and claim details of each claim;

[0185] Core processing layer: used to define the verification engine, amount calculation engine, and decision engine;

[0186] Verification engine: Used to ensure that applications comply with policy terms and to block invalid or fraudulent requests;

[0187] Verification engine implementation steps:

[0188] The first step is to check the validity of the policy: by querying the policy database, the system verifies whether the policy status is "valid (i.e., ACTIVE)," whether the upload time is within the coverage period, and whether the information of the insured uploaded by the hospital matches the information of the insured on the permissioned blockchain. If any condition fails, the process is terminated and the claim is rejected.

[0189] The second step is to verify the scope of coverage: link the scope of coverage table and the exclusion clause table; use the rule matching function _matches_exclusion to query the scope of coverage table for the medical service items that are allowed and not allowed to be covered in the medical data corresponding to the claim application, and determine the items that are allowed to be claimed and not claimed in the claim application;

[0190] The third step is to summarize the results: integrate the policy status (i.e. whether it is "claim denied"), coverage (i.e. the items that are allowed to be claimed) and the insurance company's exclusion clauses, and output a Boolean value (True / False) and the reason for the claim denial (i.e. the items that are not claimed) for the decision engine to use;

[0191] Claims calculation engine: Used to calculate the reasonableness of the claim amount in the engine's assessment;

[0192] Steps for implementing the amount calculation engine:

[0193] The first step is to check the policy limit: refer to the medical service pricing table; determine whether the claim amount for the allowed claim items is within the price range of the corresponding medical services in the medical service pricing table; if it exceeds the limit, mark the claim amount as unreasonable.

[0194] The second step is to match pricing rules: if the claim amount exceeds the range, the price range for unreasonable claims will be retrieved from the medical service pricing database; if the claim amount does not exceed the range, this step will be skipped.

[0195] The third step is to calculate the reasonable amount: the lower of the average of the price range of unreasonable claim amounts or the insurance company's predetermined payout amount is used as the suggested amount to ensure that it does not exceed the policy limit and complies with industry pricing standards.

[0196] Decision engine: Used to aggregate the processing results of the verification engine and the amount calculation engine;

[0197] Decision engine implementation steps:

[0198] The first step is process orchestration: the verification engine and the amount calculation engine are called in sequence. If the verification engine returns False, the process is terminated immediately and a rejection is returned.

[0199] The second step is the amount decision: if the verification passes but the amount is unreasonable, the suggested amount from the amount calculation engine will be used.

[0200] The third step is result generation: generating structured decisions (i.e., approved claims, approved claims after adjustment, and rejected claims). The output of the structured decisions includes: status code (i.e., claimed, claims in progress, and rejected claims), compensation amount, and detailed reasons (i.e., items not covered and the adjusted suggested amount); the structured decisions are then entered into the claims application form.

[0201] Output layer: Used to output structured decisions and provide feedback on the claim amount or suggested amount in the claim application to the insurance company and the policyholder;

[0202] Historical claims information indicates: claims that have been processed or claims that have been rejected;

[0203] Extract medical data, hospital information, claim amount, and claim status (i.e., claimed or rejected) from historical claims information, and use random forest regression to build a claims judgment model;

[0204] Extract textual features (i.e., text vectors) of medical data and hospital information, numerical features of claim amount, and categorical features of claim status from historical claims information; perform one-hot encoding on categorical features and standardize numerical features to convert the raw data into a numerical matrix that can be processed by the random forest regression model, and use it as training data;

[0205] It should be noted that one-hot encoding is a preprocessing technique that converts categorical features (non-numerical labels) into binary vectors (0 / 1).

[0206] Random Forest Regressor or Gradient Boosting Tree (XGBoost) is chosen as the core algorithm for the claims assessment model, and the preprocessing and training steps are encapsulated through a pipeline:

[0207] The model uses the feature engineering tool ColumnTransformer to apply one-hot encoding and standardization to categorical and numerical features respectively; the number of decision trees in the random forest is set to 100, the depth of the decision trees is set to 10 (to prevent overfitting), and the mean squared error (MSE) is used as the node splitting criterion; during model training, the training data is divided into training and test sets in a 7:3 ratio, and the decision tree hyperparameters (such as min_samples_split, max_features) are optimized using cross-validation algorithms to obtain a stable random forest regression model; the stable random forest regression model trained with historical claims information is used as the claims judgment model;

[0208] The insured's information, medical data, and claim amount are input into the claim payment model to determine whether the claim amount is reasonable. If it is reasonable, the claim is processed; if it is unreasonable, the medical data is input into the claim judgment model to redetermine the insured's claim amount.

[0209] Example 2

[0210] Please see Figure 2 The data verification system based on direct insurance payment business includes:

[0211] Data acquisition module: used to acquire structured medical data, calculate the hash value of each set of medical data, and then use the hospital's private key to digitally sign the hash value;

[0212] Storage and Verification Module: This module is used to deploy a permissioned blockchain network with insurance companies, hospitals, third-party CA (Certificate Authority) institutions, and regulatory agencies as participants. It writes and executes smart contracts for storage and verification logic. Hospitals submit the hash value and digital signature of the medical data corresponding to their claim applications to the blockchain, which packages the data into blocks and synchronizes them to all peer nodes. Upon receiving the claim application, the insurance company determines its credibility. If credible, it extracts the insured's information, medical data, and claim amount; otherwise, it rejects the claim.

[0213] Claims Execution Module: This module generates a policy ID for each claim application; designs the data input layer, core processing layer (verification engine, amount calculation engine, decision engine), and output layer of the claims payment model; acquires historical claims information and uses random forest regression to build a claims judgment model; inputs the insured's information, medical data, and claim amount into the claims payment model to determine if the insured's claim amount is reasonable. If reasonable, the claim is processed; if unreasonable, the medical data is substituted into the claims judgment model to re-determine the insured's claim amount.

[0214] The above formulas are all dimensionless calculations. The formulas are derived from software simulations using a large amount of collected data to obtain the most recent real-world results. The preset parameters in the formulas are set by those skilled in the art according to the actual situation. For example, there are weighting coefficients and proportional coefficients. The values ​​set are to quantify each parameter to obtain a specific value, which is convenient for subsequent comparison. The values ​​of the weighting coefficients and proportional coefficients are only required to not affect the proportional relationship between the parameters and the quantified values.

[0215] Finally, it should be noted that the above-described embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A data verification method based on direct insurance payment business, characterized in that, The method includes: Obtain structured medical data, calculate the hash value of each set of medical data, and then use the hospital's private key to digitally sign the hash value; With insurance companies, hospitals, third-party CA institutions, and regulatory agencies as participants, a permissioned blockchain network is deployed. Smart contracts for evidence storage and verification logic are written and executed. The hash value and digital signature of the medical data corresponding to the claim application are submitted to the blockchain, packaged into blocks, and synchronized to all peer nodes to determine the credibility of the claim application. If credible, the insured person's information, medical data, and claim amount are extracted from the claim application; if not credible, the claim is rejected. Generate a policy ID for each claim application; design the data input layer, core processing layer, and output layer of the claim payment model; obtain historical claim information and use random forest regression to build a claim judgment model; input the insured's information, medical data, and claim amount into the claim payment model to determine whether the insured's claim amount is reasonable. If reasonable, the claim is processed; if unreasonable, the medical data is substituted into the claim judgment model to redetermine the insured's claim amount.

2. The data verification method based on direct insurance payment business according to claim 1, characterized in that, The specific steps for deploying a permissioned blockchain network are as follows: The insurance company acts as both a peer node and an orderer node. Peer nodes: used to store ledgers, execute smart contracts, and initiate claims verification; Ledger: The core data storage structure of a blockchain network, consisting of a blockchain and a state database, used to record the claims process and status of all claims; The blockchain ledger is used to record the transaction history, claim time, and hash values ​​of the medical data involved in each claim. The ledger's status database is used to store the latest current claim status for each claim. Orderer node: Used to collect the latest claims information from each Peer node and use a consensus algorithm to sort the received claims information according to the claims time; package the sorted claims information into blocks and broadcast them to all Peer nodes; The hospital acts as a peer node; A third-party CA institution acts as a CA node; CA node: Used to issue digital certificates, which include: holder information, public key, validity period and CA signature; Holder information: Used to record the organization name and the organization's node type; Public key: Used to detect whether medical data provided by the hospital has been tampered with during the data upload process. CA signature: Used to verify the authenticity of digital certificates; CA nodes use a PKI system to manage the permissions of all participants in a permissioned blockchain network; Regulatory agencies act as read-only nodes to audit on-chain data; The audit process includes: Based on hash comparison, the authenticity of on-chain data is verified to confirm that the hash value of medical data has not been tampered with during the claims process; The legitimacy of the insured hospital's identity is verified based on the data signature.

3. The data verification method based on direct insurance payment business according to claim 2, characterized in that, The steps for deploying a permissioned blockchain network also include: We track the processing cycle of each claim record using Fabric's GetHistoryForKey interface, initialize the GoModule and import the Fabric contract library, and write a smart contract: Smart contracts include: smart contracts with evidence storage logic and smart contracts with verification logic; Write a smart contract for evidence storage logic: Define structured medical data objects and implement the basic framework of a permissioned blockchain network using the contractapi package in the Go language; When a hospital submits data, the evidence storage logic smart contract executes the upload time, the validity period of the digital certificate and the CA signature, and the data and signature hash value are verified in a triple manner. After passing the triple verification, the evidence storage logic smart contract calls the CreateCompositeKey method to generate a composite primary key for each structured medical data object; and calls the PutState method to write the composite primary key and the structured medical data object into the ledger of the corresponding peer node of the hospital and insurance company in JSON format. Write a smart contract with verification logic: The verification logic smart contract uses the GetStateByPartialCompositeKey method to query the insured's latest claim record and compares it with the hash value of the ledger and state database stored on the chain to ensure the consistency of on-chain data in the time dimension.

4. The data verification method based on direct insurance payment business according to claim 1, characterized in that, The specific steps for submitting a claim to the blockchain are as follows: By calling the smart contract through the Fabric SDK or API, the hash value and digital signature of medical data are submitted to the blockchain; after the claim records are sorted by the Orderer node, they are packaged into blocks and synchronized to all Peer nodes to ensure that the data is immutable and complete the data on-chain and notarization. Upon receiving a claim application, the system queries the blockchain for the on-chain hash value corresponding to the claim record, recalculates the hash of the claim record submitted by the hospital, and compares it with the on-chain value; it also verifies the digital signature to determine whether the claim application submitted by the hospital is credible. If credible, extract the insured person's information, medical data, and claim amount from the claim application; If the claim is not credible, then the claim will be refused.

5. The data verification method based on direct insurance payment business according to claim 1, characterized in that, The specific steps for designing the data input layer are as follows: Data input layer: used to receive claims, policy data, and medical service pricing; Design the database table structure for the data input layer: iPolicy Table: Stores policy ID, insured information, upload time, medical data, and claim amount; Coverage Scope Table: Stores the medical services that are allowed to be insured; Exclusion clauses: Store medical services that are not covered by insurance; Medical service pricing table: Stores the price range for various medical services; Claims Application Form: Stores and records the processing status and details of each claims application.

6. The data verification method based on direct insurance payment business according to claim 1, characterized in that, The specific steps for defining the core processing layer are as follows: Core processing layer: used to define the verification engine, amount calculation engine, and decision engine; Verification engine: Used to ensure that applications comply with policy terms and to block invalid or fraudulent requests; Verification engine implementation steps: The first step is to check the validity of the policy: by querying the policy database, the system verifies whether the policy status is ACTIVE, whether the upload time is within the coverage period, and whether the information of the insured uploaded by the hospital matches the information of the insured on the permissioned blockchain. If any condition fails, the process is terminated and the claim is rejected. The second step is to verify the scope of coverage: link the scope of coverage table and the exclusion clause table; use a rule matching function to query the medical data corresponding to the claim application in the scope of coverage table for the medical services that are allowed and not allowed to be covered, and determine the allowed and excluded items in the claim application. The third step is to summarize the results: output the policy status and coverage scope as Boolean values ​​and the reasons for refusing to pay out.

7. The data verification method based on direct insurance payment business according to claim 6, characterized in that, The specific steps for defining the amount calculation engine and the decision engine are as follows: Claims calculation engine: Used to calculate the reasonableness of the claim amount in the engine's assessment; Steps for implementing the amount calculation engine: The first step is to check the policy limit: refer to the medical service pricing table; determine whether the claim amount for the allowed claim items is within the price range of the corresponding medical services in the medical service pricing table; if it exceeds the limit, mark the claim amount as unreasonable. The second step is to match pricing rules: if the claim amount exceeds the range, the price range for unreasonable claims will be retrieved from the medical service pricing database; if the claim amount does not exceed the range, this step will be skipped. The third step is to calculate the reasonable amount: the lower of the average of the price range of unreasonable claim amounts or the insurance company's predetermined payout amount is used as the suggested amount to ensure that it does not exceed the policy limit and complies with industry pricing standards. Decision engine: Used to aggregate the processing results of the verification engine and the amount calculation engine; Decision engine implementation steps: The first step is process orchestration: the verification engine and the amount calculation engine are called in sequence. If the verification engine returns False, the process is terminated immediately and a rejection is returned. The second step is the amount decision: if the verification passes but the amount is unreasonable, the suggested amount from the amount calculation engine will be used. The third step is result generation: generate a structured decision, and output the structured decision including: status code, compensation amount, and detailed reason; enter the structured decision into the claim application form.

8. The data verification method based on direct insurance payment business according to claim 3, characterized in that, The definition of data matching with signature hash value verification is: Let the hash value obtained by using the SHA-256 algorithm for medical data A be denoted as hash value A; use the hospital's private key to digitally sign hash value A to obtain signature A. Suppose that the received hash value A corresponds to medical data B; calculate the hash value of medical data B, and denote it as hash value B; The evidence storage logic smart contract obtains the hospital's private key and uses the ECDSA algorithm to check whether the hash value B matches the signature A; Redefining the detection process of the ECDSA algorithm: Using the NIST P-256 curve as an elliptic curve, take any point on the elliptic curve as the base point G, and the coordinates of the base point G are (x, y, y). (G) y (G) ); Let the order of the base point G be n; use the Schof or SEA algorithm to count the number of all valid points vE in the finite field; determine whether vE is a prime number; if vE is a prime number, then the value of n is vE; if vE is not a prime number, then the value of n is the largest prime factor of vE. Let the private key be d, and the hash value A be H. (A) Let the signature A be (r (A) s (A) Define the process for generating signature A: Generate a random number k within the interval [1, (n-1)] using the RFC 6979 algorithm; Calculate the elliptic curve point (x) corresponding to k. (k) y (k) ); Calculate r (A) :r (A) =x (k) (mod(n)); where mod represents modulo; if r (A) If the value of k is zero, then k is regenerated. Calculate the modular inverse of k with respect to n, inv(k, n), and calculate s. (A) : Let the hash value B be H (B) Define the matching and verification process between hash value B and signature A.

9. The data verification method based on direct insurance payment business according to claim 8, characterized in that, The process of matching and verifying hash value B with signature A is as follows: Calculate the public key Q corresponding to the private key d, where Q is expressed as (x (Q) y (Q) ): Calculate s (A) The modular inverse of n, inv(s) (A) (n); Calculate the matching factor u (1) :u (1) =(inv(s) (A) ,n))×H (B) ; Calculate the matching factor u (2) :u (2) =(inv(s) (A) ,n))×r (A) ; Calculate the fitted elliptic curve point (x) corresponding to hash value B. (B) y (B) ): Judgment (x) (B) y (B) Is it on an elliptic curve? If (x (B) y (B) If the curve lies on an elliptic curve, then determine r. (A) ≡x (B) If (mod(n)) is true, then hash value B matches signature A; if not, then hash value B does not match signature A. If (x (B) y (B) If the hash value B is not on the elliptic curve, then the hash value B does not match the signature A.

10. A data verification system based on direct insurance payment business, applicable to the data verification method based on direct insurance payment business as described in any one of claims 1-9, characterized in that, The verification system includes: Data acquisition module: used to acquire structured medical data, calculate the hash value of each set of medical data, and then use the hospital's private key to digitally sign the hash value; Storage and Verification Module: This module deploys a permissioned blockchain network, writes and executes smart contracts for storage and verification logic, submits the hash value and digital signature of the medical data corresponding to the claim application to the blockchain, packages it into blocks and synchronizes it to all peer nodes. Upon receiving a claim application, it determines its credibility; if credible, it extracts the insured's information, medical data, and claim amount from the claim application; if uncredible, it rejects the claim. Claims Execution Module: This module generates a policy ID for each claim application; designs the data input layer, core processing layer, and output layer of the claims payment model; acquires historical claims information and uses random forest regression to build a claims judgment model; inputs the insured's information, medical data, and claim amount into the claims payment model to determine whether the insured's claim amount is reasonable. If reasonable, the claim is processed; if unreasonable, the medical data is substituted into the claims judgment model to redetermine the insured's claim amount.

Images