A commercial insurance medical data blockchain storage and risk control decision-making system

Abstract

This invention discloses a commercial insurance medical data blockchain storage and risk control decision-making system, relating to the fields of commercial medical insurance and computer technology. It includes: a diagnostic evolution sidechain for recording the iterative process of medical diagnosis for a target case; a main chain including a reimbursement basis contract; a cross-chain anchoring protocol connecting the diagnostic evolution sidechain and the main chain, used to write the consensus result of the corresponding diagnostic evolution sidechain to the main chain when the diagnostic evolution sidechain reaches a consensus on the diagnosis of the target case; a claims processing module for determining the benchmark reimbursement standard on the main chain based on the reimbursement basis contract and the consensus result; and a risk control decision-making module, based on a machine learning module, using data from the diagnostic evolution sidechain as input, outputting a risk control identifier for the target case and adjustments to the benchmark reimbursement. This invention solves the contradiction that medical diagnoses iterate with evidence, while blockchain records are immutable, leading to misuse of early diagnoses or inconsistencies in reporting in claims and risk control.

Description

Technical Field

[0001] This invention relates to the fields of commercial medical insurance and computer technology, and more specifically, to a commercial insurance medical data blockchain storage and risk control decision-making system. Background Technology

[0002] In commercial insurance medical data blockchain storage and risk control decision-making systems, the conflict of iterative updates in medical diagnoses is a highly specialized and easily overlooked pain point. It stems from the inherent tension between the business model of gradually accumulating medical evidence and the immutability of blockchain. Medical diagnoses are often not one-time conclusions but are constantly updated with examinations, tests, and clinical observations. At the initial consultation stage, doctors can only form a preliminary judgment based on limited symptoms, physical examinations, and basic tests. As new evidence emerges, such as biopsies, imaging, genetic testing, or consultation opinions, the diagnosis may be revised, refined, or even contradictory. Diagnostic updates are not random but gradually approach the true situation chronologically. Subsequent evidence is usually more complete and authoritative; therefore, the diagnostic records for the same case naturally possess evolutionary attributes.

[0003] The immutability of blockchain makes it difficult to overwrite or replace written data. Subsequent diagnostic updates can only exist as appended records, which can introduce hidden biases into risk control and claims calculations. When assessing long-term policy risk, risk control systems need to review the patient's past history. If there is a lack of mechanisms to handle diagnostic evolution, early uncertain diagnoses may be incorrectly cited, or diagnoses from different stages may be simply added together, leading to an overestimation of risk and consequently biases in premium adjustments, renewal decisions, or risk stratification. Disputes can also easily arise in claims review. For example, in cases where diagnoses have been reversed, if the evidence and chronological order of the diagnostic updates cannot be clearly explained, insurance companies may question the reasonableness of the reversal, and policyholders may feel that the claims conclusions are inconsistent.

[0004] This issue is often overlooked because blockchain is more commonly used to solidify relatively static factual records such as transactions and certificates, assuming that data uploaded to the chain already possesses determinism. However, medical data is characterized by long-term evolution and uncertainty. At the same time, medical privacy compliance requirements minimize the exposure of sensitive information, and insurance policy cycles can span many years, necessitating periodic risk reassessments. This amplifies the long-term impact of diagnostic updates. During periods of frequent diagnostic adjustments, deviations in the risk control system may occur in batches, thereby affecting claims efficiency and the stability of risk management. Summary of the Invention

[0005] The technical problem to be solved by the present invention is to provide a blockchain-based evidence storage and risk control decision-making system for commercial insurance medical data, so as to solve the problems mentioned in the background art.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: A commercial insurance medical data blockchain storage and risk control decision-making system includes a diagnostic evolution sidechain, a main chain, a cross-chain anchoring protocol, a claims processing module, and a risk control decision-making module; The diagnostic evolution sidechain is used to record the iterative process of medical diagnosis for a target case; The main chain includes a compensation basis contract; The cross-chain anchoring protocol connects the diagnostic evolution sidechain and the main chain, and is used to write the consensus result of the corresponding diagnostic evolution sidechain into the main chain when the diagnostic evolution sidechain reaches a consensus on the diagnosis of the target case. The claims processing module is used to determine the benchmark compensation standard on the main chain based on the compensation basis contract and consensus results; The risk control decision module, based on the machine learning module, takes the data from the diagnostic evolution sidechain as input and outputs a risk control identifier for the target case and an adjustment to the benchmark payout.

[0007] Preferably, the data recorded by the diagnostic evolution sidechain needle includes one or more of the following: Each diagnostic iteration includes the submitter's identifier and digital signature, submission timestamp, candidate diagnosis code and its version number, diagnosis change reason information, summary of examination and test results supporting the candidate diagnosis and its hash fingerprint, summary of treatment / medication record and its hash fingerprint, evidence hash and reference address of image or report file, and consensus voting records and results associated with the candidate diagnosis.

[0008] Preferably, the diagnostic evolution sidechain's consensus criteria for diagnosing the target case identifier include: The candidate diagnoses submitted by each participant are written into the consensus record pool, and the candidate diagnoses are normalized and mapped to obtain a unified diagnostic code. Within the preset consensus window, count the number of valid signatures corresponding to each candidate diagnosis, where valid signatures are those of participants that meet the permission verification and whose signatures are verifiable. When the number of valid signatures for a candidate diagnosis reaches a preset threshold and the candidate diagnosis is not rejected by a veto record submitted by a participant with higher authority within the preset consensus window, it is determined that the corresponding candidate diagnosis has reached a consensus and a consensus result is generated.

[0009] Preferably, the consensus result written to the main chain includes one or more of the following: The target case identifier, the consensus diagnosis code, the corresponding diagnosis version number, the consensus formation timestamp, the summary of the valid signature set participating in the consensus, the consensus voting count result, and the hash digest of the evidence record set used to support the diagnosis in the diagnosis evolution sidechain.

[0010] Preferably, the process by which the claims processing module determines the benchmark compensation standard includes: Extract the coverage clauses, scope of coverage items, deductible conditions, coverage ratio and coverage limit corresponding to the consensus diagnosis from the compensation basis contract; The consensus diagnosis and associated treatment / medication / examination items corresponding to the consensus results are matched with the scope of reimbursement items to determine the set of reimbursable items; According to the deductible conditions, the expenses in the set of reimbursable items are subject to deductible processing, and the benchmark reimbursement standard for the target case is calculated based on the reimbursement ratio and the reimbursement limit.

[0011] Preferably, the claims processing module includes a clause parsing submodule. The clause parsing submodule uses a large language model to perform semantic parsing on the natural language clauses of the compensation basis contract, outputting the protection liability clause identifier corresponding to the consensus diagnosis, the item tag set of the compensation item scope, and the structured constraint expression of the deductible conditions. Based on the structured constraint expression, the module completes the matching of the consensus diagnosis and its associated treatment / medication / examination items with the compensation item scope.

[0012] Preferably, the cross-chain anchoring protocol includes: generating an anchoring proof on the diagnostic evolution sidechain, wherein the anchoring proof includes the sidechain block hash corresponding to the consensus result, the hash digest of the consensus result, and a digest of the valid signature set participating in the consensus; The anchoring proof is encapsulated into the main chain transaction payload by a cross-chain relay node or cross-chain gateway and submitted to the main chain; On the main chain side, the anchor proof is verified based on preset side chain verification parameters. The verification includes a matching verification of the side chain block hash and the hash digest of the consensus result, as well as a signature verifiability verification of the valid signature set digest. When the verification passes, the main chain writes the anchoring proof into the main chain and generates an anchoring index that can be used to backtrack and locate the consensus result of the diagnostic evolution sidechain.

[0013] Preferably, the machine learning module includes a risk control identifier prediction model and a payout adjustment prediction model. The risk control identifier prediction model is used to output the risk control identifier of the target case, and the payout adjustment prediction model is used to output the adjustment value of the benchmark payout. The training process of the machine learning module includes: Obtain iterative diagnostic records of historical cases on the diagnostic evolution sidechain, the corresponding main chain consensus results, and claims processing results, and construct training samples based on cases; The verified risk control conclusions in the historical claims processing results are used as the first label, and the adjustment range of the benchmark compensation standard in the historical claims processing results is used as the second label. A supervised learning classification model is trained based on the sample input and the first label to obtain a risk control identification prediction model, and a supervised learning regression model is trained based on the sample input and the second label to obtain a compensation adjustment prediction model. Among them, the consensus result of the main chain is used as the sample screening condition to remove case samples that have not reached a consensus or whose consensus has been rolled back.

[0014] Preferably, the risk control indicators include any one or more of the following: abnormal diagnosis change indicator, inconsistent diagnosis across institutions indicator, abnormal treatment sequence indicator, mismatch between diagnosis and medication indicator, abnormal expense item indicator, suspected duplicate medical treatment or duplicate reimbursement indicator, and missing key evidence indicator.

[0015] Preferably, the machine learning module employs a sequence neural network model, which uses a Transformer-based encoder structure to encode the diagnostic iteration sequence of the target case on the diagnostic evolution sidechain, outputs the risk control identifier through a fully connected classification head, and outputs the adjustment value of the benchmark payout through a regression head.

[0016] The advantage of this invention over existing technologies lies in its ability to address the contradiction between the iterative and even reversible nature of medical diagnosis and the immutable nature of blockchain records, which are difficult to overwrite once written. This invention establishes a data and decision-making closed loop that preserves a complete history while providing stable conclusions applicable to business decisions. The diagnostic evolution sidechain records the diagnostic iteration process of the target case chronologically, ensuring that uncertain conclusions in the initial diagnosis stage and subsequent corrections and refinements based on new evidence are traceable, preventing early diagnoses from being mistaken for final facts and solidified into a single conclusion. By writing the consensus result to the main chain after reaching a consensus on the diagnosis of the target case on the sidechain, an auditable and verifiable index of definitive diagnostic conclusions is formed on the main chain. This preserves the complete process of diagnostic evolution and provides a unified basis for claims calculation and risk control decisions, thereby reducing the risk of inconsistencies and disputes arising from diagnostic updates.

[0017] In claims processing, this invention shifts the determination of benchmark compensation standards from relying on decentralized records and manual interpretation to consistent calculation based on the compensation basis contract in the main chain and the consensus results of the side chain. This avoids errors in the application of liability clauses caused by relying solely on early diagnoses, and also avoids repeated verification due to the lack of a reliable version boundary when diagnoses are reversed. Furthermore, the submitter's identifier and digital signature, timestamp, diagnosis code version, reason for diagnosis change, summary of examination, testing and treatment medication, and its hash fingerprint recorded in the side chain establish a verifiable link between each diagnosis update and its supporting evidence. This allows for the proof of the chronological relationship and completeness of evidence for diagnosis changes without exposing the original sensitive content, thereby improving the explainability and accountability of claims review.

[0018] Regarding cross-chain consistency, this invention binds the sidechain consensus result with the sidechain block hash, consensus result hash digest, and valid signature set digest through anchored proof and main chain side verification mechanism. After being written to the main chain, it forms an anchored index that can be traced back and located, so that the key conclusions in the diagnostic evolution process have stable cross-chain verifiable credentials, reducing the risk of inconsistent conclusions caused by sidechain rollback, replay, or relay tampering, and strengthening the trust boundary in a multi-party collaborative environment.

[0019] In terms of risk control decision-making, this invention uses diagnostic evolution sidechain data as input, and the machine learning module outputs risk control identifiers and provides adjustment suggestions for benchmark compensation. This allows risk control to move beyond relying solely on a single point-in-time diagnostic snapshot, instead utilizing the change trajectory and evidence chain integrity information during the diagnostic evolution process to identify hidden risks. By using the main chain consensus results as the training sample selection criterion, cases that have not reached consensus or have been rolled back are eliminated, reducing the interference of uncertain diagnoses and noisy data on the model and improving the stability and consistency of risk control output. The risk control identifiers cover situations such as abnormal diagnostic changes, inconsistent cross-institutional diagnoses, abnormal treatment order, mismatch between diagnosis and medication, abnormal expense items, suspected duplicate medical treatment or duplicate reimbursement, and missing key evidence. This enables the system to promptly alert to abnormal evolution patterns and form traceable evidence, even when diagnostic iteration is inevitable. This reduces the hidden biases caused by the immutability of blockchain and improves the reliability of long-term policy risk assessment and claims risk control. Attached Figure Description

[0020] Figure 1 This is a diagram of the overall system architecture of the present invention; Figure 2 This is a diagnostic evolution and consensus logic diagram of the present invention; Figure 3 This is a flowchart of the risk control decision-making and claims processing of the present invention. Detailed Implementation

[0021] The specific embodiments of the present invention will now be described with reference to the accompanying drawings.

[0022] This invention provides a commercial insurance medical data blockchain storage and risk control decision-making system, such as... Figure 1 As shown, the system includes a diagnostic evolution sidechain, a main chain, a cross-chain anchoring protocol, a claims processing module, and a risk control decision-making module. The combination of a sidechain and a main chain is used because medical diagnosis is characterized by continuous iteration; early diagnoses may be corrected or even overturned by subsequent evidence, and the immutability of blockchain requires the preservation of historical records. The sidechain is used to carry high-frequency diagnostic evolution records, ensuring that diagnostic updates can be continuously added and traced; the main chain is used to carry contracts and the final consensus index directly related to claims calculation, facilitating the formation of stable claims evidence and audit vouchers.

[0023] Diagnostic evolution sidechains are used to record the iterative process of medical diagnosis for a target case. For example... Figure 2 As shown, a target case will generate multiple candidate diagnoses during the treatment period. These candidate diagnoses can originate from hospital information systems, testing institution systems, pharmacy systems, or third-party auditing systems. To ensure verifiability, the sidechain generates an iteration record for each diagnostic iteration and writes it to a block. This iteration record includes at least the submitter's identifier and digital signature, submission timestamp, candidate diagnosis code and its version number, reason for diagnosis change information, and an evidence summary related to the candidate diagnosis. The evidence summary preferably uses a hash fingerprint method for storage, specifically including summaries of examination and testing results and their hash fingerprints, summaries of treatment or medication records and their hash fingerprints, and the storage hash and reference address of images or reports. The reason for using hash fingerprints is that medical data has privacy requirements; directly storing the original text on the blockchain increases the risk of leakage and also leads to excessive on-chain load. Using a summary method can prove that the original evidence has not been tampered with, while retaining the original data off-chain to meet compliance and storage efficiency requirements.

[0024] In one embodiment, the submitter identifier uses a certificate identifier from a medical institution or node, and the digital signature is implemented using a national cryptographic algorithm or an elliptic curve algorithm. The signature content at least covers the candidate diagnosis code, version number, timestamp, and evidence digest. The submission timestamp can be generated by the sidechain node according to the block time, or it can be generated by a trusted time source and then confirmed by the submitter's signature. The candidate diagnosis code can use a standard disease coding system or a diagnosis mapping code from the insurance side. To ensure cross-institutional consistency, the sidechain can perform a normalized mapping on the candidate diagnosis before writing, mapping different expressions to a unified diagnosis code.

[0025] The logic of reaching a consensus on diagnosis is as follows: Figure 2As shown, the system writes the candidate diagnoses submitted by each participant into a consensus record pool. This pool can be implemented as a consensus queue on a sidechain or a hybrid structure of off-chain cache and on-chain index. Within a preset consensus window, the system counts the number of valid signatures corresponding to each candidate diagnose. A valid signature refers to a participant's signature that meets permission verification and is verifiable. Permission verification can be achieved through role whitelists, certificate chain verification, or node admission policies. A preset threshold is used to determine whether consensus has been formed; its value can range from 3. In another embodiment, if there are many participants, a threshold representing the proportion of valid participants can be used, for example, a value of 0.8 to 0.9, to avoid misjudgments caused by a small number of signatures forming consensus. In another embodiment, the threshold can also be linked to the case amount or risk level; higher thresholds are used for high-value cases, and lower thresholds are used for low-value cases, thus balancing security and processing efficiency.

[0026] To prevent improper consensus, this invention introduces a veto record mechanism. When the number of valid signatures for a candidate diagnosis reaches a preset threshold and the candidate diagnosis is not rejected by a veto record submitted by a participant with higher authority within the preset consensus window, consensus is determined for the corresponding candidate diagnosis, and a consensus result is generated. The participant with higher authority can be a quality control node, an audit node, or an insurance audit node. The veto record is also written to the sidechain using a signature method and at least references the version number of the rejected candidate diagnosis and a summary of the reason for rejection. The purpose of the veto record is to handle erroneous consensus caused by a few abnormal nodes or collusion, making the final consensus more in line with the prudent requirements of medical and insurance practices.

[0027] The main chain includes a compensation basis contract. This contract, which can be implemented using smart contracts or verifiable contract data structures, describes the coverage terms, scope of compensation items, deductibles, compensation ratios, and compensation caps. Placing the contract on the main chain ensures the stability and auditability of the compensation calculation basis, preventing changes in historical case calculations due to subsequent modifications to the terms. In one embodiment, the compensation basis contract includes a terms version number and an effective period. The claims processing module selects the corresponding version to perform calculations based on the occurrence time of the target case, ensuring that the current period's calculations can still be applied when terms are adjusted across years.

[0028] A cross-chain anchoring protocol connects the diagnostic evolution sidechain and the main chain. When the diagnostic evolution sidechain reaches a consensus on the diagnosis of a target case, the corresponding consensus result is written to the main chain. The purpose of cross-chain anchoring is to separate the high-frequency evolution process of the sidechain from the stable conclusion index of the main chain. The sidechain can retain its complete evolution history, while the main chain only carries key consensus conclusions and verifiable indexes, thereby reducing the load on the main chain and improving verification efficiency.

[0029] In one embodiment, the cross-chain anchoring protocol generates an anchoring proof on the diagnostic evolution sidechain. The anchoring proof includes at least the sidechain block hash corresponding to the consensus result, the hash digest of the consensus result, and a digest of the valid signature set of participants in the consensus. The sidechain block hash is used to bind the immutable block location where the consensus result is located, the hash digest of the consensus result is used to bind the content of the consensus result, and the digest of the valid signature set is used to prove which valid participants formed the consensus. The digest of the valid signature set can be implemented using the Merkle root of the signature list or by concatenating signatures and then hashing them. The cross-chain relay node or cross-chain gateway encapsulates the anchoring proof into the main chain transaction payload and submits it to the main chain. The relay node can be operated by an insurance institution or jointly by multiple parties. To avoid single points of failure, multiple relay nodes can be allowed to submit in parallel, and the main chain side accepts only one valid anchor write according to the idempotency rule.

[0030] The main chain verifies the anchor proof based on pre-defined sidechain verification parameters. These parameters may include the sidechain validator's public key set, threshold signature parameters, sidechain chain ID, and hash algorithm identifier. Verification includes matching the sidechain block hash with the consensus result hash digest, and verifying the signature verifiability of the valid signature set digest. Matching can be verified by checking the transaction root or event root recorded in the sidechain block header to confirm the consensus result is indeed in that block, or by using the threshold signature of the consensus result hash by the sidechain validator. Signature verifiability verification can employ multi-signature verification or threshold signature verification, with the threshold value ranging from 1 to 100, preferably consistent with or slightly higher than the sidechain consensus threshold. Upon successful verification, the main chain writes the anchor proof to the main chain and generates an anchor index. This index may include the target case identifier and the main chain transaction hash, used for subsequent backtracking to locate the sidechain consensus result.

[0031] The consensus results written to the main chain include at least the target case identifier, the consensus-reached diagnostic code, the corresponding diagnostic version number, the consensus formation timestamp, a summary of the valid signature set participating in the consensus, the consensus vote count, and a hash summary of the evidence record set used to support the diagnosis. These fields are included to provide sufficient auditability without exposing raw privacy data, enabling third parties to verify when the consensus diagnosis was formed, which entities confirmed it, whether the evidence set is complete, and to locate the evidence index back to the sidechain.

[0032] The claims processing module is used to determine the benchmark compensation standard on the main chain based on the compensation basis contract and consensus results, such as... Figure 3As shown, the claims processing module extracts the coverage clauses, scope of reimbursement items, deductible conditions, reimbursement ratio, and reimbursement cap corresponding to the consensus diagnosis from the contract on which the reimbursement is based. The coverage clauses can be expanded to correspond to disease liability, accident liability, or specific liability. The scope of reimbursement items can include a set of item tags such as examination fees, treatment fees, medication fees, and surgical fees. The claims processing module matches the consensus diagnosis and its associated treatments, medications, and examinations with the scope of reimbursement items to determine the set of reimbursable items. Then, it applies deductible deductions to the expenses in the set of reimbursable items according to the deductible conditions. Finally, it calculates the benchmark reimbursement standard for the target case based on the reimbursement ratio and reimbursement cap.

[0033] There are several ways to implement deductible conditions. In one embodiment, deductible conditions include a deductible amount and deductible items. After summarizing the amount of reimbursable items, the system first deducts the deductible amount before calculating the reimbursement. In another embodiment, deductible conditions include waiting periods, exclusion of pre-existing conditions, and restrictions on designated hospitals. The system uses a rule engine to convert the conditions into verifiable constraints before making a judgment. To ensure the traceability of the calculation, the claims processing module can record key intermediate quantities of the calculation process in a summary format in an off-chain audit database and save the audit index on the main chain for easy subsequent review.

[0034] The claims processing module also includes a clause parsing submodule to enhance the structuring capabilities of natural language clauses. In one embodiment, the clause parsing submodule uses a large language model to semantically parse the natural language clauses of the compensation-based contract, outputting the protection liability clause identifier corresponding to the consensus diagnosis, the set of item tags for the scope of compensation items, and the structured constraint expression of the deductible conditions. Based on the structured constraint expression, it completes the matching of consensus diagnosis and treatment, medication, examination items, and the scope of compensation items.

[0035] The large language model can be implemented using a general pre-trained model with domain fine-tuning. Domain fine-tuning data can come from historical clause texts and manually annotated clause structure results. To control output stability, the temperature parameter during inference ranges from 0 to 1, preferably from 0 to 0.3; the maximum output length ranges from 64 to 4096, preferably from 256 to 1024. The output of the clause parsing submodule can be further fed into the rule engine for consistency verification, such as verifying whether the payout ratio is between 0 and 1 and whether the payout limit is non-negative, to avoid calculation errors caused by abnormal model output. In another embodiment, when not using a large language model, regular expression extraction, template matching, or knowledge graph clause mapping can also be used to implement clause parsing to adapt to different deployment costs and compliance requirements.

[0036] The risk control decision module, based on the machine learning module, takes data from the diagnostic evolution sidechain as input and outputs risk control indicators for target cases and adjustments to the benchmark payout, such as... Figure 3As shown, risk control indicators are used to express risk types, including at least indicators for abnormal diagnosis changes, inconsistencies in cross-institutional diagnoses, abnormal treatment sequence, mismatch between diagnosis and medication, abnormal expense items, suspected duplicate medical treatment or reimbursement, and missing key evidence. The reason for setting risk control indicators is that in scenarios where diagnostic evolution and tamper-proof record-keeping coexist, relying solely on the final diagnosis is insufficient to reveal abnormal patterns in the evolution process. Risks often manifest in procedural characteristics such as frequent diagnostic reversals, evidence gaps, cross-institutional conflicts, or abnormal cost structures.

[0037] The machine learning module includes a risk control indicator prediction model and a payout adjustment prediction model. The risk control indicator prediction model outputs one or more of the aforementioned indicators, while the payout adjustment prediction model outputs an adjustment value to the benchmark payout. The adjustment value can be in absolute amount or percentage form.

[0038] The training process of the machine learning module includes acquiring iterative diagnostic records of historical cases on the diagnostic evolution sidechain, the corresponding main chain consensus results, and claims processing results, and constructing training samples based on cases. Sample input can be implemented in various ways. In one embodiment, the sample input includes the temporal sequence information of the diagnostic iteration sequence, the diagnostic code or diagnostic text features of each iteration, diagnostic change trajectory features, and the signature or submission frequency features of participants related to the diagnostic evolution sidechain. Diagnostic text features can be implemented through word segmentation vectors, Transformer text encoding, or medical entity recognition followed by embedding. Diagnostic change trajectory features may include version number, number of changes, and differences between adjacent versions. Signature or submission frequency features can be used to characterize participant activity and the degree of disagreement. Verified risk control conclusions in historical claims processing results serve as the first label, and the adjustment range of the benchmark compensation standard in historical claims processing results serves as the second label. To improve the credibility of the training data, the machine learning module uses the main chain consensus results as the sample selection condition, eliminating case samples where consensus has not been reached or consensus has been rolled back, avoiding noisy samples that could cause the model to learn unstable associations.

[0039] In one embodiment, the risk control identification prediction model is implemented using a supervised learning classification model, which can be a gradient boosting tree, a lightweight neural network, or a sequence neural network. The payout adjustment prediction model is implemented using a supervised learning regression model, which can be linear regression, gradient boosting regression, or neural network regression. For scenarios where sequence features are dominant, the machine learning module uses a sequence neural network model. The sequence neural network model adopts a Transformer-based encoder structure to encode the diagnostic iteration sequence of the target case on the diagnostic evolution sidechain. The risk control identification is output through a fully connected classification head, and the adjustment value of the benchmark payout is output through a regression head. The number of layers in the Transformer encoder ranges from 1 to 24, preferably from 2 to 8; the hidden dimension ranges from 64 to 2048, preferably from 128 to 512; and the number of attention heads ranges from 1 to 16, preferably from 2 to 8. During training, the learning rate ranges from 0.000001 to 0.01, preferably from 0.0001 to 0.001; the batch size ranges from 8 to 1024, preferably from 32 to 256; and the number of training epochs ranges from 1 to 200, preferably from 10 to 50. To prevent overfitting, dropout can be used, with a value ranging from 0 to 0.5, preferably from 0.1 to 0.3. The classification loss function can be cross-entropy, and the regression loss function can be mean squared error or Huber loss. The two can be weighted and summed to form a joint loss, with weights ranging from 0.1 to 10, preferably from 0.5 to 2, to balance the learning intensity of label recognition and adjusted value prediction.

[0040] In another embodiment, the risk control identification prediction model and the payout adjustment prediction model can also adopt a phased training approach. First, the risk control identification prediction model is trained to obtain a stable risk representation, and then some encoder parameters are fixed to train the payout adjustment prediction model to improve stability in small sample scenarios. Alternatively, an online learning approach can be used, incrementally adding new case samples weekly or monthly for retraining or fine-tuning. The update frequency ranges from 1 day to 180 days, preferably 7 days to 30 days, to adapt to changes in medical and insurance rules.

[0041] Through the above implementation methods, the present invention enables the diagnostic iteration process to be continuously traced and verified in the sidechain, forming a stable anchor point for consensus conclusions and contractual interpretations in the main chain. The claims processing module can determine the benchmark compensation standard based on the consensus results and the contract, and the risk control decision module can output risk control identifiers and provide adjustment suggestions for the benchmark compensation by combining diagnostic evolution data. Thus, in a scenario where tamper-proof records and continuous diagnostic evolution coexist, a traceable, calculable, and auditable claims and risk control closed loop is achieved.

[0042] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A commercial insurance medical data blockchain storage and risk control decision-making system, characterized in that, This includes a diagnostic evolution sidechain, main chain, cross-chain anchoring protocol, claims processing module, and risk control decision-making module; The diagnostic evolution sidechain is used to record the iterative process of medical diagnosis for a target case; The main chain includes a compensation basis contract; The cross-chain anchoring protocol connects the diagnostic evolution sidechain and the main chain, and is used to write the consensus result of the corresponding diagnostic evolution sidechain into the main chain when the diagnostic evolution sidechain reaches a consensus on the diagnosis of the target case. The claims processing module is used to determine the benchmark compensation standard on the main chain based on the compensation basis contract and consensus results; The risk control decision module, based on the machine learning module, takes the data from the diagnostic evolution sidechain as input and outputs a risk control identifier for the target case and an adjustment to the benchmark payout.

2. The system according to claim 1, characterized in that, The data recorded by the diagnostic evolution sidechain needle includes one or more of the following: Each diagnostic iteration includes the submitter's identifier and digital signature, submission timestamp, candidate diagnosis code and its version number, diagnosis change reason information, summary of examination and test results supporting the candidate diagnosis and its hash fingerprint, summary of treatment / medication record and its hash fingerprint, evidence hash and reference address of image or report file, and consensus voting records and results associated with the candidate diagnosis.

3. The system according to claim 1 or 2, characterized in that, The diagnostic evolution sidechain's consensus criteria for diagnosing target case identifiers include: The candidate diagnoses submitted by each participant are written into the consensus record pool, and the candidate diagnoses are normalized and mapped to obtain a unified diagnostic code. Within the preset consensus window, count the number of valid signatures corresponding to each candidate diagnosis, where valid signatures are those of participants that meet the permission verification and whose signatures are verifiable. When the number of valid signatures for a candidate diagnosis reaches a preset threshold and the candidate diagnosis is not rejected by a veto record submitted by a participant with higher authority within the preset consensus window, it is determined that the corresponding candidate diagnosis has reached a consensus and a consensus result is generated.

4. The system according to claim 1, characterized in that, The consensus result written to the main chain includes one or more of the following: The target case identifier, the consensus diagnosis code, the corresponding diagnosis version number, the consensus formation timestamp, the summary of the valid signature set participating in the consensus, the consensus voting count result, and the hash digest of the evidence record set used to support the diagnosis in the diagnosis evolution sidechain.

5. The system according to claim 1, characterized in that, The process by which the claims processing module determines the benchmark compensation standard includes: Extract the coverage clauses, scope of coverage items, deductible conditions, coverage ratio and coverage limit corresponding to the consensus diagnosis from the compensation basis contract; The consensus diagnosis and associated treatment / medication / examination items corresponding to the consensus results are matched with the scope of reimbursement items to determine the set of reimbursable items; According to the deductible conditions, the expenses in the set of reimbursable items are subject to deductible processing, and the benchmark reimbursement standard for the target case is calculated based on the reimbursement ratio and the reimbursement limit.

6. The system according to claim 5, characterized in that, The claims processing module includes a clause parsing submodule. The clause parsing submodule uses a large language model to perform semantic parsing on the natural language clauses of the compensation basis contract, outputting the protection liability clause identifier corresponding to the consensus diagnosis, the item tag set of the compensation item scope, and the structured constraint expression of the deductible conditions. Based on the structured constraint expression, the module completes the matching of the consensus diagnosis and its associated treatment / medication / examination items with the compensation item scope.

7. The system according to claim 1, characterized in that, The cross-chain anchoring protocol includes: generating an anchoring proof on the diagnostic evolution sidechain, wherein the anchoring proof includes the sidechain block hash corresponding to the consensus result, the hash digest of the consensus result, and a digest of the valid signature set participating in the consensus; The anchoring proof is encapsulated into the main chain transaction payload by a cross-chain relay node or cross-chain gateway and submitted to the main chain; On the main chain side, the anchor proof is verified based on preset side chain verification parameters. The verification includes a matching verification of the side chain block hash and the hash digest of the consensus result, as well as a signature verifiability verification of the valid signature set digest. When the verification passes, the main chain writes the anchoring proof into the main chain and generates an anchoring index that can be used to backtrack and locate the consensus result of the diagnostic evolution sidechain.

8. The system according to claim 1, characterized in that, The machine learning module includes a risk control identifier prediction model and a payout adjustment prediction model. The risk control identifier prediction model is used to output the risk control identifier of the target case, and the payout adjustment prediction model is used to output the adjustment value of the benchmark payout. The training process of the machine learning module includes: Obtain iterative diagnostic records of historical cases on the diagnostic evolution sidechain, the corresponding main chain consensus results, and claims processing results, and construct training samples based on cases; The verified risk control conclusions in the historical claims processing results are used as the first label, and the adjustment range of the benchmark compensation standard in the historical claims processing results is used as the second label. A supervised learning classification model is trained based on the sample input and the first label to obtain a risk control identification prediction model, and a supervised learning regression model is trained based on the sample input and the second label to obtain a compensation adjustment prediction model. Among them, the consensus result of the main chain is used as the sample screening condition to remove case samples that have not reached a consensus or whose consensus has been rolled back.

9. The system according to claim 1, characterized in that, The risk control indicators include any one or more of the following: abnormal diagnosis change indicator, inconsistent diagnosis across institutions indicator, abnormal treatment sequence indicator, mismatch between diagnosis and medication indicator, abnormal cost item indicator, suspected duplicate medical treatment or duplicate reimbursement indicator, and missing key evidence indicator.

10. The system according to claim 1 or 8, characterized in that, The machine learning module employs a sequence neural network model, which uses a Transformer-based encoder structure to encode the diagnostic iteration sequence of the target case on the diagnostic evolution sidechain. The risk control identifier is output through a fully connected classification head, and the adjustment value of the benchmark payout is output through a regression head.

Images