Dynamic automatic adjustment method and device
Through the combination of dynamic automatic calculation methods and Groovy scripts, the complexity and insufficient performance of claims processing in the insurance industry are solved, and high-flexible automatic calculations are achieved, which improves the efficiency and accuracy of claims processing.
Patent Information
- Application Number
- CN202510023651.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-01-07
- Publication Date
- 2025-05-13
AI Technical Summary
Claim handling in the insurance industry is complex and cumbersome, and traditional manual operations cannot meet the service efficiency of increasing cases and customized requirements.
The dynamic automatic calculation method is adopted to obtain claims data through data entry configuration items and custom extended configuration items, perform standardized processing and multi-layer data verification, and use Groovy scripts to perform calculation processing, and dynamically adjust the script to adapt to changes in insurance terms and claims.
It realizes high-flexible automatic calculation, can adapt to complex and changeable claims requirements, improves the efficiency and accuracy of claims processing, and reduces the cumbersomeness of manual operations.
Smart Images
Figure CN119991307A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of data processing technology, and in particular to a dynamic automatic adjustment method and device. Background Art
[0002] In the insurance industry, claims processing is a complex and tedious process that traditionally relies on a large amount of manual operations and manual calculations. However, in the face of an environment with increasing caseloads and more customized requirements, the problem of insufficient service efficiency has gradually become apparent. Summary of the invention
[0003] The purpose of the embodiments of the present application is to provide a dynamic automatic settlement method and device, which is an automatic settlement system that can adapt to the complex and changeable claims needs of accidental health insurance.
[0004] The first aspect of the present application provides a dynamic automatic adjustment method, comprising:
[0005] Obtain claims data based on data entry configuration items and custom extension configuration items;
[0006] Performing standardization processing on the claims data to obtain standardized data;
[0007] Performing multi-layer data verification on the standardized data to obtain a verification result;
[0008] When the verification result is that the verification is passed, the standardized data is processed by a Groovy script to obtain a calculation result; wherein the Groovy script is used to implement the calculation logic.
[0009] Furthermore, the claim data is standardized to obtain standardized data, including:
[0010] Through the preset search middleware word segmentation engine, the drug expenses, medical treatment expenses, and material expenses recorded in the bill details in the claim data are matched with the data in the preset three-directory library of medical insurance to obtain a matching result;
[0011] Based on the matching results and the received detailed input data, the claim data is standardized.
[0012] Further, the performing multi-layer data verification on the standardized data to obtain the verification result includes:
[0013] Performing image layer verification on the standardized data to obtain a first syndrome result;
[0014] Performing an input-level check on the standardized data to obtain a second check sub-result;
[0015] A verification layer verification is performed on the first syndrome result and the second syndrome result to obtain a verification result.
[0016] Further, performing image layer verification on the standardized data to obtain a first syndrome result includes:
[0017] Check whether the number of bills corresponding to the bill layer in the standardized data is greater than zero; if so, output bill retransmission prompt information.
[0018] Further, performing input-level verification on the standardized data to obtain a second syndrome result includes:
[0019] When the standardized data is an amount field entered by the user, detecting whether the amount field is a numerical type; if not, outputting a prompt message that the amount field needs to be re-entered; or
[0020] When the standardized data is an amount field entered by the user, detecting whether the amount value corresponding to the amount field is greater than or equal to zero; if not, outputting a prompt message indicating that the amount is unreasonable; or
[0021] When the standardized data is a date field entered by the user, detecting whether the date field conforms to the date format; if not, outputting a prompt message that the date needs to be re-entered; or
[0022] When the standardized data is a medical insurance payment voucher, check whether the amount within the medical insurance scope, the amount paid by the medical insurance fund, the self-payment amount 1, the self-payment amount 2, the self-paid amount, and the third-party payment amount pass the logic check; if not, output a prompt message indicating that the logic check has not passed; or
[0023] When the standardized data is certificate information, check whether the certificate expiration date is greater than the date of consultation; if not, output a prompt message indicating that the certificate is invalid; or
[0024] When the standardized data is certificate information, it is detected whether the age segment corresponding to the certificate is consistent with the validity period of the certificate; if not, a prompt message indicating that the data logic is inconsistent is output.
[0025] Furthermore, the data entry configuration item specifies at least one of the conventional data type, entry method, entry format, adopted coding standard, effective time, mandatory requirements, and entry level of the data to be entered;
[0026] The custom extended configuration item specifies at least one of the unconventional data type, entry method, entry format, effective time, entry level, data association information, claim settlement rule association information, and business logic association information of the data to be entered;
[0027] The entry level includes a case level and a bill level.
[0028] Furthermore, the method further comprises:
[0029] When the insurance terms are updated or a special claim situation occurs, the Groovy script is dynamically adjusted based on the updated insurance terms and the details of the special claim situation to obtain a new Groovy script.
[0030] A second aspect of the present application provides a dynamic automatic adjusting device, the dynamic automatic adjusting device comprising:
[0031] An acquisition unit, used to acquire claims data based on data entry configuration items and custom extended configuration items;
[0032] A standardization unit, used for performing standardization processing on the claim data to obtain standardized data;
[0033] A verification unit, used for performing multi-layer data verification on the standardized data to obtain a verification result;
[0034] The calculation unit is used for, when the verification result is a verification pass, performing a calculation process on the standardized data through a Groovy script to obtain a calculation result; wherein the Groovy script is used to implement the calculation logic.
[0035] Furthermore, the standardization unit comprises:
[0036] The matching subunit is used to match the drug expenses, medical treatment expenses, and material expenses recorded in the bill details in the claim data with the data in the preset three-directory library of medical insurance through the preset search middleware word segmentation engine to obtain a matching result;
[0037] The standardization subunit is used to standardize the claim data based on the matching result and the received detailed input data.
[0038] Furthermore, the verification unit includes:
[0039] An image verification subunit, configured to perform image layer verification on the standardized data to obtain a first syndrome result;
[0040] An input check subunit, used to perform input-level check on the standardized data to obtain a second check sub result;
[0041] The verification subunit is used to perform a verification layer verification on the first syndrome result and the second syndrome result to obtain a verification result.
[0042] Furthermore, the image verification subunit is specifically used to detect whether the number of bills corresponding to the bill layer in the standardized data is greater than zero; if so, output a bill retransmission prompt message.
[0043] Furthermore, the input verification subunit is specifically used to detect whether the amount field is a numerical type when the standardized data is an amount field entered by the user; if not, output a prompt message that the amount field needs to be re-entered; or
[0044] When the standardized data is an amount field entered by the user, detecting whether the amount value corresponding to the amount field is greater than or equal to zero; if not, outputting a prompt message indicating that the amount is unreasonable; or
[0045] When the standardized data is a date field entered by the user, detecting whether the date field conforms to the date format; if not, outputting a prompt message that the date needs to be re-entered; or
[0046] When the standardized data is a medical insurance payment voucher, check whether the amount within the medical insurance scope, the amount paid by the medical insurance fund, the self-payment amount 1, the self-payment amount 2, the self-paid amount, and the third-party payment amount pass the logic check; if not, output a prompt message indicating that the logic check has not passed; or
[0047] When the standardized data is certificate information, check whether the certificate expiration date is greater than the date of consultation; if not, output a prompt message indicating that the certificate is invalid; or
[0048] When the standardized data is certificate information, it is detected whether the age segment corresponding to the certificate is consistent with the validity period of the certificate; if not, a prompt message indicating that the data logic is inconsistent is output.
[0049] Furthermore, the data entry configuration item specifies at least one of the conventional data type, entry method, entry format, adopted coding standard, effective time, mandatory requirements, and entry level of the data to be entered;
[0050] The custom extended configuration item specifies at least one of the unconventional data type, entry method, entry format, effective time, entry level, data association information, claim settlement rule association information, and business logic association information of the data to be entered;
[0051] The entry level includes a case level and a bill level.
[0052] Furthermore, the dynamic automatic adjusting device further comprises:
[0053] The script adjustment unit is used to dynamically adjust the Groovy script based on the updated content of the insurance terms and the details of the special claims to obtain a new Groovy script when the insurance terms are updated or special claims occur.
[0054] A third aspect of the present application provides an electronic device, including a memory and a processor, wherein the memory is used to store a computer program, and the processor runs the computer program to enable the electronic device to execute the dynamic automatic adjustment method described in any one of the first aspects of the present application.
[0055] A fourth aspect of the present application provides a computer-readable storage medium storing computer program instructions, wherein when the computer program instructions are read and executed by a processor, the dynamic automatic adjustment method described in any one of the first aspect of the present application is executed.
[0056] The beneficial effects of the present application are as follows: the method and device can provide data support for the Groovy script through data entry configuration items and automatic extension of configuration items, so that the Groovy script can achieve highly flexible automatic settlement, thereby enabling the method and device to adapt to the complex and changeable claims needs of voluntary health insurance. BRIEF DESCRIPTION OF THE DRAWINGS
[0057] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments of the present application will be briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.
[0058] Figure 1 A schematic diagram of a flow chart of a dynamic automatic adjustment method provided in an embodiment of the present application;
[0059] Figure 2 A schematic flow chart of another dynamic automatic adjustment method provided in an embodiment of the present application;
[0060] Figure 3 A schematic diagram of a newly added entry rule provided in an embodiment of the present application;
[0061] Figure 4 An example diagram of a newly added custom extended configuration item provided in an embodiment of the present application;
[0062] Figure 5 An example diagram of a liability adjustment configuration provided in an embodiment of the present application;
[0063] Figure 6 An example diagram of a claimable amount limit script provided in an embodiment of the present application;
[0064] Figure 7 A structural schematic diagram of a dynamic automatic adjustment device provided in an embodiment of the present application;
[0065] Figure 8 A schematic diagram of the structure of another dynamic automatic adjusting device provided in an embodiment of the present application. DETAILED DESCRIPTION
[0066] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application.
[0067] It should be noted that similar reference numerals and letters represent similar items in the following drawings, so once an item is defined in one drawing, it does not need to be further defined and explained in subsequent drawings. At the same time, in the description of this application, the terms "first", "second", etc. are only used to distinguish the description and cannot be understood as indicating or implying relative importance.
[0068] Example 1
[0069] Please see Figure 1 , Figure 1 A schematic flow chart of a dynamic automatic adjustment method provided in this embodiment. The dynamic automatic adjustment method includes:
[0070] S101. Obtain claims data based on data entry configuration items and custom extension configuration items.
[0071] S102: Standardize the claims data to obtain standardized data.
[0072] S103, performing multi-layer data verification on the standardized data to obtain a verification result.
[0073] S104. When the verification result is that the verification is passed, the standardized data is processed by a Groovy script to obtain a calculation result; wherein the Groovy script is used to implement the calculation logic.
[0074] In this embodiment, the execution subject of the method may be a computing device such as a computer or a server, and no limitation is made in this embodiment.
[0075] In this embodiment, the execution subject of the method may also be a smart device such as a smart phone, a tablet computer, etc., which is not limited in this embodiment.
[0076] It can be seen that the implementation of the dynamic automatic settlement method described in this embodiment can provide data support for the Groovy script through data entry configuration items and automatic extension configuration items, so that the Groovy script can achieve highly flexible automatic settlement, thereby being able to adapt to the complex and changeable claims needs of voluntary health insurance.
[0077] Example 2
[0078] Please see Figure 2 , Figure 2 A schematic flow chart of a dynamic automatic adjustment method provided in this embodiment. The dynamic automatic adjustment method includes:
[0079] S201. Obtain claims data based on data entry configuration items and custom extension configuration items.
[0080] In this embodiment, the data entry configuration item specifies at least one of the conventional data type, entry method, entry format, adopted coding standard, effective time, mandatory requirements, and entry level of the data to be entered;
[0081] The custom extended configuration item specifies at least one of the unconventional data type, entry method, entry format, effective time, entry level, data association information, claim settlement rule association information, and business logic association information of the data to be entered;
[0082] The entry levels include case level and bill level.
[0083] In this embodiment, the data entry configuration item is used to define the input method and format of claims data, which determines the rules for claims personnel or systems to obtain data from various channels (such as medical bills, customer declaration information, etc.) and the field information that needs to be collected.
[0084] For example, the entry format of medical expense data is required to be a table containing fixed fields such as date, expense category, amount, etc., or the entry of diagnostic information must be in accordance with the International Classification of Diseases (ICD 10) standards.
[0085] In this embodiment, the data entry configuration items support configuration according to the underwriting institution, claim type, major category of insurance, sub-type of insurance, amount and effective time, etc. (wherein, the data entry configuration items can be understood as the content in the entry rules, and the above-mentioned underwriting institution, claim type, major category of insurance, sub-type of insurance, amount and effective time are labels of the entry rules; specifically, the data entry configuration items refer to how and what data should be entered under the entry rules).
[0086] In this embodiment, the data entry configuration items may include report information, accident information, payment information, death / total disability information, disability information, serious illness information, case-level hospital information, bill information, hospital information, disease information, project expenses, and detailed information level. At the same time, the data entry configuration items may further set rules for field selection and whether or not fields are required.
[0087] Please see Figure 3 , Figure 3A schematic diagram of a newly added entry rule is shown, wherein the diagram shows some data entry configuration items and the corresponding labels of the entry rule.
[0088] In this embodiment, the custom extended configuration item is an additional configuration item defined by the user (such as an insurance product developer or a claim rule maker) according to the specific health insurance product and claim scenario. In this configuration item, the field may be a special clause requirement in the insurance contract, or additional information for a specific customer group or risk factor.
[0089] For example, for a voluntary health insurance product that includes health management services, a custom extended configuration item of "number of times the health management service is used" can be defined; for accident insurance involving occupational risks, a custom extended configuration item of "occupational category risk coefficient" can be defined; when the default fixed fields collected based on the data entry configuration items cannot meet the settlement field requirements of the current setting rules (such as some insurance policies require that the compensation ratio of special needs wards is inconsistent with that of ordinary wards, or the registration fee type is associated with the claim formula; among them, the registration fee categories include expert registration, special needs registration, chief physician registration, deputy chief physician registration fees, etc.), this method can add custom extended configuration items to enable it to prompt for obtaining more custom fields to meet business requirements.
[0090] Among them, the custom extended configuration item can include configuration level (i.e. case level and bill level), configuration field name, and input type of bound field (i.e. input box, selection box, text box and date box, where the selection box can be set to single choice and multiple choice), and configuration option information (i.e. field selection rules and whether it is required).
[0091] Please see Figure 4 , Figure 4 An example diagram of adding a custom extended configuration item is shown. The diagram directly illustrates that when configuring a custom extended configuration item, it is necessary to specifically add / edit a custom field of the custom extended configuration item heavy crossbow.
[0092] In this embodiment, the custom fields in the custom extension configuration items are associated with the standard fields in the data entry configuration. For example, the "number of times the health management service is used" field may be related to the calculation of the claim amount, and its value may be determined based on the customer's medical records (collected through the data entry configuration) and the compensation rules for health management services in the insurance contract. Through this association, the custom fields are integrated into the entire claim data system, providing more abundant variables and parameters for the Groovy script.
[0093] S202. Match the drug costs, medical treatment costs, and material costs recorded in the bill details in the claim data with the data in the preset three-directory library of medical insurance through the preset search middleware word segmentation engine to obtain a matching result.
[0094] S203: Based on the matching results and the received detailed input data, the claims data is standardized.
[0095] In this embodiment, the method can match the drug, medical treatment, and material costs in the bill details with the medical insurance catalog data of each region through an open search middleware word segmentation engine, add detailed entry matching based on the data at the bill level, and allow manual correction of erroneous information.
[0096] S204: Perform image-level verification on the standardized data to obtain a first syndrome result.
[0097] As an optional implementation, performing image layer verification on the standardized data to obtain a first syndrome result includes:
[0098] Check whether the number of bills corresponding to the bill layer in the standardized data is greater than zero; if so, output the bill retransmission prompt information.
[0099] In this embodiment, the method can verify data at the image layer, input layer, review layer and other levels to ensure that the data in the settlement process can meet the basic data requirements, and at the same time use the three catalog libraries of medical insurance in each region to correct and process the data, thereby achieving data standardization.
[0100] In this embodiment, when the image layer is verified as non-case layer (ie, bill layer) adjustment, the number of bills must be greater than 0.
[0101] S205: Perform input-level verification on the standardized data to obtain a second verification sub-result.
[0102] As an optional implementation, performing an input-level check on the standardized data to obtain a second syndrome result includes:
[0103] When the standardized data is an amount field entered by the user, check whether the amount field is a numeric type; if not, output a prompt message that the amount field needs to be re-entered; or
[0104] When the standardized data is an amount field entered by the user, check whether the amount value corresponding to the amount field is greater than or equal to zero; if not, output a prompt message indicating that the amount is unreasonable; or
[0105] When the standardized data is a date field entered by the user, check whether the date field conforms to the date format; if not, output a prompt message that the date needs to be re-entered; or
[0106] When the standardized data is a medical insurance payment voucher, check whether the amount within the medical insurance scope, the amount paid by the medical insurance fund, the self-payment amount 1, the self-payment amount 2, the self-paid amount, and the third-party payment amount pass the logic check; if not, output a prompt message indicating that the logic check failed; or
[0107] When the standardized data is certificate information, check whether the certificate expiration date is greater than the date of consultation; if not, output a prompt message indicating that the certificate is invalid; or
[0108] When the standardized data is certificate information, check whether the age segment corresponding to the certificate is consistent with the validity period of the certificate; if not, output a prompt message that the data logic is inconsistent.
[0109] In this embodiment, the method can perform data verification according to the configured rules during the data entry process. For example, check whether the amount field is a numeric type, whether the date field conforms to the date format, etc. For data that does not meet the requirements, pre-processing is performed to prompt the user to re-enter or automatically correct it.
[0110] In this embodiment, when collecting data, it is required that the expiration date of the certificate is greater than the date of medical consultation when entering, and when applying for the certificate, the age segment is verified with the certificate validity period data.
[0111] In this embodiment, the claimable amount, the reduced amount, and the actual compensation amount of the payment liability are greater than or equal to 0.
[0112] In this embodiment, the method can also perform logical verification on the amount within the medical insurance scope, the amount paid by the medical insurance fund, the self-payment one, the self-payment two, the self-paid amount, and the third-party payment amount of the entered new rural cooperative medical care, other social insurance payments, and medical insurance reimbursement receipts.
[0113] S206: Perform a verification layer verification on the first syndrome result and the second syndrome result to obtain a verification result.
[0114] S207. When the verification result is that the verification is passed, the standardized data is processed by a Groovy script to obtain a calculation result; wherein the Groovy script is used to implement the calculation logic.
[0115] In this embodiment, the Groovy script uses the standardized data input provided by the data entry configuration. The Groovy script writes the calculation logic corresponding to the settlement rules of the insurance product.
[0116] For example, if the insurance contract stipulates that the compensation amount is the total medical expenses multiplied by a coefficient determined according to the customer's health status (the coefficient is obtained through custom field configuration), the Groovy script can implement such calculation logic.
[0117] It can be seen that Groovy scripts can flexibly handle various complex conditional judgments and calculations, such as determining the compensation ratio and amount based on different disease types, treatment methods, customer risk levels and other factors.
[0118] Please see Figure 5 , Figure 5 An example diagram showing a liability adjustment configuration.
[0119] As an optional implementation, the method further includes:
[0120] When the insurance terms are updated or a special claim situation occurs, the Groovy script is dynamically adjusted based on the updated insurance terms and the details of the special claim situation to obtain a new Groovy script.
[0121] In this embodiment, the Groovy script can be dynamically adjusted according to the update of insurance terms or special claims. When the settlement rules of the insurance product change, such as adding a new disease compensation condition or modifying the calculation method of the compensation ratio, it is only necessary to modify the corresponding logic in the Groovy script.
[0122] It can be seen that this dynamism enables the settlement system to quickly adapt to changes in business rules, unlike the traditional fixed formula system that requires the entire settlement process to be redesigned.
[0123] Please see Figure 6 , Figure 6 An example diagram of a claimable amount limit script is shown.
[0124] In this embodiment, the execution subject of the method may be a computing device such as a computer or a server, and no limitation is made in this embodiment.
[0125] In this embodiment, the execution subject of the method may also be a smart device such as a smart phone, a tablet computer, etc., which is not limited in this embodiment.
[0126] It can be seen that the implementation of the dynamic automatic settlement method described in this embodiment can ensure the accurate collection and preliminary standardization of claims data through data entry configuration; at the same time, it can also add personalized information according to business needs and associate it with standard data through custom extension configuration; finally, the Groovy script can use this data to perform complex settlement calculations and logical judgments and output the final settlement results. Among them, the data entry configuration and custom extension configuration provide data support for the Groovy script, and the Groovy script implements highly flexible settlement logic. They work together to realize an automatic settlement method that adapts to the complex and changeable claims needs of voluntary health insurance.
[0127] Example 3
[0128] Please see Figure 7 , Figure 7 The following is a schematic diagram of the structure of a dynamic automatic adjustment device provided in this embodiment. Figure 7 As shown, the dynamic automatic adjusting device includes:
[0129] An acquisition unit 310, configured to acquire claim data based on data entry configuration items and user-defined extension configuration items;
[0130] A standardization unit 320 is used to perform standardization processing on the claim data to obtain standardized data;
[0131] The verification unit 330 is used to perform multi-layer data verification on the standardized data to obtain a verification result;
[0132] The calculation unit 340 is used to calculate the standardized data through the Groovy script to obtain the calculation result when the verification result is passed; wherein the Groovy script is used to implement the calculation logic.
[0133] In this embodiment, the explanation of the dynamic automatic adjusting device can refer to the description in Embodiment 1 or Embodiment 2, and will not be further described in this embodiment.
[0134] It can be seen that the dynamic automatic settlement device described in this embodiment can provide data support for Groovy scripts through data entry configuration items and automatic extension configuration items, so that the Groovy scripts can achieve highly flexible automatic settlement, thereby being able to adapt to the complex and changeable claims needs of voluntary health insurance.
[0135] Example 4
[0136] Please see Figure 8 , Figure 8 The following is a schematic diagram of the structure of a dynamic automatic adjustment device provided in this embodiment. Figure 8 As shown, the dynamic automatic adjusting device includes:
[0137] An acquisition unit 310, configured to acquire claim data based on data entry configuration items and user-defined extension configuration items;
[0138] A standardization unit 320 is used to perform standardization processing on the claim data to obtain standardized data;
[0139] The verification unit 330 is used to perform multi-layer data verification on the standardized data to obtain a verification result;
[0140] The calculation unit 340 is used to calculate the standardized data through the Groovy script to obtain the calculation result when the verification result is passed; wherein the Groovy script is used to implement the calculation logic.
[0141] As an optional implementation, the standardization unit 320 includes:
[0142] The matching subunit 321 is used to match the drug costs, medical treatment costs, and material costs recorded in the bill details in the claim data with the data in the preset three-directory library of medical insurance through the preset search middleware word segmentation engine to obtain a matching result;
[0143] The standardization subunit 322 is used to standardize the claim data based on the matching results and the received detailed input data.
[0144] As an optional implementation, the verification unit 330 includes:
[0145] An image check subunit 331 is used to perform image layer check on the standardized data to obtain a first check subresult;
[0146] An input check subunit 332, used to perform input layer check on the standardized data to obtain a second check sub result;
[0147] The verification check subunit 333 is used to perform a verification layer verification on the first syndrome result and the second syndrome result to obtain a verification result.
[0148] As an optional implementation, the image verification subunit 331 is specifically used to detect whether the number of bills corresponding to the bill layer in the standardized data is greater than zero; if so, output a bill retransmission prompt message.
[0149] As an optional implementation, the input verification subunit 332 is specifically used to detect whether the amount field is a numeric type when the standardized data is an amount field entered by the user; if not, output a prompt message that the amount field needs to be re-entered; or
[0150] When the standardized data is an amount field entered by the user, check whether the amount value corresponding to the amount field is greater than or equal to zero; if not, output a prompt message indicating that the amount is unreasonable; or
[0151] When the standardized data is a date field entered by the user, check whether the date field conforms to the date format; if not, output a prompt message that the date needs to be re-entered; or
[0152] When the standardized data is a medical insurance payment voucher, check whether the amount within the medical insurance scope, the amount paid by the medical insurance fund, the self-payment amount 1, the self-payment amount 2, the self-paid amount, and the third-party payment amount pass the logic check; if not, output a prompt message indicating that the logic check failed; or
[0153] When the standardized data is certificate information, check whether the certificate expiration date is greater than the date of consultation; if not, output a prompt message indicating that the certificate is invalid; or
[0154] When the standardized data is certificate information, check whether the age segment corresponding to the certificate is consistent with the validity period of the certificate; if not, output a prompt message that the data logic is inconsistent.
[0155] In this embodiment, the data entry configuration item specifies at least one of the conventional data type, entry method, entry format, adopted coding standard, effective time, mandatory requirements, and entry level of the data to be entered;
[0156] The custom extended configuration item specifies at least one of the unconventional data type, entry method, entry format, effective time, entry level, data association information, claim settlement rule association information, and business logic association information of the data to be entered;
[0157] The entry levels include case level and bill level.
[0158] As an optional implementation, the dynamic automatic adjusting device further includes:
[0159] The script adjustment unit 350 is used to dynamically adjust the Groovy script based on the updated content of the insurance terms and the details of the special claims settlement to obtain a new Groovy script when the insurance terms are updated or a special claims settlement situation occurs.
[0160] In this embodiment, the explanation of the dynamic automatic adjusting device can refer to the description in Embodiment 1 or Embodiment 2, and will not be further described in this embodiment.
[0161] It can be seen that the dynamic automatic settlement device described in this embodiment can provide data support for Groovy scripts through data entry configuration items and automatic extension configuration items, so that the Groovy scripts can achieve highly flexible automatic settlement, thereby being able to adapt to the complex and changeable claims needs of voluntary health insurance.
[0162] An embodiment of the present application provides an electronic device, including a memory and a processor, wherein the memory is used to store a computer program, and the processor runs the computer program to enable the electronic device to execute the dynamic automatic adjustment method in Embodiment 1 or Embodiment 2 of the present application.
[0163] An embodiment of the present application provides a computer-readable storage medium storing computer program instructions. When the computer program instructions are read and executed by a processor, the dynamic automatic adjustment method in Embodiment 1 or Embodiment 2 of the present application is executed.
[0164] In several embodiments provided in the present application, it should be understood that the disclosed devices and methods can also be implemented in other ways. The device embodiments described above are merely schematic. For example, the flowcharts and block diagrams in the accompanying drawings show the possible architecture, functions and operations of the devices, methods and computer program products according to multiple embodiments of the present application. In this regard, each box in the flowchart or block diagram can represent a module, a program segment or a part of a code, and the module, a program segment or a part of a code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two consecutive boxes can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, and the combination of boxes in the block diagram and / or flowchart can be implemented with a dedicated hardware-based system that performs a specified function or action, or can be implemented with a combination of dedicated hardware and computer instructions.
[0165] In addition, the functional modules in the various embodiments of the present application may be integrated together to form an independent part, or each module may exist separately, or two or more modules may be integrated to form an independent part.
[0166] If the functions are implemented in the form of software function modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application can be essentially or partly embodied in the form of a software product that contributes to the prior art. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.
[0167] The above description is only an embodiment of the present application and is not intended to limit the scope of protection of the present application. For those skilled in the art, the present application may have various changes and variations. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application should be included in the scope of protection of the present application. It should be noted that similar reference numerals and letters represent similar items in the following drawings, so once an item is defined in one drawing, it does not need to be further defined and explained in the subsequent drawings.
[0168] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.
[0169] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or device including the elements.
Claims
1. A dynamic automatic adjustment method, characterized in that: include: Obtain claims data based on data entry configuration items and custom extension configuration items; Performing standardization processing on the claims data to obtain standardized data; Performing multi-layer data verification on the standardized data to obtain a verification result; When the verification result is that the verification is passed, the standardized data is processed by a Groovy script to obtain a calculation result; wherein the Groovy script is used to implement the calculation logic.
2. The dynamic automatic adjustment method according to claim 1, characterized in that: The step of performing standardization processing on the claim data to obtain standardized data includes: Through the preset search middleware word segmentation engine, the drug expenses, medical treatment expenses, and material expenses recorded in the bill details in the claim data are matched with the data in the preset three-directory library of medical insurance to obtain a matching result; Based on the matching results and the received detailed input data, the claim data is standardized.
3. The dynamic automatic adjustment method according to claim 1, characterized in that: The performing multi-layer data verification on the standardized data to obtain a verification result includes: Performing image layer verification on the standardized data to obtain a first syndrome result; Performing an input-level check on the standardized data to obtain a second check sub-result; A verification layer verification is performed on the first syndrome result and the second syndrome result to obtain a verification result.
4. The dynamic automatic adjustment method according to claim 3, characterized in that: The performing image layer verification on the standardized data to obtain a first syndrome result includes: Check whether the number of bills corresponding to the bill layer in the standardized data is greater than zero; if so, output bill retransmission prompt information.
5. The dynamic automatic adjustment method according to claim 3, characterized in that: The performing an input-level check on the standardized data to obtain a second syndrome result includes: When the standardized data is an amount field entered by the user, detecting whether the amount field is a numerical type; if not, outputting a prompt message that the amount field needs to be re-entered; or When the standardized data is an amount field entered by the user, detecting whether the amount value corresponding to the amount field is greater than or equal to zero; if not, outputting a prompt message indicating that the amount is unreasonable; or When the standardized data is a date field entered by the user, detecting whether the date field conforms to the date format; if not, outputting a prompt message that the date needs to be re-entered; or When the standardized data is a medical insurance payment voucher, check whether the amount within the medical insurance scope, the amount paid by the medical insurance fund, the self-payment amount 1, the self-payment amount 2, the self-paid amount, and the third-party payment amount pass the logic check; if not, output a prompt message indicating that the logic check has not passed; or When the standardized data is certificate information, check whether the certificate expiration date is greater than the date of consultation; if not, output a prompt message indicating that the certificate is invalid; or When the standardized data is certificate information, it is detected whether the age segment corresponding to the certificate is consistent with the validity period of the certificate; if not, a prompt message indicating that the data logic is inconsistent is output.
6. The dynamic automatic adjustment method according to claim 1, characterized in that: The data entry configuration item specifies at least one of the conventional data type, entry method, entry format, adopted coding standard, effective time, mandatory requirements, and entry level of the data to be entered; The custom extended configuration item specifies at least one of the unconventional data type, entry method, entry format, effective time, entry level, data association information, claim settlement rule association information, and business logic association information of the data to be entered; The entry level includes a case level and a bill level.
7. The dynamic automatic adjustment method according to claim 1, characterized in that: The method further comprises: When the insurance terms are updated or a special claim situation occurs, the Groovy script is dynamically adjusted based on the updated insurance terms and the details of the special claim situation to obtain a new Groovy script.
8. A dynamic automatic adjusting device, characterized in that: The dynamic automatic adjusting device comprises: An acquisition unit, used to acquire claims data based on data entry configuration items and custom extended configuration items; A standardization unit, used for performing standardization processing on the claim data to obtain standardized data; A verification unit, used for performing multi-layer data verification on the standardized data to obtain a verification result; The calculation unit is used for, when the verification result is a verification pass, performing a calculation process on the standardized data through a Groovy script to obtain a calculation result; wherein the Groovy script is used to implement the calculation logic.
9. An electronic device, characterized in that: The electronic device comprises a memory and a processor, the memory is used to store a computer program, and the processor runs the computer program to enable the electronic device to perform the dynamic automatic adjusting method according to any one of claims 1 to 7.
10. A readable storage medium, characterized in that: The readable storage medium stores computer program instructions, and when the computer program instructions are read and executed by a processor, the dynamic automatic adjustment method according to any one of claims 1 to 7 is executed.