Claim settlement case distribution method and system based on RPA

Abstract

The invention discloses a claim settlement case distribution method and system based on RPA. The method comprises the step of simulating manual operation to log in a system claim settlement platform through an RPA robot. According to the method, the RPA simulation login and paging query merging technology is adopted, so that the time consumption of manual login, case query and data merging operation is shortened, meanwhile, manual operation errors are avoided, and the accuracy of analysis of fields such as case numbers and case reporting time is ensured; a fairness algorithm dynamically counts the number of personnel cases and preferentially distributes the number of personnel cases to the least load personnel, and the pain point of'busy and idle non-uniformity 'is thoroughly solved by combining processing time comparison and a random polling mechanism; the effect monitoring module generates a fairness report per hour, and when the processing time is lower than a threshold value, the strategy weight is automatically adjusted to form a'monitoring-evaluation-tuning 'dynamic closed loop, so that the average processing time is improved, and the requirements of workers are met.

Description

Technical Field

[0001] This invention relates to the field of claims case allocation technology, specifically to a claims case allocation method and system based on RPA. Background Technology

[0002] In the existing insurance claims system, case allocation relies heavily on manual experience or static rules, resulting in significant efficiency bottlenecks and fairness defects. The traditional system mainly suffers from the following core problems: 1. High degree of human intervention: Case allocation relies on manual screening of case types and manual verification of staff workload, resulting in low allocation efficiency; 2. Lack of fairness mechanism: Static allocation rules are prone to causing the phenomenon of "uneven workload". 3. Weak verification mechanism: Traditional systems often use centralized log storage, which is susceptible to tampering. 4. Insufficient dynamic optimization capabilities: Lack of real-time processing and timely monitoring, and adaptive adjustment of strategies. Summary of the Invention

[0003] To address the aforementioned technical issues, this technical solution provides a method and system for allocating claims cases based on RPA, resolving the problems mentioned in the background section.

[0004] To achieve the above objectives, the technical solution adopted by the present invention is as follows: In a first aspect of the invention, a claims case allocation method based on RPA is provided, comprising: Log in to the system's claims platform using an RPA robot to simulate manual operation; Execute the pending task query command in the claims platform to obtain a list of case information; Cases are categorized into medical cases, allowance cases, and non-medical cases based on the case type field. Non-medical cases include serious illnesses and disabilities. Based on the real-time case volume database of each claims personnel, a fairness algorithm is used to prioritize the allocation of cases to the employee number with the fewest cases; After the assignment is completed, a case assignment log is generated and synchronized to the personnel scheduling menu; Monitor the effects of allocation and automatically adjust the allocation strategy.

[0005] Preferably, the step of simulating human operation to log in to the claims platform via an RPA robot specifically includes: System authentication is completed through a pre-configured encrypted account password library or digital certificate verification module, wherein the encrypted account password library is stored using the AES-256 algorithm and transmitted through a secure channel; Automatically capture the image area of ​​the verification code dynamically generated on the login interface, and parse the verification code characters through the recognition module of the FaceID face detection interface engine developed by China Life R&D Center. If the recognition fails, the backup plan is triggered, and the SMS / email interface is called to obtain a second verification code. After successful identity verification, the system automatically redirects users by parsing the main interface of the claims platform and triggering a click event. During the redirection process, the login timestamp and IP address are simultaneously recorded in the audit log database.

[0006] Preferably, the step of executing the pending task query instruction in the claims platform to obtain a list of case information specifically includes: Initiate an HTTP GET request through the preset system API interface address, carrying the identity token verification parameter, and receive the returned JSON format unprocessed case list data packet; Use a JSON parser to extract core fields such as case number, reporting time, and case type from the data packet, and at the same time verify whether the reporting time field conforms to the YYYY-MM-DD HH:MM:SS format specification; The query results are paginated. First, the current page number, total number of pages, and number of records per page parameters returned by the API are parsed. The API interface is called page by page in a loop iteration until all data is obtained. When merging data from multiple pages, a data deduplication algorithm is used to verify the uniqueness of the case number. Finally, a structured dataset containing complete case information is generated, which is the case information list.

[0007] Preferably, the step of classifying cases into medical cases, allowance cases, and non-medical cases based on the case type field specifically includes: The case description field is preprocessed, and text fragments containing medical keywords such as "outpatient", "hospitalization" and "surgery" are extracted by regular expression matching. If the match is successful, it is determined to be a medical case. Perform an exact match operation on the case type code field. When the code value is “R02” or “R05”, it is directly classified as an allowance case. At the same time, the validity of the code is verified by a preset code mapping table. For non-medical cases, a dual-condition judgment is adopted. First, cases with case type codes in the range of "N01" to "N09" are screened. Then, feature words such as "serious illness" and "disability" are matched through the keyword database. Only cases that meet both the code range condition and the feature word matching condition can be classified. Establish a dynamic verification mechanism for case types, record the classification criteria keywords, code values ​​and matching positions in real time during the classification process, generate a timestamped classification log and store it in the audit trail database to ensure that the classification results are traceable.

[0008] Preferably, the method of using a fairness algorithm to prioritize assigning cases to employee numbers with the fewest cases specifically includes: By accessing the claims personnel's case database in real time, the system uses dynamic SQL queries to count the total number of cases currently being handled by each person and generates a sorted list of cases by volume. When multiple individuals are detected to have the same number of cases, the timeliness indicator comparison module is triggered. This module calculates the average processing time by extracting historical case processing records. The timeliness indicator uses a weighted scoring model for quantitative comparison. Based on the sorting results, the single person with the fewest cases and the highest timeliness score is selected as the first choice for allocation. If there are multiple candidates with the same score, the random round-robin allocator is started. The allocator generates a random sequence number and dynamically adjusts the priority of the candidates according to the preset round-robin period to ensure that each candidate is selected only once in n consecutive allocations, where n is the total number of candidates. The allocation decision-making process is recorded in real time to the fairness algorithm execution log. The log includes allocation time, employee number, case number, and decision basis parameters, and a log check code is generated through a hash algorithm to ensure data integrity.

[0009] Preferably, the weighted scoring model formula is: ; in, To ensure timely processing, For the time when the case is completed, Allocate time for the case. The total number of cases, These are the weighting coefficients.

[0010] Preferably, the step of generating a case allocation log after allocation is completed specifically includes: The case number field is extracted from the case information database, and the allocation time record is automatically generated by combining it with the system timestamp. The receiving personnel's employee number data output by the allocation decision module is then associated to form basic log entries. Based on the output of the case type classification module, standardized case type labels are added to the basic log entries, and a fairness algorithm version identifier is embedded. This identifier is dual-encoded with semantic version number format and algorithm parameter hash value to form a complete log entry. The complete log entries are structured to generate JSON transaction packages that conform to the data format, and case allocation logs are generated.

[0011] Preferably, the synchronization step of the personnel scheduling menu specifically includes: The allocation result data is written to the scheduling system database in JSON format through the preset RESTful API interface. The data fields include case number, allocation timestamp, receiving employee ID and case type label. Data integrity verification is performed before writing, including case number uniqueness check, employee ID validity verification and timestamp format verification. When the real-time message push notification of the dispatch system is triggered, a long connection channel is established using the WebSocket protocol. The allocation result is encapsulated into a structured message body, which includes basic case information, allocation decision basis and processing priority identifier. The message body is pushed to the client device corresponding to the recipient and triggers an interface pop-up reminder. When automatically creating case processing task cards in the scheduling menu, the system uses a front-end framework dynamic rendering component library to match preset task card templates based on case type tags, fills in dynamic fields such as case number, receiving personnel, and processing time limit, and embeds a processing progress tracking bar and timeout warning function module. After the task card is generated, it is synchronously updated to the scheduling system database.

[0012] Preferably, the step of monitoring the effects of allocation and automatically adjusting the allocation strategy specifically includes: The performance monitoring agents deployed at each node of the claims system collect case processing time data in real time. This data includes case allocation time, initial processing time, final completion time, and time consumed at each node. The data is stored in a time-series database and a baseline model of processing time is constructed. Based on the baseline model, a daily allocation fairness assessment report is dynamically generated. The report includes the distribution of average case processing time per person, the coefficient of difference in case volume, and the efficiency index of the fairness algorithm. Heat maps and trend curves are generated through a data visualization engine to assist in the analysis. When it is detected that the processing time of a certain person is lower than the preset threshold, the preset threshold is dynamically adjusted according to historical data, using the 3σ rule combined with seasonal factors for correction, and by analyzing the reasons for the timeliness bottleneck (such as staff load, case complexity), the allocation strategy parameters are dynamically adjusted, and the adjustment records and effect feedback are written into the monitoring log to form a closed-loop optimization mechanism.

[0013] In a second aspect of the invention, an RPA-based claims allocation system is also provided, comprising: The login module is used to simulate human operation and log in to the claims platform of the system via an RPA robot; The acquisition module is used to execute a query command for pending tasks in the claims platform and acquire a list of case information. The classification module is used to classify cases into medical cases, allowance cases, and non-medical cases according to the case type field. The non-medical cases include serious illnesses, disabilities, etc. The allocation module is used to prioritize the allocation of cases to the employee number with the fewest cases based on a real-time case quantity database for each claims personnel and using a fairness algorithm. The scheduling module is used to generate a case allocation log after the allocation is completed and synchronize it to the personnel scheduling menu; The monitoring module is used to monitor the effects of allocation and automatically adjust the allocation strategy.

[0014] Compared with existing technologies, this invention provides a method and system for allocating claims cases based on RPA, which has the following beneficial effects: This invention employs RPA-simulated login and paginated query merging technology to shorten the time required for manual login, case query, and data merging, while avoiding human error and ensuring the accuracy of parsing fields such as case number and reporting time. A fairness algorithm dynamically counts the number of cases handled by each staff member and prioritizes allocation to those with the least workload. Combined with processing time comparison and random polling mechanisms, this keeps the difference in case volume within ±5%, completely resolving the pain point of uneven workload distribution. The performance monitoring module generates a fairness report every hour, automatically adjusting strategy weights when processing time falls below a threshold, forming a dynamic closed loop of "monitoring-evaluation-optimization," thereby improving average processing time and meeting the needs of staff. Attached Figure Description

[0015] Figure 1 This is a schematic diagram of the method flow of S101-S106 in this invention; Figure 2 This is a schematic diagram of the method flow of S201-S203 of the present invention; Figure 3 This is a schematic diagram of the method flow for S301-S303 in this invention; Figure 4 This is a schematic diagram of the method flow of S401-S404 in this invention; Figure 5 This is a schematic diagram of the method flow for S501-S504 in this invention; Figure 6 This is a schematic diagram of the method flow for S601-S603 in this invention. Detailed Implementation

[0016] The following description is intended to disclose the invention and enable those skilled in the art to implement it. The preferred embodiments described below are merely examples, and other obvious variations will occur to those skilled in the art.

[0017] Example 1 Please refer to Figure 1 As shown, in a first aspect of the present invention, a claims case allocation method based on RPA is provided, comprising: S101. Log in to the claims platform using an RPA robot to simulate manual operation; S102. Execute the pending task query command in the claims platform to obtain a list of case information; S103. Classify cases into medical cases, allowance cases, and non-medical cases according to the case type field. Non-medical cases include serious illnesses, disabilities, etc. S104. Based on the real-time case volume database of each claims personnel, a fairness algorithm is used to prioritize the allocation of cases to the employee number with the fewest cases. S105. After the allocation is completed, a case allocation log is generated and synchronized to the personnel scheduling menu; S106. Monitor the effects of allocation and automatically adjust the allocation strategy.

[0018] Those skilled in the art will understand that this invention employs RPA-simulated login and paginated query merging technology to shorten the time required for manual login, case query, and data merging, while avoiding human error and ensuring the accuracy of parsing fields such as case number and reporting time. A fairness algorithm dynamically counts the number of cases handled by each staff member and prioritizes allocation to those with the least workload. Combined with a processing time comparison and random polling mechanism, this keeps the difference in caseload within ±5%, completely resolving the pain point of uneven workload distribution. An effectiveness monitoring module generates a fairness report every hour, automatically adjusting strategy weights when processing time falls below a threshold, forming a dynamic closed loop of "monitoring-evaluation-optimization," thereby improving average processing time and meeting the needs of staff.

[0019] Please refer to Figure 2 As shown, the RPA robot simulates manual operation to log in to the claims platform, specifically including: S201. System authentication is completed through a pre-configured encrypted account password library or digital certificate verification module, wherein the encrypted account password library is stored using the AES-256 algorithm and transmitted through a secure channel; S202. Automatically capture the image area of ​​the verification code dynamically generated on the login interface, and parse the verification code characters through the recognition module of the FaceID face detection interface engine developed by China Life R&D Center. If the recognition fails, the backup plan is triggered, and the SMS / email interface is called to obtain the secondary verification code. S203. After identity verification, the system automatically redirects users by parsing the main interface of the claims platform and triggering a click event. During the redirection process, the login timestamp and IP address are simultaneously recorded in the audit log database.

[0020] Those skilled in the art will understand that the AES-256 encrypted account database + digital certificate two-factor authentication complies with the requirements of the Cybersecurity Law for the protection of sensitive data, avoids the risk of plaintext password leakage, and has been tested and blocked brute-force attacks; China Life's R&D Center's self-developed FaceID face detection interface automatically recognizes dynamic verification codes, combined with SMS / email backup verification, reducing the login failure rate; login timestamps and IP addresses are stored in the audit log in real time, supporting real-time queries by regulatory agencies, meeting the compliance requirements of "operation traceability and accountability", and providing a reliable time benchmark for subsequent operations. These steps together construct a complete security system of "identity security authentication - anomaly fault tolerance handling - full-link auditing", which improves automation efficiency and provides an immutable chain of operational evidence for the claims system, and is a key infrastructure to ensure the legality and compliance of the entire automated process.

[0021] Please refer to Figure 3 As shown, executing the pending task query command in the claims platform retrieves a list of case information, specifically including: S301. Initiate an HTTP GET request through the preset system API interface address, carrying the identity token verification parameter, and receive the returned JSON format unprocessed case list data packet; S302. Use a JSON parser to extract core fields such as case number, reporting time, and case type from the data packet, and at the same time verify whether the reporting time field conforms to the YYYY-MM-DD HH:MM:SS format specification. S303. Perform pagination on the query results. First, parse the current page number, total number of pages, and number of records per page parameters returned by the API. Then, call the API interface page by page in a loop until all data is obtained. When merging multiple pages of data, use a data deduplication algorithm to verify the uniqueness of the case number. Finally, generate a structured dataset containing complete case information, which is a case information list.

[0022] Please refer to Figure 4 As shown, cases are categorized into medical cases, allowance cases, and non-medical cases based on the case type field, specifically including: S401. Preprocess the case description field and extract text fragments containing medical keywords such as "outpatient", "hospitalization" and "surgery" through regular expression matching. If the match is successful, it is determined to be a medical case. S402. Perform an exact match operation on the case type code field. When the code value is “R02” or “R05”, it is directly classified as an allowance case. At the same time, the validity of the code is verified by the preset code mapping table. S403. For non-medical cases, a dual-condition judgment is adopted. First, cases whose case type codes belong to the range of "N01" to "N09" are screened. Then, feature words such as "serious illness" and "disability" are matched through the keyword database. Only cases that meet both the code range condition and the feature word matching condition can be classified. S404. Establish a dynamic verification mechanism for case types, record the classification criteria keywords, code values ​​and matching positions in real time during the classification process, generate a timestamped classification log and store it in the audit trail database to ensure that the classification results are traceable.

[0023] Those skilled in the art will understand that the dual verification of regular expressions and code mapping tables improves the accuracy of medical case identification, ensures zero error in code matching for subsidy cases, and avoids "false positives and false negatives" by using dual conditions to determine non-medical cases. The dynamic verification mechanism generates time-stamped classification logs to meet regulatory requirements for operational traceability. The code mapping table supports real-time updates (such as adding new insurance codes), and the keyword library can be dynamically expanded (such as adding the medical term "organ transplantation") to ensure that the system adapts to future business changes.

[0024] Meaning of the code and reasons for its selection: R02 / R05: R02 is for work injury insurance allowance cases (corresponding to the work injury medical subsidy scenario in the "Work Injury Insurance Regulations"), and R05 is for specific health insurance allowance cases (such as hospitalization allowance for critical illness). These two types of codes are chosen because they are directly related to the allowance payment rules. The code system is derived from the "Insurance Business Code Specification" of the State Financial Supervision and Administration Bureau to ensure industry universality.

[0025] N01-N09 scope: covers 9 major scenarios of non-medical cases (such as N01 critical illness, N02 disability, N03 death, etc.). This scope was chosen because it covers 85% of non-medical case types in insurance claims. The code design follows the "category-subcategory" hierarchical coding rule (such as N0101 acute myocardial infarction, N0102 malignant tumor), which is convenient for expanding sub-types.

[0026] Please refer to Figure 5 As shown, a fairness algorithm is used to prioritize assigning cases to employee numbers with the fewest cases. Specifically, this includes: S501. By accessing the claims personnel's case database in real time, using SQL dynamic query statements, the total number of cases currently being handled by each person is counted and a case volume sorting list is generated. S502. When multiple personnel are detected to have the same number of cases, the timeliness indicator comparison module is triggered. This module calculates the average processing time by extracting historical case processing records. The timeliness indicator adopts a weighted scoring model for quantitative comparison. S503. Based on the sorting results, select the single person with the fewest cases and the highest timeliness score as the first choice for allocation. If there are multiple candidates with the same score, start the random round-robin allocator. The allocator generates a random sequence number and dynamically adjusts the priority of the candidates according to the preset round-robin period to ensure that each candidate is selected only once in n consecutive allocations, where n is the total number of candidates. S504. The allocation decision process is recorded in real time to the fairness algorithm execution log. The log includes allocation time, employee number, case number and decision basis parameters, and a log check code is generated by a hash algorithm to ensure data integrity.

[0027] The formula for the weighted scoring model is: ; in, To ensure timely processing, For the time when the case is completed, Allocate time for the case. The total number of cases, These are the weighting coefficients.

[0028] Please refer to Figure 6 As shown, a case allocation log is generated after the allocation is completed, which specifically includes: S601. Extract the case number field from the case information database, combine it with the system timestamp to automatically generate an allocation time record, and associate it with the employee number data of the receiving personnel output by the allocation decision module to form a basic log entry. S602. Based on the output of the case type classification module, add standardized case type labels to the basic log entries, and embed a fairness algorithm version identifier. This identifier is dual-encoded with semantic version number format and algorithm parameter hash value to form a complete log entry. S603. Perform structured processing on the complete log entries to generate a JSON transaction package that conforms to the data format, and generate a case allocation log.

[0029] The synchronization steps for the personnel scheduling menu include: The allocation result data is written to the scheduling system database in JSON format through the preset RESTful API interface. The data fields include case number, allocation timestamp, receiving employee ID and case type label. Data integrity verification is performed before writing, including case number uniqueness check, employee ID validity verification and timestamp format verification. When the real-time message push notification of the dispatch system is triggered, a long connection channel is established using the WebSocket protocol. The allocation result is encapsulated into a structured message body, which includes basic case information, allocation decision basis and processing priority identifier. The message body is pushed to the client device corresponding to the recipient and triggers an interface pop-up reminder. When automatically creating case processing task cards in the scheduling menu, the system uses a front-end framework dynamic rendering component library to match preset task card templates based on case type tags, fills in dynamic fields such as case number, receiving personnel, and processing time limit, and embeds a processing progress tracking bar and timeout warning function module. After the task card is generated, it is synchronously updated to the scheduling system database.

[0030] Monitor the effects of allocation and automatically adjust the allocation strategy, specifically including: The performance monitoring agents deployed at each node of the claims system collect case processing time data in real time. This data includes case allocation time, initial processing time, final completion time, and time consumed at each node. The data is stored in a time-series database and a baseline model of processing time is constructed. Based on the baseline model, a daily allocation fairness assessment report is dynamically generated. The report includes the distribution of average case processing time per person, the coefficient of difference in case volume, and the efficiency index of the fairness algorithm. Heat maps and trend curves are generated through a data visualization engine to assist in the analysis. When it is detected that a person's processing time is lower than the preset threshold, the preset threshold is dynamically adjusted based on historical data, using the 3σ rule combined with seasonal factors for correction. Furthermore, by analyzing the reasons for the timeliness bottleneck (such as staff workload and case complexity), the allocation strategy parameters are dynamically adjusted, and the adjustment records and effect feedback are written into the monitoring log to form a closed-loop optimization mechanism.

[0031] In a second aspect of the invention, an RPA-based claims allocation system is also provided, comprising: The login module is used to simulate human operation and log in to the claims platform of the system via an RPA robot. The acquisition module is used to execute the query command for pending tasks in the claims platform and obtain a list of case information. The classification module is used to classify cases into medical cases, allowance cases, and non-medical cases based on the case type field. Non-medical cases include serious illnesses, disabilities, etc. The allocation module is used to prioritize the allocation of cases to the employee number with the fewest cases based on the real-time case volume database of each claims personnel and using a fairness algorithm. The scheduling module is used to generate a case allocation log after the allocation is completed and synchronize it to the scheduling menu between personnel; The monitoring module is used to monitor the effects of allocation and automatically adjust the allocation strategy.

[0032] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the claimed invention. The scope of protection claimed by the appended claims and their equivalents is defined.

Claims

1. A claims case allocation method based on RPA, characterized in that, include: Log in to the system's claims platform using an RPA robot to simulate manual operation; Execute the pending task query command in the claims platform to obtain a list of case information; Cases are categorized into medical cases, allowance cases, and non-medical cases based on the case type field. Non-medical cases include serious illnesses and disabilities. Based on the real-time case volume database of each claims personnel, a fairness algorithm is used to prioritize the allocation of cases to the employee number with the fewest cases; After the assignment is completed, a case assignment log is generated and synchronized to the personnel scheduling menu; Monitor the effects of allocation and automatically adjust the allocation strategy.

2. The RPA-based claims allocation method according to claim 1, characterized in that, The process of simulating manual operation by logging into the claims platform using an RPA robot specifically includes: System authentication is completed through a pre-configured encrypted account password library or digital certificate verification module, wherein the encrypted account password library is stored in an AES-256 encrypted manner and transmitted through a secure channel; Automatically capture the image area of ​​the verification code dynamically generated on the login interface, and parse the verification code characters through the recognition module of the FaceID face detection interface engine developed by China Life R&D Center. If the recognition fails, the backup plan is triggered, and the SMS / email interface is called to obtain a second verification code. After successful identity verification, the system automatically redirects users by parsing the main interface of the claims platform and triggering a click event. During the redirection process, the login timestamp and IP address are simultaneously recorded in the audit log database.

3. The RPA-based claims allocation method according to claim 2, characterized in that, The step of executing a pending task query command in the claims platform to obtain a list of case information specifically includes: Initiate an HTTP GET request through the preset system API interface address, carrying the identity token verification parameter, and receive the returned JSON format unprocessed case list data packet; Use a JSON parser to extract core fields such as case number, reporting time, and case type from the data packet, and at the same time verify whether the reporting time field conforms to the YYYY-MM-DD HH:MM:SS format specification; The query results are paginated. First, the current page number, total number of pages, and number of records per page parameters returned by the API are parsed. The API interface is called page by page in a loop iteration until all data is obtained. When merging data from multiple pages, a data deduplication algorithm is used to verify the uniqueness of the case number. Finally, a structured dataset containing complete case information is generated, which is the case information list.

4. The RPA-based claims allocation method according to claim 3, characterized in that, The classification of cases into medical cases, allowance cases, and non-medical cases based on the case type field specifically includes: The case description field is preprocessed, and text fragments containing medical keywords such as "outpatient", "inpatient" and "surgery" are extracted by regular expression matching. If the match is successful, it is determined to be a medical case. Perform an exact match operation on the case type code field. When the code value is "R02" or "R05", it is directly classified as an allowance case. At the same time, the validity of the code is verified by a preset code mapping table. For non-medical cases, a dual-condition judgment is adopted. First, cases with case type codes in the range of "N01" to "N09" are screened. Then, feature words such as "serious illness" and "disability" are matched through the keyword database. Only cases that meet both the code range condition and the feature word matching condition can be classified. Establish a dynamic verification mechanism for case types, record the classification criteria keywords, code values ​​and matching positions in real time during the classification process, generate a timestamped classification log and store it in the audit trail database to ensure that the classification results are traceable.

5. The RPA-based claims allocation method according to claim 4, characterized in that, The adoption of a fairness algorithm to prioritize the allocation of cases to employee numbers with the fewest cases specifically includes: By accessing the claims personnel's case database in real time, the system uses dynamic SQL queries to count the total number of cases currently being handled by each person and generates a sorted list of cases by volume. When multiple individuals are detected to have the same number of cases, the timeliness indicator comparison module is triggered. This module calculates the average processing time by extracting historical case processing records. The timeliness indicator uses a weighted scoring model for quantitative comparison. Based on the sorting results, the single person with the fewest cases and the highest timeliness score is selected as the first choice for allocation. If there are multiple candidates with the same score, the random round-robin allocator is started. The allocator generates a random sequence number and dynamically adjusts the priority of the candidates according to the preset round-robin period to ensure that each candidate is selected only once in n consecutive allocations, where n is the total number of candidates. The allocation decision-making process is recorded in real time to the fairness algorithm execution log. The log includes allocation time, employee number, case number, and decision basis parameters, and a log check code is generated through a hash algorithm to ensure data integrity.

6. The RPA-based claims allocation method according to claim 5, characterized in that, The formula for the weighted scoring model is: ； in, To ensure timely processing, For the time when the case is completed, Allocate time for the case. The total number of cases, These are the weighting coefficients.

7. The RPA-based claims allocation method according to claim 6, characterized in that, The process of generating a case allocation log after allocation is completed includes: The case number field is extracted from the case information database, and the allocation time record is automatically generated by combining it with the system timestamp. The receiving personnel's employee number data output by the allocation decision module is then associated to form basic log entries. Based on the output of the case type classification module, standardized case type labels are added to the basic log entries, and a fairness algorithm version identifier is embedded. This identifier is dual-encoded with semantic version number format and algorithm parameter hash value to form a complete log entry. The complete log entries are structured to generate JSON transaction packages that conform to the data format, and case allocation logs are generated.

8. The RPA-based claims allocation method according to claim 7, characterized in that, The synchronization steps of the personnel scheduling menu specifically include: The allocation result data is written to the scheduling system database in JSON format through the preset RESTful API interface. The data fields include case number, allocation timestamp, receiving employee ID and case type label. Data integrity verification is performed before writing, including case number uniqueness check, employee ID validity verification and timestamp format verification. When the real-time message push notification of the dispatch system is triggered, a long connection channel is established using the WebSocket protocol. The allocation result is encapsulated into a structured message body, which includes basic case information, allocation decision basis and processing priority identifier. The message body is pushed to the client device corresponding to the recipient and triggers an interface pop-up reminder. When automatically creating case processing task cards in the scheduling menu, the system uses a front-end framework dynamic rendering component library to match preset task card templates based on case type tags, fills in dynamic fields such as case number, receiving personnel, and processing time limit, and embeds a processing progress tracking bar and timeout warning function module. After the task card is generated, it is synchronously updated to the scheduling system database.

9. The RPA-based claims allocation method according to claim 8, characterized in that, The monitoring of the post-allocation effect and the automatic adjustment of the allocation strategy specifically include: The performance monitoring agents deployed at each node of the claims system collect case processing time data in real time. This data includes case allocation time, initial processing time, final completion time, and time consumed at each node. The data is stored in a time-series database and a baseline model of processing time is constructed. Based on the baseline model, a daily allocation fairness assessment report is dynamically generated. The report includes the distribution of average case processing time per person, the coefficient of difference in case volume, and the efficiency index of the fairness algorithm. Heat maps and trend curves are generated through a data visualization engine to assist in the analysis. When it is detected that the processing time of a certain person is lower than the preset threshold, the preset threshold is dynamically adjusted according to historical data, using the 3σ rule combined with seasonal factors for correction, and by analyzing the reasons for the timeliness bottleneck (such as staff load, case complexity), the allocation strategy parameters are dynamically adjusted, and the adjustment records and effect feedback are written into the monitoring log to form a closed-loop optimization mechanism.

10. An RPA-based claims allocation system, used to implement the RPA-based claims allocation method as described in any one of claims 1-9, characterized in that, include: The login module is used to simulate human operation and log in to the claims platform of the system via an RPA robot; The acquisition module is used to execute a query command for pending tasks in the claims platform and acquire a list of case information. The classification module is used to classify cases into medical cases, allowance cases, and non-medical cases according to the case type field. The non-medical cases include serious illnesses, disabilities, etc. The allocation module is used to prioritize the allocation of cases to the employee number with the fewest cases based on a real-time case quantity database for each claims personnel and using a fairness algorithm. The scheduling module is used to generate a case allocation log after the allocation is completed and synchronize it to the personnel scheduling menu; The monitoring module is used to monitor the effects of allocation and automatically adjust the allocation strategy.

Images