An insurance claim intelligent processing method and system based on closed-loop engineering

Abstract

The application discloses an insurance claim intelligent processing method and system based on a closed loop project, and the method comprises the following steps: receiving multi-source claim event data, creating a closed loop task object when a preset trigger condition is met; assembling context data from a business asset library; generating a directed action graph configured with a verification rule based on a target state and the context data; executing an action according to the action graph and collecting execution evidence, and calculating a closed loop score; determining a branch decision of task closing, re-planning, rolling back or manual conversion according to the closed loop score, a risk level and a maximum iteration number. The application realizes end-to-end automatic closed loop of claim processing through closed loop task driving and feedback re-planning.

Description

Technical Field

[0001] This invention relates to the field of insurance claims data processing technology, and in particular to an intelligent insurance claims processing method and system based on closed-loop engineering. Background Technology

[0002] Currently, insurance industry claims information systems typically operate on a fixed business process framework, configuring process nodes, operation pages, and permission rules around stages such as reporting, investigation, loss assessment, loss verification, claims calculation, settlement, and payment. To address management needs such as timeliness alerts, clearing pending cases, loss estimation discrepancies, and risk case identification, specialized reports, data dashboards, rule engines, automated robotic processes, or intelligent analysis models are usually added. Existing reports and dashboards can display indicators such as case closure rate and processing rate, and support drill-down to specific cases from the perspective of institutions, teams, and individuals; some systems can also send reminders, generate tasks, or call single business interfaces based on thresholds or model results.

[0003] However, while reports, dashboards, rule alerts, or model scores can detect anomalies, anomaly identification, cause localization, action selection, action execution, result verification, and follow-up are usually scattered across different systems or rely on manual coordination, failing to form a sustainable end-to-end closed loop for computer operation. Summary of the Invention

[0004] This invention provides an intelligent insurance claims processing method and system based on closed-loop engineering, which can solve the problem in the prior art where anomaly detection and problem solving are disconnected and cannot form an end-to-end automatic closed loop.

[0005] To achieve the above objectives, the embodiments of the present invention adopt the following technical solutions: Firstly, a method for intelligent processing of insurance claims based on closed-loop engineering is provided. The method includes: S1, receiving multi-source claims event data; when the multi-source claims event data meets preset triggering conditions, creating a closed-loop task object, the closed-loop task object including a case identifier, target status, risk level, and maximum iteration count; S2, assembling context data from a pre-built business asset library according to the closed-loop task object, the context data being operational indicators, case process, personnel behavior, management rules, and management action information associated with the case identifier and the target status; S3, generating a directed action graph based on the target status and the context data, each action node in the directed action graph being configured with verification rules; S4, executing each action node according to the directed action graph and collecting execution evidence, calculating a closed-loop score based on the matching degree between the execution evidence and the target status; S5, determining a closed-loop branch decision based on the closed-loop score, the risk level, and the maximum iteration count, the closed-loop branch decision including task closure, replanning, rollback, or transfer to manual processing.

[0006] The method provided by this invention receives multi-source claims event data and creates a closed-loop task object containing case identifier, target status, risk level, and maximum iteration count. Driven by the target status, each processing step is constructed as a closed-loop task with a clear endpoint. By assembling context data associated with case identifier and target status from a pre-built business asset library, unified retrieval and assembly of operational indicators, case processes, personnel behaviors, management rules, and management actions are achieved. By generating a directed action graph configured with verification rules based on the target status and context data, each automatically executed action is bound to a verifiable execution standard. By executing each action node according to the directed action graph, collecting execution evidence, and calculating the closed-loop score, automatic verification after action execution is achieved. By determining the closed-loop branch decision based on the closed-loop score, risk level, and maximum iteration count, multi-branch automatic control of task closure, replanning, rollback, or transfer to manual processing is achieved.

[0007] In one possible implementation of the first aspect, receiving multi-source claims event data and creating a closed-loop task object when the multi-source claims event data meets preset trigger conditions includes: standardizing the raw data collected from message queues, database change logs, API interfaces, or operation logs, establishing associations by case number, personnel number, and organization number, and generating claims event objects; determining whether the claims event objects meet the preset trigger conditions based on the operating indicators and management rules in the business asset library, wherein the preset trigger conditions include: the current value of a preset operating indicator in the business asset library exceeds the corresponding abnormal threshold, or the trigger condition of a preset management rule is met.

[0008] The method provided by this invention generates claims event objects by standardizing and associating multi-source raw data, thereby achieving unified access to heterogeneous data sources; it covers two closed-loop triggering modes, namely indicator-driven and rule-driven, by judging whether preset triggering conditions are met based on two conditions: abnormal operating indicators and triggering by management rules.

[0009] In one possible implementation of the first aspect, the closed-loop task object further includes a closure threshold and a manual takeover threshold; the target state includes the business state to be changed, the required evidence set, and the completion deadline; the task state of the closed-loop task object includes initialization, context ready, planned, executing, verifying, replanning, rollback, manual or closed.

[0010] The method provided by this invention clarifies the boundary criteria between automatic task closure and secure takeover by defining closure thresholds and manual takeover thresholds for closed-loop task objects; it makes task objectives quantifiable and verifiable by breaking down the target state into the business state to be changed, the required evidence set, and the completion deadline; and it achieves standardized management of the entire lifecycle of closed-loop tasks by defining a complete task state machine.

[0011] In one possible implementation of the first aspect, the business asset library includes an operational indicator library, a case process library, a personnel behavior and profile library, a management rule library, and a management action library. The step of assembling context data from the pre-built business asset library based on the closed-loop task object includes: using the case identifier and the target status as search conditions, reading abnormal indicators and drill-down paths from the operational indicator library; reading the case's full lifecycle status sequence from the case process library; reading the current handler's operational capabilities and risk tags from the personnel behavior and profile library; reading hard constraint rules and closure rules from the management rule library; and reading actions that can be invoked within the current permission scope from the management action library. The retrieved data items are then sorted according to relevance, calculated based on semantic matching degree, data freshness, source authority, process matching degree, and conflict penalty item. The first few selected data items after sorting are then used to form the context data with version numbers.

[0012] The method provided by this invention unifies the retrieval of five business asset databases to assemble operational indicators, case processes, personnel behaviors, management rules and actions scattered across different systems into contextual data; by selecting high-value data based on multi-dimensional relevance ranking and forming contextual data with version numbers, it provides a reproducible data foundation for subsequent planning and verification.

[0013] In one possible implementation of the first aspect, generating a directed action graph based on the target state and the context data includes: decomposing the target state into several sub-targets; selecting corresponding action nodes from the management action library according to each sub-target; configuring preconditions, verification rules, and rollback strategies for each action node; and forming the directed action graph according to the dependency relationship among multiple action nodes; performing permission verification, dependency verification, parameter verification, and hard constraint verification on the directed action graph, and executing only after the verification is passed.

[0014] The method provided by this invention decomposes the target state into sub-targets and matches them with action nodes, thereby realizing the layer-by-layer decomposition and action mapping of complex targets. By binding preconditions, verification rules and rollback strategies to each action node, the method structurally ensures that the actions are verifiable and rollbackable. By performing multiple checks on the directed action graph, the method ensures that the planning results are executable only within safety constraints.

[0015] In one possible implementation of the first aspect, the step of executing each action node according to the directed action graph and collecting execution evidence includes: calling the business interfaces corresponding to each action node according to the topological order of the directed action graph; generating an idempotent key with the closed-loop task identifier, node identifier and current iteration number before each call, and saving the state before execution and input parameters; saving the interface response, the state after execution and the state version after the call is completed; when the call fails or times out, retrying according to the retry strategy configured for the corresponding action node, and if the retry still fails, executing the corresponding rollback strategy or generating failure evidence.

[0016] The method provided by this invention prevents repeated execution through an idempotent key mechanism, achieves version tracking by saving the state before and after execution, and provides fault tolerance guarantees at the action execution level through retry and rollback strategies.

[0017] In one possible implementation of the first aspect, the step of calculating the closed-loop score based on the matching degree between the execution evidence and the target state includes: calculating the state matching degree, which represents the degree of matching between the current case state after execution and the business state to be changed in the target state; calculating the rule pass rate, which represents the degree of pass rate of the closing rule after execution; calculating the evidence completeness, which represents the proportion of the required evidence set in the target state that has been collected; and weighted and fused the state matching degree, the rule pass rate, and the evidence completeness to obtain the closed-loop score.

[0018] The method provided by this invention calculates a closed-loop score from three dimensions: state matching degree, rule pass rate, and evidence completeness. This ensures that the score not only reflects whether the interface call was successful, but also whether the business state has actually changed, whether the rules are met, and whether the evidence is complete, thus achieving multi-dimensional result verification.

[0019] In one possible implementation of the first aspect, determining the closed-loop branch decision based on the closed-loop score, the risk level, and the maximum number of iterations includes: determining the closed-loop branch decision as task closure when the closed-loop score is greater than or equal to the closure threshold and there are no hard constraint rule conflicts; determining the closed-loop branch decision as replanning when the closed-loop score is less than the closure threshold, the risk level is lower than the manual takeover threshold, and the current iteration number is less than the maximum number of iterations; determining the closed-loop branch decision as rollback and performing compensation actions when execution leads to state deterioration or version conflict; and determining the closed-loop branch decision as manual transfer when the risk level reaches the manual takeover threshold, the current iteration number reaches the maximum number of iterations, or there is a rule conflict.

[0020] The method provided by this invention establishes a multi-condition branch judgment logic among closed-loop scoring, closure threshold, risk level, manual takeover threshold and iteration number, and realizes four differentiated decisions: task closure, replanning, rollback and manual transfer, which takes into account both automation efficiency and claims security control.

[0021] In one possible implementation of the first aspect, when the closed-loop branch decision is replanning, the method further includes: writing the failed action, failure reason, missing evidence, latest state and prohibited repeated action of the previous round into new context data, increasing the current iteration number, re-executing S2 to S5 until the closed-loop branch decision is task closure or manual transfer, and selecting an action path that is different from the previous round and meets the new constraints during replanning.

[0022] The method provided by this invention achieves dynamic replanning based on execution feedback by writing the failure cause and missing evidence into new context data and re-executing S2 to S5. It avoids invalid loops by prohibiting repeated actions and prioritizing different paths.

[0023] Secondly, this invention provides an intelligent insurance claims processing system based on closed-loop engineering. The system includes: an event perception module, used to receive multi-source claims event data, and when the multi-source claims event data meets preset trigger conditions, create a closed-loop task object, the closed-loop task object including case identifier, target state, risk level, and maximum iteration count; a context assembly module, used to assemble context data from a pre-built business asset library according to the closed-loop task object, the context data being operational indicators, case process, personnel behavior, management rules, and management action information associated with the case identifier and the target state; an action planning module, used to generate a directed action graph based on the target state and the context data, each action node in the directed action graph being configured with verification rules; an execution verification module, used to execute each action node according to the directed action graph and collect execution evidence, and calculate a closed-loop score based on the matching degree between the execution evidence and the target state; and a closed-loop determination module, used to determine a closed-loop branch decision based on the closed-loop score, the risk level, and the maximum iteration count, the closed-loop branch decision including task closure, replanning, rollback, or transfer to manual processing.

[0024] Thirdly, an electronic device is provided, the electronic device including a memory and one or more processors; the memory is coupled to the processors; wherein the memory stores computer program code, the computer program code including computer instructions, which, when executed by the processor, cause the electronic device to perform the method as described in any implementation of the first aspect.

[0025] Fourthly, a computer-readable storage medium is provided, including computer instructions that, when executed on an electronic device, cause the electronic device to perform a method as described in any implementation of the first aspect.

[0026] Fifthly, a computer program product is provided that, when run on a computer, causes the computer to perform the method in any implementation of the first aspect.

[0027] Understandably, the beneficial effects achieved by the system of the second aspect, the electronic device of the third aspect, the computer-readable storage medium of the fourth aspect, and the computer program product of the fifth aspect provided above can be referred to with reference to the beneficial effects of the first aspect and any of its possible design embodiments, which will not be repeated here. Attached Figure Description

[0028] Figure 1 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention; Figure 2 A flowchart illustrating an intelligent insurance claims processing method based on closed-loop engineering, provided as an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of an intelligent insurance claims processing system based on closed-loop engineering, provided as an embodiment of the present invention. Detailed Implementation

[0029] The technical solutions of the embodiments of the present invention will be described below with reference to the accompanying drawings. In the description of the present invention, unless otherwise stated, " / " indicates that the objects before and after are in an "or" relationship. For example, A / B can represent A or B. The "or" in the present invention is merely a description of the relationship between the related objects, indicating that three relationships can exist. For example, A or B can represent: A alone, A and B simultaneously, and B alone. A and B can be singular or plural. Furthermore, in the description of the present invention, unless otherwise stated, "multiple" refers to two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items.

[0030] Furthermore, to facilitate a clear description of the technical solutions of the embodiments of the present invention, the terms "first" and "second" are used in the embodiments of the present invention to distinguish identical or similar items with essentially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that the terms "first" and "second" are not necessarily different.

[0031] In this embodiment of the invention, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design described as "exemplary" or "for example" in this embodiment of the invention should not be construed as superior or more advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner for ease of understanding.

[0032] Currently, insurance industry claims information systems typically operate on a fixed business process framework, configuring process nodes, operation pages, and permission rules around stages such as reporting, investigation, loss assessment, loss verification, claims calculation, settlement, and payment. To address management needs such as timeliness alerts, clearing pending cases, loss estimation discrepancies, and risk case identification, specialized reports, data dashboards, rule engines, automated robotic processes, or intelligent analysis models are usually added. Existing reports and dashboards can display indicators such as case closure rate and processing rate, and support drill-down to specific cases from the perspective of institutions, teams, and individuals; some systems can also send reminders, generate tasks, or call single business interfaces based on thresholds or model results.

[0033] However, while reports, dashboards, rule alerts, or model scores can detect anomalies, anomaly identification, cause localization, action selection, action execution, result verification, and follow-up are usually scattered across different systems or rely on manual coordination, failing to form a sustainable end-to-end closed loop for computer operation.

[0034] In view of this, embodiments of the present invention provide an intelligent insurance claims processing method based on closed-loop engineering. The method includes: S1, receiving multi-source claims event data, and when the multi-source claims event data meets preset triggering conditions, creating a closed-loop task object, wherein the closed-loop task object includes a case identifier, a target state, a risk level, and a maximum number of iterations; S2, assembling context data from a pre-built business asset library according to the closed-loop task object, wherein the context data includes operating indicators, case process, personnel behavior, management rules, and management action information associated with the case identifier and the target state; S3, generating a directed action graph based on the target state and the context data, wherein each action node in the directed action graph is configured with verification rules; S4, executing each action node according to the directed action graph and collecting execution evidence, and calculating a closed-loop score based on the matching degree between the execution evidence and the target state; S5, determining a closed-loop branch decision based on the closed-loop score, the risk level, and the maximum number of iterations, wherein the closed-loop branch decision includes task closure, replanning, rollback, or transfer to manual processing.

[0035] The method provided by this invention receives multi-source claims event data and creates closed-loop task objects, constructing each processing step as a closed-loop task with a clear target state and iteration boundary; it assembles context data from a business asset library to achieve unified retrieval of operating indicators, case processes, personnel behavior, management rules, and management actions; it generates directed action graphs configured with verification rules to ensure that each action is bound to verifiable standards; it collects execution evidence and calculates closed-loop scores to achieve automatic verification after action execution; and it determines branch decisions based on closed-loop scores, risk levels, and maximum iteration counts to achieve differentiated control of task closure, replanning, rollback, or transfer to manual processing.

[0036] In some embodiments, the intelligent insurance claims processing method based on closed-loop engineering provided by the present invention can be executed by an intelligent insurance claims processing system 100 based on closed-loop engineering (hereinafter referred to as processing system 100).

[0037] As an example, the processing system 100 can be any electronic device 200 with data processing capabilities, such as a general-purpose computer, personal computer, laptop computer, switch, or tablet computer. The specific implementation of the processing system 100 is not limited here.

[0038] Figure 1 A schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present invention is shown. The electronic device 200 includes a processor 210, a memory 220, and a communication interface 230.

[0039] Processor 210 may include one or more processing cores. Processor 210 connects to various parts within electronic device 200 using various interfaces and lines, and performs various functions and processes data of electronic device 200 by running or executing instructions, programs, code sets, or instruction sets stored in memory 220, and by calling data stored in memory 220. Optionally, processor 210 may be implemented using at least one of the following hardware forms: Central Processing Unit (CPU), Graphics Processing Unit (GPU), Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), and Programmable Logic Array (PLA).

[0040] The memory 220 may include random access memory (RAM) or read-only memory (ROM). Optionally, the memory 220 may include a non-transitory computer-readable storage medium. The memory 220 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 220 may include a program storage area. This program storage area may store instructions for implementing an operating system, instructions for implementing at least one function, instructions for implementing the various method embodiments described above, etc.

[0041] Communication interface 230 is used to communicate with other devices, equipment or communication networks, such as data storage devices, image processing devices or Ethernet, wireless access network (RAN), wireless local area network (WLAN), etc.

[0042] In terms of physical implementation, the aforementioned devices (such as processor 210, memory 220, and communication interface 230) can each be devices within the same device (such as a laptop computer). Alternatively, at least two of these devices can be located within the same device, i.e., as different devices within the same device, similar to the deployment of devices or components in a distributed system.

[0043] It is understood that the structure illustrated in this embodiment does not constitute a specific limitation on the electronic device 200. In other embodiments of the present invention, the electronic device 200 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0044] The following description, in conjunction with the accompanying drawings, illustrates an intelligent insurance claims processing method based on closed-loop engineering provided by an embodiment of the present invention.

[0045] Figure 2 This is a flowchart illustrating an intelligent insurance claims processing method based on closed-loop engineering, provided as an embodiment of the present invention. Optionally, this method can be... Figure 1 The illustrated electronic device performs this operation. The method includes the following steps: S1. Receive multi-source claims event data. When the multi-source claims event data meets the preset triggering conditions, create a closed-loop task object. The closed-loop task object includes case identifier, target status, risk level, and maximum number of iterations.

[0046] Specifically, multi-source claims event data comes from various data access channels such as message queues, database change logs, API interfaces, or operation logs, covering business data from all stages of claims processing, including reporting, investigation, loss assessment, loss verification, claims calculation, claims settlement, and payment. After receiving the raw data, it is first standardized, and associated by case number, personnel number, and organization number, converting heterogeneous data from different sources into unified claims event objects.

[0047] A closed-loop task object refers to a closed-loop computational unit that constructs each claims processing request as having a clear target state, executable actions, verifiable evidence, and termination conditions. Specifically, the case identifier is used to associate a specific claims case, the target state describes the business state that this closed-loop task is expected to achieve, the risk level indicates the business risk level of the task, and the maximum number of iterations limits the upper limit of the system's automatic retries.

[0048] In one possible implementation, before creating a closed-loop task object, it is necessary to determine whether the multi-source claims event data meets the preset trigger conditions. Preset trigger conditions include: the current value of a preset operating indicator in the business asset database exceeds the corresponding abnormal threshold, for example, if an institution's "number of overdue pending cases" exceeds a preset upper limit, the system locates the specific case based on the drill-down path and generates a trigger event; or, the trigger conditions of preset management rules are met, for example, if the personnel behavior and profile database detect a combination of abnormal behaviors such as abnormal logins and repeated returns within a preset window, a trigger event is generated according to the management rules.

[0049] Furthermore, the closed-loop task objects also include a closure threshold and a manual takeover threshold. The closure threshold is used to determine whether the task meets the conditions for automatic closure, while the manual takeover threshold is used to determine whether the task risk has reached a level that requires manual handling. In addition to the business status, the target status also includes the required evidence set and the completion deadline. The required evidence set specifies the types of evidence that must be collected to prove that the target has been achieved, and the completion deadline specifies the latest time limit for closing the task.

[0050] The task state of a closed-loop task object migrates between initialization, context ready, planned, executing, verifying, replanning, rollback, manual, and closed, forming a complete task lifecycle management.

[0051] The method provided by this invention achieves unified access to heterogeneous data sources by standardizing and associating multi-source raw data to generate claims event objects; it covers two closed-loop triggering modes, namely indicator-driven and rule-driven, by judging whether preset triggering conditions are met based on two conditions: abnormal operating indicators and management rule triggering; and it makes tasks quantifiable and automatically controllable by defining closure thresholds, manual takeover thresholds, and a complete task state machine for closed-loop task objects.

[0052] S2. Based on the closed-loop task object, assemble context data from the pre-built business asset library. The context data includes business indicators, case process, personnel behavior, management rules, and management action information associated with the case identifier and the target status.

[0053] Specifically, the business asset library refers to a reusable asset layer formed by unifying and accumulating data and capabilities scattered across different systems in claims scenarios. It includes five independent and scalable business asset libraries: the operational indicator library, the case process library, the personnel behavior and profile library, the management rule library, and the management action library.

[0054] In one possible implementation, the specific steps for assembling context data are as follows: using case identifiers and target status as retrieval criteria, read the current values, historical trends, and drill-down paths of abnormal indicators from the operational indicator database to understand the triggering causes and scope of impact; read the case's entire lifecycle status sequence from the case process database, including status changes and personnel operation records at each stage from reporting to payment, forming a case timeline; read the current handler's operational capabilities, historical timeliness, and risk tags from the personnel behavior and profile database; read the hard constraint rules and closure rules applicable to the current case and stage from the management rule database; and read the actions that can be invoked within the current permission scope from the management action database, including queries, material verification, reminders, follow-ups, task assignments, and escalations.

[0055] The amount of data retrieved from the five databases can be substantial, necessitating the sorting of each retrieved data item according to its relevance. Relevance is calculated based on semantic matching, data freshness, source authority, process matching, and conflict penalty. The top few items selected after sorting are then grouped into contextual data with version numbers. These version numbers are associated with the case status version, ensuring that the same round of planning and verification is based on a reproducible data set.

[0056] The method provided by this invention uses a unified retrieval of five business asset databases to assemble operating indicators, case processes, personnel behaviors, management rules and actions scattered across different systems into contextual data with version numbers, providing a structured and reproducible data foundation for subsequent planning.

[0057] S3. Generate a directed action graph based on the target state and the context data, wherein each action node in the directed action graph is configured with a verification rule.

[0058] Specifically, a directed action graph (DAP) refers to an execution plan composed of sub-goals and corresponding action nodes after decomposing a target state according to their dependencies. The generation process first decomposes the target state into several sub-goals. For example, "completing the missing material supplementation and proceeding to the next processing node within a limited time" is decomposed into sub-goals such as cause identification, material list acquisition, notification of responsible personnel, material verification, and status confirmation. Then, corresponding action nodes are selected from the management action library based on each sub-goal.

[0059] In one possible implementation, each action node needs to be configured with preconditions, validation rules, and rollback strategies. Preconditions define the state requirements that must be met before the action is executed, validation rules define how to verify the effect of the action after execution, and rollback strategies define the compensation methods in case of execution failure. Multiple action nodes form a directed action graph according to their dependencies.

[0060] After a directed action graph is generated, it must undergo permission verification, dependency verification, parameter verification, and hard constraint verification before execution. Among them, hard constraint verification is used to restrict actions involving compensation payments, liability determination, claim denial, significant amounts, or regulatory requirements, ensuring that high-risk actions are executed within safe boundaries.

[0061] The method provided by this invention decomposes the target state into sub-targets and matches them with action nodes, thereby achieving the layer-by-layer decomposition of complex targets. By binding preconditions, verification rules, and rollback strategies to each action node, it structurally ensures that actions are verifiable and rollbackable. By performing hard constraints and other checks on the directed action graph, it ensures that the planning results can only be executed within the safety boundary.

[0062] S4. Execute each action node according to the directed action graph and collect execution evidence. Calculate the closed-loop score based on the matching degree between the execution evidence and the target state.

[0063] Specifically, during the execution phase, the business interfaces corresponding to each action node are called according to the topological order of the directed action graph. Before each call, an idempotent key is generated using the closed-loop task identifier, node identifier, and current iteration number. The state before execution and input parameters are saved to prevent duplicate execution. After the call is completed, the interface response, post-execution state, and state version are saved. When a call fails or times out, it is retried according to the retry policy configured for the corresponding action node. If the retry still fails, the corresponding rollback policy is executed or failure evidence is generated.

[0064] After execution, the verification phase begins, where execution evidence is collected according to the verification rules bound to each action node. Verification not only checks whether the interface returns success, but also verifies whether the target business status has actually changed, such as whether the case has entered the next stage, whether the materials have been supplemented, whether the responsible personnel have accepted the order, and whether the risk score has decreased.

[0065] In one possible implementation, the closed-loop score is calculated comprehensively from three dimensions: First, the state matching degree is calculated, representing the degree of matching between the current case state after execution and the business state to be changed in the target state; second, the rule pass rate is calculated, representing the pass rate of the closing rules after execution, where closing rules refer to the set of business rules used to determine whether the task has been achieved; third, the evidence completeness is calculated, representing the proportion of the required evidence set in the target state that has been collected. The state matching degree, rule pass rate, and evidence completeness are then weighted and fused to obtain the closed-loop score.

[0066] The method provided by this invention prevents repeated execution by using idempotent keys and achieves version tracking by saving the state before and after execution. By comprehensively calculating the closed-loop score from three dimensions—state matching degree, rule pass rate, and evidence completeness—the method ensures that the score reflects the actual changes in the business state and achieves multi-dimensional result verification.

[0067] S5. Determine the closed-loop branch decision based on the closed-loop score, the risk level, and the maximum number of iterations. The closed-loop branch decision includes task closure, replanning, rollback, or manual intervention.

[0068] Specifically, closed-loop branch decisions are the result of comprehensive judgment based on multiple conditions, and can be divided into the following four cases: First, when the closed-loop score is greater than or equal to the closure threshold and there are no hard constraint rule conflicts, the closed-loop branch decision is determined as task closure. Task closure indicates that the target state has been achieved, the required evidence has been collected, the closure rule has been passed, and the task can be terminated normally.

[0069] Second, when the closed-loop score is less than the closure threshold, the risk level is lower than the manual takeover threshold, and the current iteration count is less than the maximum iteration count, the closed-loop branch decision is determined as a replanning. Replanning indicates that the task has not yet met the target but is still within a safe and controllable range, and the system will continue to try different action paths.

[0070] Third, when execution leads to a deterioration of the state or a version conflict, the closed-loop branch decision will be determined as a rollback, and compensatory actions will be performed. A rollback indicates that the current action has had a negative impact and needs to be reversed. Compensatory actions include withdrawing the task, canceling the notification, or generating a bug fix ticket.

[0071] Fourth, when the risk level reaches the manual takeover threshold, the current iteration count reaches the maximum iteration count, or there is a rule conflict, the closed-loop branch decision will be set to manual intervention. Manual intervention indicates that the system can no longer handle the situation automatically within the safety boundaries and manual intervention is required.

[0072] In one possible implementation, when the closed-loop branch decision is replanning, the system writes the failed action from the previous round, the reason for failure, missing evidence, the latest state, and prohibited actions into new context data, increments the current iteration count, and re-executes S2 to S5 until the closed-loop branch decision is task closure or manual intervention. During replanning, priority is given to action paths that are different from the previous round and satisfy the newly added constraints. Negative constraints prevent the repeated execution of invalid actions, and the latest state and missing evidence drive the next round of planning towards the target state.

[0073] The method provided by this invention establishes a multi-condition branching judgment logic among closed-loop scoring, closure threshold, risk level, manual takeover threshold, and number of iterations, realizing four differentiated decisions: task closure, replanning, rollback, and manual transfer, thus balancing automation efficiency and claims security control. By writing the failure reasons and missing evidence into new context data and re-executing S2 to S5, dynamic replanning based on execution feedback is achieved.

[0074] As described in S1-S5 above, the method provided by this embodiment of the invention receives multi-source claims event data and creates a closed-loop task object in S1, constructing each processing step as a closed-loop task with a clear target state and iteration boundary; in S2, it assembles context data from the business asset library, achieving unified retrieval and versioned assembly of data from the five libraries; in S3, it generates a directed action graph configured with verification rules, ensuring that each action is bound to a verifiable standard; in S4, it executes actions according to the directed action graph, collects evidence, and calculates the closed-loop score, achieving automatic verification after action execution; and in S5, it determines branch decisions based on the closed-loop score, risk level, and maximum number of iterations, achieving differentiated closed-loop control such as task closure, replanning, rollback, or transfer to manual intervention. Through the coordinated operation of these five steps, the problem of the separation between anomaly detection and problem solving in the prior art, which prevents the formation of an end-to-end automatic closed loop, is solved.

[0075] To facilitate understanding of this solution, the following explanation and illustration of the method provided in the embodiments of the present invention will be provided in conjunction with specific examples.

[0076] In one example, the operational indicator database detects that an organization's "number of overdue pending cases" exceeds a threshold. The system locates the specific case based on the drill-down path and generates a trigger event. The system creates a closed-loop task object with the target state of "the case completes the supplementation of missing materials within the time limit and enters the next processing node." Closure evidence includes material upload records, personnel submission records, and changes in case status versions. The system retrieves the case timeline from the case process database, identifying the last effective operation and the current blocking node; reads the workload, historical timeliness, and on-duty status of the current handler from the personnel behavior and profile database; reads the timeliness requirements for this stage from the management rule database; and selects material query, reminder, expediting, assignment, and escalation actions from the management action database. The first round of actions sends a structured task containing missing materials and the deadline to the responsible personnel and verifies whether the task has been delivered and received. If the personnel receive the task but the case status does not change, the second round adds a material list or transfers it to collaborating personnel based on the latest status; if it is still unprocessed and the deadline is approaching, it is escalated to the team leader. When the materials are complete, the case is successfully submitted, and the timeliness rules are met, the closed-loop score reaches the closure threshold, and the task is closed.

[0077] In another example, the operational indicator library detects that the deviation between the estimated loss amount and the subsequent loss assessment amount exceeds a threshold. The event module associates the estimated loss version, loss assessment version, image materials, and handling personnel for the same case. The system's target state is "complete the confirmation of the cause of the deviation and form an effective correction result." The action graph includes retrieving historical versions, identifying discrepancies, generating review tasks, requesting supplementary evidence, and correcting the loss estimate. After execution, the system verifies whether the estimated loss version has been updated, whether the review opinion has been signed, whether the cause of the difference conforms to the rule base enumeration value, and whether the evidence is complete. If only analysis suggestions are generated but no system state change is formed, the closed loop must not be closed. For personnel who repeatedly exhibit the same type of deviation, the closed loop result is synchronously written into the personnel behavior and profile library and can trigger independent closed loop tasks for training or spot checks.

[0078] The foregoing mainly describes the solutions of the embodiments of the present invention from a methodological perspective. It is understood that, in order to achieve the above-mentioned functions, the processing system 100 includes at least one of the hardware structures and software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, in conjunction with the units and algorithm steps of the various examples described in the embodiments disclosed herein, the embodiments of the present invention can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the embodiments of the present invention.

[0079] In this embodiment of the invention, the processing system 100 can be divided into functional units according to the above method example. For example, the processing system 100 can be divided into functional units corresponding to each function, or two or more functions can be integrated into one processing unit. The integrated unit can be implemented in hardware or as a software functional unit. It should be noted that the unit division in this embodiment is illustrative and only represents one logical functional division; other division methods may be used in actual implementation.

[0080] For example, Figure 3 The diagram shows a schematic of the structure of an intelligent insurance claims processing system based on closed-loop engineering, provided by an embodiment of the present invention. The processing system 100 includes: an event perception module 110, used to receive multi-source claims event data, and when the multi-source claims event data meets preset trigger conditions, create a closed-loop task object, the closed-loop task object including case identifier, target status, risk level, and maximum iteration count; a context assembly module 120, used to assemble context data from a pre-built business asset library according to the closed-loop task object, the context data being operating indicators, case process, personnel behavior, management rules, and management action information associated with the case identifier and the target status; an action planning module 130, used to generate a directed action graph based on the target status and the context data, each action node in the directed action graph being configured with verification rules; an execution verification module 140, used to execute each action node according to the directed action graph and collect execution evidence, and calculate a closed-loop score based on the matching degree between the execution evidence and the target status; and a closed-loop determination module 150, used to determine a closed-loop branch decision based on the closed-loop score, the risk level, and the maximum iteration count, the closed-loop branch decision including task closure, replanning, rollback, or transfer to manual processing.

[0081] It should be understood that specific descriptions of the above-mentioned optional methods can be found in the foregoing method embodiments, and will not be repeated here. Furthermore, explanations of any of the processing systems 100 provided above, as well as descriptions of their beneficial effects, can be found in the corresponding method embodiments described above, and will not be repeated here.

[0082] This invention also provides a computer-readable storage medium storing at least one computer instruction, which is loaded and executed by a processor to implement the methods of the various embodiments described above. Explanations of the relevant content and descriptions of the beneficial effects of any of the computer-readable storage media provided above can be found in the corresponding embodiments described above, and will not be repeated here.

[0083] This invention also provides a chip. This chip integrates a control circuit for implementing the functions of the processing system 100 described above, and one or more ports. Optionally, the functions supported by this chip are as described above, and will not be repeated here.

[0084] Those skilled in the art will understand that the program for implementing all or part of the steps of the above embodiments, which can be executed by a program instructing related hardware, can be stored in a computer-readable storage medium. The storage medium mentioned above can be a read-only memory, a random access memory, etc. The processing unit or processor mentioned above can be a central processing unit, a general-purpose processor, an application-specific integrated circuit (ASIC), a microprocessor (DSP), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof.

[0085] This invention also provides a computer program product containing instructions that, when executed on a computer, cause the computer to perform any of the methods described in the above embodiments. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this invention is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., SSD), etc.

[0086] It should be noted that the devices for storing computer instructions or computer programs provided in the embodiments of the present invention, such as, but not limited to, the aforementioned memory, computer-readable storage medium, and communication chip, are all non-transitory. Those skilled in the art should recognize that the functions described in the embodiments of the present invention in one or more of the above examples can be implemented using hardware, software, firmware, or any combination thereof. When implemented using software, these functions can be stored in a computer-readable storage medium or transmitted as one or more instructions or code on a computer-readable storage medium. Computer-readable storage media include computer storage media and communication media, wherein communication media include any medium that facilitates the transmission of computer programs from one place to another. Storage media can be any available medium accessible to general-purpose or special-purpose computers.

[0087] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A method for intelligent processing of insurance claims based on closed-loop engineering, characterized in that, include: S1. Receive multi-source claims event data. When the multi-source claims event data meets the preset triggering conditions, create a closed-loop task object. The closed-loop task object includes case identifier, target status, risk level, and maximum number of iterations. S2. Based on the closed-loop task object, assemble context data from the pre-built business asset library. The context data includes business indicators, case process, personnel behavior, management rules, and management action information associated with the case identifier and the target status. S3. Generate a directed action graph based on the target state and the context data, wherein each action node in the directed action graph is configured with a verification rule; S4. Execute each action node according to the directed action graph and collect execution evidence. Calculate the closed-loop score based on the matching degree between the execution evidence and the target state. S5. Determine the closed-loop branch decision based on the closed-loop score, the risk level, and the maximum number of iterations. The closed-loop branch decision includes task closure, replanning, rollback, or manual intervention.

2. The method according to claim 1, characterized in that, The process of receiving multi-source claims event data, and creating a closed-loop task object when the multi-source claims event data meets preset trigger conditions, includes: The raw data collected from message queues, database change logs, API interfaces, or operation logs is standardized, and associations are established by case number, personnel number, and organization number to generate claims event objects; The system determines whether the claim event object meets the preset trigger conditions based on the operating indicators and management rules in the business asset database. The preset trigger conditions include: the current value of the preset operating indicator in the business asset database exceeds the corresponding abnormal threshold, or the trigger condition of the preset management rule is met.

3. The method according to claim 1, characterized in that, The closed-loop task object also includes a closure threshold and a manual takeover threshold; the target state includes the business state to be changed, the required evidence set, and the completion deadline; the task state of the closed-loop task object includes initialization, context ready, planned, executing, verifying, replanning, rollback, manual or closed.

4. The method according to claim 3, characterized in that, The business asset database includes an operational indicator database, a case process database, a personnel behavior and profile database, a management rule database, and a management action database. The step of assembling context data from a pre-built business asset library based on the closed-loop task object includes: Using the case identifier and the target status as search criteria, abnormal indicators and drill-down paths are read from the operational indicator database, the full life cycle status sequence of the case is read from the case process database, the operational capabilities and risk tags of the current handler are read from the personnel behavior and profile database, hard constraint rules and closure rules are read from the management rule database, and actions that can be invoked within the current permission scope are read from the management action database. The retrieved data items are sorted according to their relevance, which is calculated based on semantic matching degree, data freshness, source authority, process matching degree, and conflict penalty item. The first few items selected after sorting are used to form the context data with version numbers.

5. The method according to claim 4, characterized in that, The generation of a directed action graph based on the target state and the context data includes: The target state is decomposed into several sub-targets, and corresponding action nodes are selected from the management action library according to each sub-target. Each action node is configured with preconditions, verification rules, and rollback strategies, and multiple action nodes are arranged according to their dependencies to form the directed action graph. The directed action graph is subjected to permission verification, dependency verification, parameter verification, and hard constraint verification. Execution is only permitted after the verification is passed.

6. The method according to claim 5, characterized in that, The step of executing each action node according to the directed action graph and collecting execution evidence includes: The business interfaces corresponding to each action node are called according to the topological order of the directed action graph. Before each call, an idempotent key is generated using the closed-loop task identifier, node identifier, and current iteration number, and the state and input parameters before execution are saved. After the call is completed, save the interface response, the post-execution status, and the status version; When a call fails or times out, it is retried according to the retry policy configured for the corresponding action node. If the retry still fails, the corresponding rollback policy is executed or failure evidence is generated.

7. The method according to claim 4, characterized in that, The step of calculating the closed-loop score based on the matching degree between the execution evidence and the target state includes: Calculate the state matching degree, which represents the degree of matching between the current case state after execution and the business state to be changed in the target state; Calculate the rule pass rate, which represents the degree to which the closing rule passes after execution; Calculate the evidence completeness, which represents the proportion of the required evidence set in the target state that has been collected; The closed-loop score is obtained by weighting and fusing the state matching degree, the rule pass rate, and the evidence completeness.

8. The method according to claim 7, characterized in that, The step of determining the closed-loop branch decision based on the closed-loop score, the risk level, and the maximum number of iterations includes: When the closed-loop score is greater than or equal to the closure threshold and there are no hard constraint rule conflicts, the closed-loop branch decision is determined as task closure; When the closed-loop score is less than the closure threshold, the risk level is lower than the manual takeover threshold, and the current iteration number is less than the maximum iteration number, the closed-loop branch decision is determined as a reprogramming. When execution leads to state deterioration or version conflict, the closed-loop branch decision is determined to be a rollback and a compensation action is performed. When the risk level reaches the manual takeover threshold, the current iteration count reaches the maximum iteration count, or a rule conflict exists, the closed-loop branch decision will be determined as manual intervention.

9. The method according to claim 8, characterized in that, When the closed-loop branch decision is a reprogramming, the method further includes: Write the failed action, failure reason, missing evidence, latest status and prohibited repeated action from the previous round into the new context data, increase the current iteration number, and re-execute S2 to S5 until the closed-loop branch decision is to close the task or transfer to manual intervention. When replanning, select an action path that is different from the previous round and meets the new constraints.

10. An intelligent insurance claims processing system based on closed-loop engineering, characterized in that, include: The event awareness module is used to receive multi-source claims event data. When the multi-source claims event data meets the preset triggering conditions, a closed-loop task object is created. The closed-loop task object includes case identifier, target status, risk level and maximum number of iterations. The context assembly module is used to assemble context data from a pre-built business asset library according to the closed-loop task object. The context data includes business indicators, case process, personnel behavior, management rules and management action information associated with the case identifier and the target status. An action planning module is used to generate a directed action graph based on the target state and the context data, wherein each action node in the directed action graph is configured with a verification rule. The execution verification module is used to execute each action node according to the directed action graph and collect execution evidence, and calculate the closed-loop score based on the matching degree between the execution evidence and the target state; The closed-loop determination module is used to determine the closed-loop branch decision based on the closed-loop score, the risk level, and the maximum number of iterations. The closed-loop branch decision includes task closure, replanning, rollback, or manual intervention.

Images