WO2018188505A1 - 理赔案件处理方法、装置、终端设备及介质 - Google Patents

理赔案件处理方法、装置、终端设备及介质 Download PDF

Info

Publication number
WO2018188505A1
WO2018188505A1 PCT/CN2018/081825 CN2018081825W WO2018188505A1 WO 2018188505 A1 WO2018188505 A1 WO 2018188505A1 CN 2018081825 W CN2018081825 W CN 2018081825W WO 2018188505 A1 WO2018188505 A1 WO 2018188505A1
Authority
WO
WIPO (PCT)
Prior art keywords
case
information
target
report
type
Prior art date
Application number
PCT/CN2018/081825
Other languages
English (en)
French (fr)
Inventor
梁效栋
周鹏
朱瑾
Original Assignee
平安科技（深圳）有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 平安科技（深圳）有限公司 filed Critical 平安科技（深圳）有限公司
Publication of WO2018188505A1 publication Critical patent/WO2018188505A1/zh

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/08—Insurance

Definitions

  • the present application belongs to the field of information processing technology, and in particular, to a method, device, terminal device and medium for processing a claim case.
  • the embodiment of the present application provides a method, a device, a terminal device, and a medium for processing a claim case, so as to solve the problem that the entry process of the existing claims processing process requires a large amount of time cost and low efficiency.
  • a first aspect of the embodiments of the present application provides a method for processing a claim case, including:
  • a second aspect of the embodiment of the present application provides a claim case processing apparatus, the claim case processing apparatus comprising a module for executing the claim case processing method of the first aspect.
  • a third aspect of the embodiments of the present application provides a terminal device, including a memory and a processor, where the computer stores computer readable instructions executable on the processor, the processor executing the computer
  • the steps of the claim case processing method as described in the first aspect are implemented when the command is read.
  • a fourth aspect of the embodiments of the present application provides a computer readable storage medium storing computer readable instructions, the computer readable instructions being executed by a processor to implement the first aspect as described in the first aspect The steps of the method of processing claims.
  • the embodiment of the present application after the requester reports and accepts the case, the case template corresponding to the report information is selected, and the related information is quickly extracted and input through the direct connection of the data, thereby generating a case and performing automatic review and processing, and finally giving relevant review. result. It can be seen that the embodiment of the present application reduces the time cost of the entry process, greatly improves the efficiency of entering the relevant information of the case, and thus indirectly improves the settlement efficiency of the claim case.
  • FIG. 1 is a flow chart of an embodiment of a method for processing a claim case according to an embodiment of the present application
  • FIG. 2 is a schematic flowchart of a method for extracting key information of a case in a claim case processing method according to an embodiment of the present application
  • FIG. 3 is a schematic flowchart of a process for calculating a claim payment according to a method for processing a claims case according to an embodiment of the present application;
  • FIG. 4 is a schematic flowchart of a step 302 of a claim processing method in an application scenario in the corresponding embodiment of FIG. 3;
  • FIG. 5 is a schematic flowchart of step 303 of a claim case processing method in an application scenario in the corresponding embodiment of FIG. 3;
  • FIG. 6 is a schematic flowchart of a claim case processing method step 505 in an application scenario in the corresponding embodiment of FIG. 5;
  • FIG. 7 is a structural block diagram of a claim case processing apparatus according to an embodiment of the present application.
  • FIG. 8 is a schematic diagram of a terminal device according to an embodiment of the present application.
  • an embodiment of a method for processing a claim case in the embodiment of the present application includes:
  • the claim when the requester needs to make a claim, the claim may be sent to the insurance company's system, and after the system obtains the claim report request and accepts the report, the report information in the claim report request is obtained.
  • the report information may include information such as the identity of the requester, the policy requesting the claim, the time of occurrence of the event requesting the claim, the place of occurrence, and the general situation of the event.
  • a plurality of case templates are preset, and the case templates are used to input related case information of the claim report request. Since different types of cases often need to enter different fields (attributes), different case templates correspond to different case types. Before entering the case information, the case type needs to be determined first, so that the corresponding case template is selected.
  • the corresponding case type can be determined based on the report information. For example, if there are related attributes or fields such as medical expenses, diseases, treatments, etc. in the report information, it can be determined that the corresponding case type is a medical case.
  • step 102 may specifically determine the type of the case by using the following two methods: mode one and mode two, respectively.
  • Manner 1 The back-end database of the insurance company may be queried first to determine the type of the insurance policy corresponding to the report information, and then the case type corresponding to the report information is determined according to the insurance type.
  • the report information may include a policy for requesting a claim, and after the policy requesting the claim in the report information is a valid policy, the insurance policy of the valid policy may be known. Since the insurance type often corresponds to the case type at the time of design, the case type corresponding to the report information can be determined according to the type of insurance.
  • the value of the preset keyword attribute may be extracted from the report information; then, the extracted value of the keyword attribute is compared with the attribute value of each case type in the preset case type set. Matching, selecting a case type with the highest matching degree as the case type corresponding to the report information. It can be understood that for each case type in the case type set, the attribute value is set in advance for each case type.
  • the value of the keyword attribute extracted from the report information also includes “medical expenses", " In the case of "disease” and “treatment”, the value of the extracted keyword attribute is successfully matched with the attribute value of the case type of the "medical case", and the degree of matching is higher than that of other case types, then the "medical”
  • the case type of the case is determined as the type of case corresponding to the report information.
  • the corresponding field of the report information is generally set correspondingly.
  • the mandatory field generally includes: name, ID number, customer number, policy number, accident date, type of accident, cause of the accident, bill number, bill amount, hospital for treatment, type of treatment, etc. Therefore, when extracting the value of the keyword attribute of the report information, the main must be extracted for these mandatory fields.
  • the attribute values of each case type are mostly set with reference to the above-mentioned mandatory field to ensure that any type of report information can be selected from the preset case type set to a high degree of matching. Type of case.
  • the step 103 it can be known from the above that different case templates correspond to different case types. Therefore, after determining the type of the case corresponding to the report information, one of the preset case templates may be selected according to the determined case type.
  • the case template is used as the target template.
  • case template in this embodiment may specifically be an excel form template.
  • Each column in the excel form template represents a certain field (attribute) of a certain type of case, and each line represents a piece of report information.
  • attribute attribute
  • each line represents a piece of report information.
  • each column in the excel table represents a field (attribute) of a certain type of case
  • each line represents a piece of report information. Therefore, an input excel table can store multiple rows of data at the same time, and each row of data can generate a corresponding claim case. In this way, when the excel form is uploaded to the insurance company's case generation system, the function of uploading multiple claims cases in batches can be realized.
  • the case key information in this embodiment refers to the information specified in the target template that needs to be entered and does not belong to the report information.
  • the report information often includes the policy number, but does not include the information such as the total insured amount, the remaining insured amount, and the agreed liability of the policy number.
  • the information is required to generate the claim case and belongs to the key information of the case.
  • the key information of the case may be extracted from the back-end database of the insurance company and/or the preset docking system according to the report information by using data direct connection.
  • the report information is used as index information required for extraction.
  • the report information generally includes the policy number, and may also include the identity information of the requester.
  • the relevant case key information is extracted from the background data of the insurance company.
  • the key information of the case can be extracted by the following steps:
  • step 202 determining whether the extracted key information of the case is complete, and if so, executing the above step 104, and if not, executing step 203;
  • the key information of the required case can be preferentially extracted in the back-end database of the insurance company. If the key information of the extracted case is complete, the entry process of the above step 104 can be performed; if the key information of the extracted case is incomplete, Then, the corresponding missing portion is extracted from the docked system, and after the missing portion is extracted, step 104 is performed.
  • the key information of the extracted case when the key information of the extracted case is incomplete, it may be determined which type of information the missing part of the key information of the case belongs to, and then the missing part is extracted from the corresponding docking system.
  • the preset docking system can periodically update the case key information of the relevant insurer belonging to the insurance company to the back-end database of the insurance company.
  • the hospital system transmits the patient's identity information, the type of treatment (outpatient or hospitalization), and the time of the visit to the insurance company's system.
  • the insurance company system determines whether the patient is A valid customer of the insurance company. After verification by means of identity verification, diagnosis type verification, verification policy and personnel range, all patients who pass the above verification will be judged as effective customers of the insurance company.
  • the hospital system updates the billing data of the actual customer's actual visit and other related information to the back-end database of the insurance company through the data direct connection port.
  • the case key information of the patient can be extracted from the background database.
  • the obtained report file may be uploaded to the case generation system of the insurance company to generate a corresponding target case.
  • a report file can include case information for multiple claims cases, so multiple claims cases (ie, target cases) can be generated based on a report file through the case generation system.
  • the case generation system can perform related verification on the report file. For example, check if the file content is empty, whether the file naming format contains special characters, and so on. For the report file that meets the verification rules, the case generation system will prompt the upload of the report file successfully and generate the corresponding upload batch number. The claims case generated by the same report file will be used as the target case under the batch, and the target cases of the same batch can be transferred together.
  • the case generation system performs related verification on the report file, which may include: automatically parsing data of each case in the report file, reading the value of the corresponding field in the parsed data, and adopting a preset rule pair. The value read is verified. For example, “Is the admission time later than the current time?", "Is the discharge time later than the current time?” For the successful case data, the subsequent steps are executed to generate the corresponding target case; and for the check failure button, the failure reason can be written into the feedback text, and the feedback text is sent to upload the report file. Terminal or system.
  • step 106 the target case is reviewed according to a preset audit rule, if the approval is passed, step 107 is performed, and if the review fails, step 108 is performed;
  • the target case After the target case is generated, the target case enters the review process of the claim process. In the review process, if the review is passed, step 107 is performed, and if the review fails, step 108 is performed.
  • the review of the target case in the above step 106 may include two parts, namely, a risk control review part and a remaining insurance amount review part.
  • the credit information of the target person corresponding to the target case may be obtained from the docking credit information system; and then, according to the risk information of the risk person and the preset risk control rule, the target is The case is subjected to a risk assessment to obtain a risk level of the target case; if the risk level of the target case is higher than a preset risk control level threshold, it may be determined that the review of the target case is not passed.
  • a higher risk level can be set for the target case of the risk person who has fraud risk, administrative negative risk, and other risk behaviors in the credit information, so that When the risk level exceeds the preset risk control level threshold, it can be determined that the target case review fails.
  • the remaining insurance amount corresponding to the valid policy of the target case may be obtained from the back-end database of the insurance company. If the remaining insurance amount is 0, it is determined that the review of the target case fails. It can be understood that when the remaining insured amount is 0, the target case has no claims for the claimable amount, and the claim can be directly refused, so it can be determined that the target case is not approved.
  • the process of calculating the claim for the target case in the foregoing step 107 may specifically include:
  • step 301 it can be understood that after the insurance company system accepts and generates related claims cases, the bills of these cases can be saved in the back-end database of the insurance company. Therefore, each bill of the target case can be obtained through the back-end database of the insurance company.
  • the claim liability generally agreed in the policy of the case is differentiated according to different scenarios.
  • the insured vehicle is also damaged.
  • the responsibility for the auto insurance policy is different in different scenarios.
  • the damage event is the responsibility of the auto insurance policy; if the vehicle is damaged under the scene of force majeure (such as flood or typhoon), this time The damage event is not the responsibility of the auto insurance policy. Therefore, before calculating the claim, it is necessary to determine the respective payout scenarios of the target case, and then subdivide and calculate the respective claims amount according to different scenarios.
  • the scene to be paid is the scene within the scope of responsibility of the corresponding policy corresponding to the target case.
  • the foregoing step 302 may include:
  • a target case mostly has multiple bills, which may have different billing dates, types, consumption areas, etc., therefore, these billing rules can be grouped and grouped according to these billing attribute setting grouping rules. , thereby dividing multiple bills into more than one billing group.
  • the corresponding bill is a medical bill, and the same day group visit, the same type of treatment, the same disease type, and the same hospital can be used as the same billing group.
  • Each billing team is a sub-case of the target case. Sub-cases are used as calculation dimensions in subsequent steps.
  • the first attribute type may be set according to different sub-cases, for example, may include an accident nature, a refinement governance type, a risk location, etc., and the attribute values of the first attribute types may pass case information of the target case. And billing information is obtained or generated.
  • the second attribute type may be set according to different bill types, for example, may include a fee item, a consumption date, a billing unit name, etc., and the attribute values of the second attribute types may pass the case information of the target case. And billing information is obtained or generated.
  • the core attribute is the main attribute of the claims liability for accepting the policy, and these core attributes can be set according to the needs of different insurance companies.
  • the acceptance policy refers to the valid policy in the corresponding policy of the target case. It can be understood that the insured person corresponding to the target case may have multiple policies corresponding to the purchase, but considering that different policies have different expiration dates and other agreements, only some of the policies purchased by the insured may be valid. Warranty.
  • the claims liability agreed in the acceptance policy can be determined, and then the attribute values of the core attributes of all these claims liabilities are extracted.
  • these core attributes can include the nature of the incident, the type of treatment refinement, the expense item, and the like.
  • the nature of the accident can be an accident, and the type of refinement treatment is outpatient and hospitalization.
  • the cost items include medical expenses, medical treatment fees, bed fees, and medicine fees.
  • step 405 after obtaining the attribute value of the preset core attribute of all claim liabilities of each of the accepted policies under the target case, and obtaining the attribute value of the preset core attribute of the target case, the attribute values of the two may be obtained. Matching and matching the successful claim liability is the claim liability of the target case.
  • the attribute value of the preset core attribute of the target case may be obtained or generated according to the case information of the target case.
  • the matching claim liability can be determined as the claim liability of the target case.
  • the nature of the accident is accident
  • the type of refinement treatment is outpatient and hospitalization
  • the cost items include medical expenses, medical expenses, bed fees, and medicines.
  • the target case can be considered to be in contact with the accidental medical liability.
  • step 406 after determining the respective claims liability of the target case, the attribute value of each claim liability and the attribute value of the bill under each of the above sub-cases may be matched, and each claim liability of the target case is subdivided into sub-cases. Corresponding claims liability.
  • each scenario pre-defined under the claims liability corresponding to each of the sub-cases may be separately extracted. It can be understood that, in this embodiment, the scenarios in which claims should be made under each claim liability are pre-agreed, defined, and recorded. For example, for medical claims liability, it will pre-agreed which scenes belong to the scope of claims for medical claims, and which scenes are not covered by the claims for medical claims.
  • step 408 it can be understood that after obtaining the predefined scenarios under the claims responsibility of a sub-case, it does not mean that the predefined scenarios are applicable to the sub-case. Therefore, for a sub-case, the attribute value of the sub-case needs to be matched with the attribute value of the scene. If the matching is successful, the matching successful scene can be determined as the to-be-paid scene of the sub-case, that is, applicable. Scenes.
  • step 408 further, in order to improve the success rate of the scene matching, if the attribute values of the scenes of the sub-case are sequentially matched with the attribute values of the sub-cases according to a preset scene sequence, If the scenes of the case are not matched successfully, the last scene located in the scene sequence may be determined as the to-be-paid scene of the sub-case. Thereby improving the matching efficiency of the scene, and indirectly improving the determining efficiency of the target to be compensated scene.
  • the sub-cases to be compensated for each sub-case can be determined by step 408, and one sub-case can determine more than one pay-to-pay scenario. After determining the sub-cases to be compensated, all of the sub-cases are to be treated.
  • the payout scenario can be used to determine the individual payout scenarios for the target case.
  • the policy information of each policy accepted under the target case and the billing information of each bill may be according to a preset adjustment rule. Calculate the compensation amount of each of the to-be-paid scenarios separately. It can be understood that, in the process of calculating the payment amount of each to-be-paid scene, the scene is calculated as the minimum dimension, that is, the compensation amount of each scene to be paid is calculated.
  • the foregoing step 303 may include:
  • step 503 determining whether the payables are greater than the payout limit of the payout scenario, if yes, proceed to step 504, if not, proceed to step 505;
  • the remaining insured amount of the policy in the to-be-paid scenario is accepted, that is, the maximum indemnity amount in the to-be-paid scenario.
  • the remaining insured amount may include three parts: the remaining insured amount of the policy, the remaining insured amount of the responsibility, and the remaining insured amount of the scene, and the minimum amount of the insured amount of the above three parts is obtained by the remaining claims in the scene to be compensated Insurance amount.
  • the payout limit of the to-be-paid scenario refers to the maximum payable amount in the pay-to-pay scenario. It can be understood that, when the payable fee is greater than the payout limit of the payable scenario, step 504 should be performed to adjust the payable value to the payout limit of the payable scenario.
  • the remaining deductible refers to the amount of the deductible of the insurance policy in the to-be-paid scenario.
  • the specific amount of the deductible is agreed by the insurer and the insured in advance, and the amount of the loss is within the prescribed amount.
  • the insured shall bear the losses on its own and the insurer shall not be responsible for the amount of compensation. If there is no deductible amount in the to-be-paid scenario, the remaining deductible may be considered to be zero.
  • the foregoing step 505 may specifically include:
  • the remaining deductible should be subtracted from the compensable payment, thereby obtaining a reasonable compensation.
  • step 603 in this embodiment, different payout ratios are set in advance for different fee intervals.
  • there may be two cost intervals: when 0 ⁇ reasonable compensation for ⁇ 999, the compensation ratio is 0.9; when the reasonable compensation is for > 1000, the compensation ratio is 0.8.
  • step 506 since the remaining insured amount in the to-be-paid scene is obtained in step 501, and the claim amount cannot be greater than the remaining insured amount, the smaller value of the claim amount and the remaining insured amount may be taken as The amount of the payment to be paid for the scene to be paid.
  • the payment amount of each to-be-paid scene can be calculated, and since the target case may have one or more to-be-paid scenes, the claim amount of the target case is equal to all corresponding to-be-paid items.
  • the sum of the claims amount of the payout scenario For example, suppose the target case has three scenarios to be paid, namely, scene A, scene B, and scene C.
  • the payout amount of scene A is A1
  • the payout amount of scene B is B1
  • the payout amount of scene C is C1
  • the target case Claims A1 + B1 + C1.
  • each payment scenario of the target case may be determined according to each bill of the target case, and then the compensation amount of each to-be-paid scenario is separately calculated by using the to-be-paid scenario as a dimension, and finally the sum of the claims is obtained to obtain the target case.
  • the claim compensation not only realizes the automatic calculation of the case claims, but also greatly improves the calculation efficiency of the claims, thereby improving the settlement efficiency of the claims case, and refining the calculation process of the claims in the dimension of the scene, so that the claims are made.
  • the calculation of gold is more accurate.
  • the corresponding claim processing may be performed according to the calculated claim.
  • the related information that the target case is not approved may be generated and fed back, for example, the reason for the failure to pass the review, related suggestions, and the like.
  • the target case when the target case is not approved, the target case can also be transferred to the manual review process, and the relevant personnel can be manually audited by the relevant staff.
  • the case template corresponding to the report information can be selected, and the related information can be quickly extracted and input through the direct connection of the data, thereby generating a case and performing automatic review and processing, and finally giving relevant information. Audit results. It can be seen that the program reduces the time cost of the entry process, greatly improves the efficiency of the entry of relevant information of the case, and thus indirectly improves the settlement efficiency of the claim case.
  • FIG. 7 is a block diagram showing the structure of the claims case processing apparatus provided by the embodiment of the present application. For the convenience of description, only the parts related to the embodiment of the present application are shown.
  • a claim case processing apparatus includes:
  • the report accepting module 701 is configured to obtain the claim report request of the requester and receive the report information, and obtain the report information, where the claim report request includes the report information;
  • a case type confirmation module 702 configured to determine a corresponding case type according to the report information
  • the template selection module 703 is configured to select a case template from the preset case template as the target template according to the determined type of the case;
  • the information entry module 704 is configured to input the report information and the case key information into the target template, and obtain a report file, where the key information of the case is directly connected from the insurance company according to the report information. Extracted from the database and/or the preset docking system;
  • the target case generating module 705 is configured to generate, by the insurance company's case generation system, a target case corresponding to the claim report request according to the report file;
  • the case review module 706 is configured to review the target case according to a preset audit rule
  • the claim module 707 is configured to calculate a claim for the target case if the audit result of the case review module 706 is approved, and perform a claim processing according to the calculated claim;
  • the feedback module 708 is configured to: if the audit result of the case review module 706 is not approved, generate and feed back relevant information that the target case review fails.
  • case type confirmation module 702 can include:
  • the insurance inquiry unit is configured to query the back-end database of the insurance company to determine the insurance type of the valid policy corresponding to the report information;
  • a first confirming unit configured to determine, according to the insurance type, the type of the case corresponding to the report information.
  • a keyword extracting unit configured to extract a value of a preset keyword attribute from the report information
  • the type matching unit is configured to match the extracted value of the keyword attribute with the attribute value of each case type in the preset case type set, and select a case type with the highest matching degree as the report information corresponding to the case information.
  • Type of case is configured to match the extracted value of the keyword attribute with the attribute value of each case type in the preset case type set, and select a case type with the highest matching degree as the report information corresponding to the case information.
  • the key information of the case may be extracted by the following module: a key information extraction module, configured to extract required case key information from a back-end database of the insurance company according to the target template; the first trigger module is configured to If the key information extracted by the key information extraction module is complete, the information input module is triggered; and the second triggering module is configured to: if the key information extracted by the key information extraction module is not complete, Determining a docking system corresponding to the missing portion of the case key information, and then extracting a missing portion of the case key information from the determined docking system, and triggering the information entry module after the missing portion is successfully extracted .
  • a key information extraction module configured to extract required case key information from a back-end database of the insurance company according to the target template
  • the first trigger module is configured to If the key information extracted by the key information extraction module is complete, the information input module is triggered
  • the second triggering module is configured to: if the key information extracted by the key information extraction module is not complete, Determining a docking system corresponding
  • the case review module 706 may include: a credit information obtaining unit, configured to acquire, from the docked credit information system, the credit information of the target person corresponding to the target case; and the risk evaluation unit, configured to perform the risk according to the risk The human credit information and the preset risk control rule perform risk assessment on the target case to obtain the risk level of the target case; and the first non-passing determining unit is configured to: if the risk level of the target case is higher than the pre- Setting the threshold of the wind control level to determine that the review of the target case fails;
  • a remaining insured amount obtaining unit configured to obtain, from a back-end database of the insurance company, a remaining insured amount corresponding to the valid policy of the target case; and a second non-passing determining unit, configured to determine, if the remaining insured amount is 0, The review of the target case did not pass.
  • the claims module 707 can include:
  • a case bill obtaining unit configured to obtain each bill of the target case through a back-end database of the insurance company
  • a payout scenario determining unit configured to determine, according to the case information of the target case and the billing information of the respective bills, each to-be-paid scene of the target case;
  • a claim amount calculation unit configured to calculate, according to the policy information of each of the policies for accepting the policy under the target case, the bill payment information of each bill to be compensated according to a preset adjustment rule
  • the case claim calculation unit is configured to calculate a sum of the claims amount of each of the to-be-paid scenarios, and obtain a claim for the target case.
  • FIG. 8 is a schematic diagram of a terminal device according to an embodiment of the present application.
  • the terminal device 8 of this embodiment includes a processor 80 and a memory 81 in which computer readable instructions 82, such as claim case handlers, executable on the processor 80 are stored.
  • computer readable instructions 82 such as claim case handlers, executable on the processor 80 are stored.
  • the processor 80 executes the computer readable instructions 82, the steps in the foregoing embodiments of the various claims case processing methods are implemented, such as steps 101 to 108 shown in FIG.
  • the processor 80 executes the computer readable instructions 82, the functions of the modules/units in the various apparatus embodiments described above are implemented, such as the functions of the modules 701 to 708 shown in FIG.
  • the computer readable instructions 82 may be partitioned into one or more modules/units that are stored in the memory 81 and executed by the processor 80, To complete this application.
  • the one or more modules/units may be a series of computer readable instruction segments capable of performing a particular function, the instruction segments being used to describe the execution of the computer readable instructions 82 in the terminal device 8.
  • the terminal device 8 may be a computing device such as a desktop computer, a notebook, a palmtop computer, or a cloud server.
  • the terminal device may include, but is not limited to, the processor 80 and the memory 81. It will be understood by those skilled in the art that FIG. 8 is merely an example of the terminal device 8, and does not constitute a limitation on the terminal device 8, and may include more or less components than those illustrated, or combine some components, or different components.
  • the terminal device may further include an input/output device, a network access device, a bus, and the like.
  • the so-called processor 80 can be a central processing unit (Central Processing Unit, CPU), can also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (Application Specific Integrated Circuit (ASIC), Field-Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, etc.
  • the general purpose processor may be a microprocessor or the processor or any conventional processor or the like.
  • the memory 81 may be an internal storage unit of the terminal device 8, such as a hard disk or a memory of the terminal device 8.
  • the memory 81 may also be an external storage device of the terminal device 8, such as a plug-in hard disk provided on the terminal device 8, a smart memory card (SMC), and a secure digital (SD). Card, flash card, etc. Further, the memory 81 may also include both an internal storage unit of the terminal device 8 and an external storage device.
  • the memory 81 is configured to store the computer readable instructions and other programs and data required by the terminal device.
  • the memory 81 can also be used to temporarily store data that has been output or is about to be output.
  • each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.
  • the above integrated unit can be implemented in the form of hardware or in the form of a software functional unit.
  • the integrated unit if implemented in the form of a software functional unit and sold or used as a standalone product, may be stored in a computer readable storage medium.
  • a computer readable storage medium A number of instructions are included to cause a computer device (which may be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods described in various embodiments of the present application.
  • the foregoing storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, and the like, which can store program codes. .

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Engineering & Computer Science (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Technology Law (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

本方案提供了一种理赔案件处理方法、装置、终端设备及介质，适用于信息处理技术领域，该方法包括：获取理赔报案请求并受理，得到报案信息；根据报案信息确定对应的案件类型；根据确定的案件类型从预设的案件模板中选取一个案件模板作为目标模板；将报案信息和案件关键信息录入至目标模板中，得到报案文件；通过保险公司的案件生成系统根据报案文件生成与理赔报案请求对应的目标案件；按照预设的审核规则对所述目标案件进行审核；若通过，则计算目标案件的理赔金，并根据计算得到的所述理赔金进行赔付处理；若不通过，则生成并反馈目标案件审核不通过的相关信息。本方案解决了现有理赔处理流程的录入环节需要耗费大量的时间成本，效率低下的问题。

Description

理赔案件处理方法、装置、终端设备及介质
本申请要求于2017年04月14日提交中国专利局、申请号为201710245716.1 、发明名称为“一种理赔案件处理方法和装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请属于信息处理技术领域，尤其涉及一种理赔案件处理方法、装置、终端设备及介质。
 背景技术
在保险行业中，现有理赔案件需要通过报案、受理、录入、审核等环节操作，才能完成理赔完整的流程，并给付给客户赔付理赔金。尤其是在客户信息的录入环节中，往往需要耗费工作人员不少的时间。
目前，由于不同客户的理赔情况往往并不相同，因此工作人员需要根据客户的理赔情况针对性地录入不同的案件信息，且多以手动录入为主，往往导致录入环节耗费大量的时间成本，间接降低了理赔案件的结案效率。
 技术问题
有鉴于此，本申请实施例提供了一种理赔案件处理方法、装置、终端设备及介质，以解决现有理赔处理流程的录入环节需要耗费大量的时间成本，效率低下的问题。
 技术解决方案
本申请实施例的第一方面提供了一种理赔案件处理方法，包括：
获取请求人的理赔报案请求并受理，得到报案信息，所述理赔报案请求中包括所述报案信息；
根据所述报案信息确定对应的案件类型；
根据确定的所述案件类型从预设的案件模板中选取一个案件模板作为目标模板；
将所述报案信息和案件关键信息录入至所述目标模板中，得到报案文件，所述案件关键信息为根据所述报案信息采用数据直连的方式从保险公司的后台数据库和/或预设的对接系统中提取得到；
通过保险公司的案件生成系统根据所述报案文件生成与所述理赔报案请求对应的目标案件；
按照预设的审核规则对所述目标案件进行审核；
若审核通过，则计算所述目标案件的理赔金，并根据计算得到的所述理赔金进行赔付处理；
若审核不通过，则生成并反馈所述目标案件审核不通过的相关信息。
本申请实施例的第二方面提供了一种理赔案件处理装置，该理赔案件处理装置包括用于执行上述第一方面所述的理赔案件处理方法的模块。
本申请实施例的第三方面提供了一种终端设备，包括存储器以及处理器，所述存储器中存储有可在所述处理器上运行的计算机可读指令，所述处理器执行所述计算机可读指令时实现如第一方面所述的理赔案件处理方法的步骤。
本申请实施例的第四方面提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机可读指令，所述计算机可读指令被处理器执行时实现如第一方面所述的理赔案件处理方法的步骤。
 有益效果
本申请实施例可以在请求人报案、受理后，选取与报案信息对应的案件模板，并通过数据直连的方式快速提取并录入相关信息，从而生成案件并进行自动审核处理，最后给出相关审核结果。可见，本申请实施例减少了录入环节耗费的时间成本，大大提高了案件相关信息的录入效率，从而也间接提升了理赔案件的结案效率。
 附图说明
图1为本申请实施例中一种理赔案件处理方法一个实施例流程图；
图2为本申请实施例中一种理赔案件处理方法的案件关键信息提取步骤的流程示意图；
图3为本申请实施例中一种理赔案件处理方法的理赔金计算过程的流程示意图；
图4为图3对应实施例中一种理赔案件处理方法步骤302在一个应用场景下的流程示意图；
图5为图3对应实施例中一种理赔案件处理方法步骤303在一个应用场景下的流程示意图；
图6为图5对应实施例中一种理赔案件处理方法步骤505在一个应用场景下的流程示意图；
图7为本申请实施例中一种理赔案件处理装置的结构框图；
图8为本申请实施例提供的终端设备的示意图。
 本发明的实施方式
为了说明本申请所述的技术方案，下面通过具体实施例来进行说明。
请参阅图1，本申请实施例中一种理赔案件处理方法一个实施例包括：
101、获取请求人的理赔报案请求并受理，得到报案信息；
本实施例中，当请求人需要理赔时，可以向保险公司的系统发起理赔报案请求，系统获取该理赔报告请求并受理后，得到该理赔报案请求中的报案信息。一般来说，该报案信息可以包括请求人的身份、请求理赔的保单、要求理赔的事件的发生时间、发生地点、事件大致情况等信息。
102、根据所述报案信息确定对应的案件类型；
103、根据确定的所述案件类型从预设的案件模板中选取一个案件模板作为目标模板；
对于步骤102和步骤103，本实施例中，预先设置多个案件模板，这些案件模板用于录入该理赔报案请求的相关案件信息。由于不同类型的案件往往需要录入不同的字段（属性），因此，不同的案件模板对应不同的案件类型，在录入案件信息之前，需要先确定其案件类型，从而选取到对应的案件模板。
对于步骤102，由于报案信息中往往记录了案件的相关情况，因此可以根据这些报案信息确定出其对应的案件类型。比如，若报案信息中出现医疗费用、疾病、治疗等相关属性或字段，则可以确定其对应的案件类型为医疗案件。
进一步地，上述步骤102具体可以采用以下两种方式来确定案件类型，分别为方式一和方式二。
方式一：可以先查询保险公司的后台数据库确定与所述报案信息对应的有效保单的险种，然后根据所述险种确定所述报案信息对应的所述案件类型。可以理解的是，报案信息中可以包括请求理赔的保单，在确定报案信息中请求理赔的保单为有效保单之后，则可以得知该有效保单的险种。由于险种往往在设计时就与案件类型对应，因而，可以根据其险种确定报案信息对应的案件类型。
方式二：可以先从所述报案信息中提取预设关键字属性的值；然后，将提取得到的所述关键字属性的值与预设的案件类型集合中各个案件类型的属性值进行一一匹配，选取匹配度最高的一个案件类型作为所述报案信息对应的案件类型。可以理解的是，对于案件类型集合中的各个案件类型，预先为每个案件类型设置好属性值。例如，对“医疗案件”的案件类型，设置其属性值为“医疗费用”、“疾病”、“治疗”，当从报案信息中提取到的关键字属性的值也包括“医疗费用”、“疾病”和“治疗”时，则提取到的关键字属性的值与该“医疗案件”的案件类型的属性值匹配成功，匹配度相对其它案件类型的匹配度更高，则可以将该“医疗案件”的案件类型确定为该报案信息对应的案件类型。
需要说明的是，对于上述方式二，在设置关键字属性时，一般针对报案信息的必传字段进行对应设置。在请求人进行理赔报案时，必传字段一般包括：姓名、证件号、客户号、保单号、事故日期、事故类型、事故原因、账单号、账单金额、就诊医院、就诊类型等。因此，在提取报案信息的关键字属性的值时，主要针对这些必传字段进行提取。另外，为了提高案件类型选取的准确性，各个案件类型的属性值大多也参考上述的必传字段进行设置，以确保任意类型的报案信息均能从预设的案件类型集合中选取到匹配度高的案件类型。
对于步骤103，由上述内容可知，不同的案件模板对应不同的案件类型，因此，在确定出该报案信息对应的案件类型之后，可以根据确定的所述案件类型从预设的案件模板中选取一个案件模板作为目标模板。
可以理解的是，本实施例中的案件模板具体可以为excel表格模板，这些excel表格模板中的每一列代表某种类型案件的某个字段（属性），每一行代表一条报案信息。同时由于各种案件模板是可以通过基础模板来衍生的，因此可以根据需要增加基础模板的列来自定义模板上的字段（属性）。
另外，由于excel表格中的每一列代表某种类型案件的某个字段（属性），每一行代表一条报案信息。因此，一个录入完成的excel表格中可以同时存储多行数据，每行数据可以生成对应的一个理赔案件。这样，在将excel表格上传至保险公司的案件生成系统时，就可以实现批次上载多个理赔案件的功能。
104、将所述报案信息和案件关键信息录入至所述目标模板中，得到报案文件，所述案件关键信息为根据所述报案信息采用数据直连的方式从保险公司的后台数据库和/或预设的对接系统中提取得到；
本实施例中的案件关键信息是指该目标模板中指定需要录入的、且不属于报案信息的信息。例如报案信息中往往包括保单号，但不包括保单号对应保单的总保额、剩余保额、约定责任等信息，这些信息在生成理赔案件时需要，属于案件关键信息。
在本实施例中，为了提高录入环节的效率，这些案件关键信息可以根据所述报案信息采用数据直连的方式从保险公司的后台数据库和/或预设的对接系统中提取得到。在提取案件关键信息时，将该报案信息作为提取所需的索引信息。报案信息一般包括保单号，还可以包括请求人的身份信息。
另外，关于上述的案件关键信息的提取，其中，从保险公司的后台数据中提取得到相关的案件关键信息。
进一步地，如图2所示，所述案件关键信息可以通过以下步骤提取得到：
201、根据所述目标模板从保险公司的后台数据库中提取所需的案件关键信息；
202、判断提取得到的所述案件关键信息是否完整，若是，则执行上述步骤104，若否，则执行步骤203；
203、确定所述案件关键信息的缺失部分所对应的对接系统，然后从确定的所述对接系统中提取所述案件关键信息的缺失部分，在所述缺失部分提取成功后，执行上述步骤104。
对于上述步骤201~203，为了提高案件关键信息的提取效率，由于保险公司的后台数据库往往属于本地数据库，在提取信息的速度上要远高于从对接系统中提取的速度。因此，本实施例可以优先在保险公司的后台数据库中提取所需的案件关键信息，若提取的案件关键信息已完整，则可以执行上述步骤104的录入过程；若提取的案件关键信息不完整，再从对接的系统中提取相应的缺失部分，在缺失部分提取完成后，再执行步骤104。
其中，在提取的案件关键信息不完整时，可以判断该案件关键信息的缺失部分属于哪种类型的信息，再从对应的对接系统中提取该缺失部分。
对于上述步骤104，预设的对接系统可以定期自动将属于该保险公司的相关保险人的案件关键信息更新至保险公司的后台数据库。例如，在一个应用场景中，患者门诊挂号或办理入院手续时，医院系统传输该患者的身份信息、就诊类型（门诊或住院）、就诊时间给保险公司的系统，保险公司系统判断该患者是否为该保险公司的有效客户。在通过身份校验、就诊类型校验、校验保单及人员范围等校验手段校验后，全部通过以上校验的患者会被判断为保险公司的有效客户。当患者到医院缴费窗口缴费时，医院系统通过数据直连接口将该有效客户实际就诊的账单数据以及其它相关信息更新至保险公司的后台数据库。从而，当系统接收到与该患者相关的理赔报案请求之后，可以从后台数据库中提取到该患者的这些案件关键信息。
105、通过保险公司的案件生成系统根据所述报案文件生成与所述理赔报案请求对应的目标案件。
本实施例中，在目标模板中完成信息录入之后，可以将得到的报案文件上传至保险公司的案件生成系统生成对应的目标案件。一个报案文件中可以包括多个理赔案件的案件信息，因此可以通过案件生成系统根据一个报案文件生成多个理赔案件（也即目标案件）。
进一步地，在案件生成系统根据报案文件生成目标案件之前，案件生成系统可以对该报案文件进行相关的校验。例如，校验文件内容是否为空、文件命名格式是否包含特殊字符等。对符合校验规则的报案文件，案件生成系统会提示该报案文件上载成功，并生成对应上传批次号。同一个报案文件生成的理赔案件会作为该批次下的目标案件，同一批次的目标案件可以一起流转。
更进一步地，案件生成系统对该报案文件进行相关的校验具体可以包括：自动解析该报案文件中各个案件的数据，读取解析得到的数据中对应字段的值，同时采用预设的规则对读取到的值进行校验。例如，“入院时间是否晚于当前时间”，“出院时间是否晚于当前时间”等。对于校验成功的案件数据，则执行后续步骤生成对应的目标案件；而对于校验失败的按键，则可以将失败原因写入到反馈的文本中，并将反馈的文本发送至上传该报案文件的终端或系统。
106、按照预设的审核规则对所述目标案件进行审核，若审核通过，则执行步骤107，若审核不通过，则执行步骤108；
在生成目标案件后，该目标案件进入理赔流程的审核环节，在审核环节中，若审核通过，则执行步骤107，若审核不通过，则执行步骤108。
进一步地，上述步骤106对目标案件的审核可以包括两部分，分别为风控审核部分和剩余保额审核部分。
对于风控审核部分，可以先从对接的征信系统中获取所述目标案件对应出险人的征信信息；然后，根据所述出险人的征信信息和预设的风控规则对所述目标案件进行风险评估，得到所述目标案件的风险等级；若所述目标案件的风险等级高于预设的风控等级阈值，则可以确定所述目标案件的审核不通过。可以理解的是，在获取到出险人的征信信息之后，可以对那些征信信息中存在欺诈风险、行政负面风险、其他风险行为的出险人的目标案件设置较高的风险等级，从而当该风险等级超过预设的风控等级阈值时，可以判定该目标案件审核不通过。
对于剩余保额审核部分，可以先从保险公司的后台数据库中获取所述目标案件对应有效保单的剩余保额，若所述剩余保额为0，则确定所述目标案件的审核不通过。可以理解的是，当剩余保额为0时，该目标案件已不存在可理赔的保额，可以直接拒付，因此可以确定该目标案件审核不通过。
107、计算所述目标案件的理赔金，并根据计算得到的所述理赔金进行赔付处理；
进一步地，如图3所示，上述步骤107计算所述目标案件的理赔金的过程具体可以包括：
301、通过保险公司的后台数据库获取所述目标案件的各个账单；
302、根据所述目标案件的案件信息和所述各个账单的账单信息确定所述目标案件的各个待赔付场景；
303、根据所述目标案件下各个受理保单的保单信息和所述各个账单的账单信息按照预设的理算规则分别计算各个所述待赔付场景的赔付金额；
304、计算各个所述待赔付场景的赔付金额之和，得到所述目标案件的理赔金。
对于步骤301，可以理解的是，在保险公司系统受理并生成相关理赔案件之后，这些案件的账单可以保存在保险公司的后台数据库中。因此，可以通过保险公司的后台数据库获取所述目标案件的各个账单。
对于步骤302，需要说明的是，在本实施例中，为了精确计算目标案件的理赔金，由于案件的保单中一般约定的理赔责任是根据不同的场景进行区分的。例如，对于同一个车险保单，同样是被保车辆损坏，在不同的场景下车险保单承担的责任并不相同。比如，若车辆是在人为的场景下受损，则本次受损事件属于车险保单的责任范围；而若该车辆是在不可抗力下的场景（如洪水、台风）下受损，则本次受损事件不属于车险保单的责任范围。因此，在计算理赔金之前需要确定该目标案件的各个待赔付场景，然后在根据不同的场景细分并计算出各自的赔付金额。其中，待赔付场景即为属于目标案件对应保单的责任范围内的场景。
进一步地，如图4所示，上述步骤302可以包括：
401、按照预设分组规则对所述各个账单进行分组，得到的各个账单小组分别作为所述目标案件的各个子案件；
402、根据所述案件信息和所述账单信息生成各个所述子案件的预设第一属性类型的属性值；
403、根据所述案件信息和所述账单信息生成各个所述账单的预设第二属性类型的属性值；
404、提取所述目标案件下各个受理保单的所有理赔责任的预设核心属性的属性值；
405、将所述所有理赔责任的预设核心属性的属性值与所述目标案件的预设核心属性的属性值进行匹配，得到匹配成功的各个理赔责任作为所述目标案件的理赔责任；
406、将所述目标案件的各个理赔责任的属性值与各个所述子案件下所述账单的属性值进行匹配，得到各个所述子案件对应的理赔责任；
407、分别提取各个所述子案件对应的理赔责任下预定义的各个场景；
408、将所述子案件的各个场景的属性值按照预设的场景顺序依次与所述子案件的属性值进行匹配，若匹配成功，则将匹配成功的场景确定为所述子案件的待赔付场景；
409、将确定出的各个所述子案件的待赔付场景确定为所述目标案件的各个待赔付场景。
对于步骤401，一般来说，一个目标案件大多具有多个账单，这些账单可能具有不同的账单日期、类型、消费区域等，因此，可以根据这些账单属性设置分组规则对这些账单进行归类、分组，从而将多个账单分成一个以上的账单小组。例如，对于医疗理赔案件，对应的账单为医疗账单，可以将同一天就诊、同一就诊类型、同一疾病类型、且同一家医院作为同一账单小组。每一个账单小组即为目标案件的一个子案件。在后续的步骤中均以子案件作为计算维度。
对于步骤402，所述第一属性类型可以根据不同的子案件进行设定，例如可以包括事故性质、细化治理类型、出险地等，这些第一属性类型的属性值可以通过目标案件的案件信息和账单信息获取或生成得到。
对于步骤403，所述第二属性类型可以根据不同的账单类型进行设定，例如可以包括费用项目、消费日期、出账单位名称等，这些第二属性类型的属性值可以通过目标案件的案件信息和账单信息获取或生成得到。
对于步骤404，所述核心属性为受理保单的理赔责任的主要属性，这些核心属性可以根据不同保险公司的需要进行设定。所述受理保单是指该目标案件对应保单中的有效保单。可以理解的是，目标案件对应的被保人可能对应购买有多个保单，但考虑到不同保单具有不一样的有效期以及其它约定，因此，被保人购买的这些保单中可能只有一部分保单为有效保单。
在确定出目标案件下的各个受理保单之后，可以确定这些受理保单中约定的理赔责任，然后提取所有这些理赔责任的核心属性的属性值。例如，在医疗保单中，这些核心属性可以包括事故性质、细化治疗类型、费用项目等。提取后，可以得到事故性质为意外，细化治疗类型为门诊和住院，费用项目包括医疗费、诊疗费、床位费、药品费等。
需要说明的是，上述步骤402、403和404之间不限定先后执行顺序。
对于步骤405，在得到目标案件下的各个受理保单的所有理赔责任的预设核心属性的属性值，以及得到所述目标案件的预设核心属性的属性值之后，可以将这两者的属性值进行匹配，匹配成功的理赔责任即为目标案件的理赔责任。其中，目标案件的预设核心属性的属性值可以根据目标案件的案件信息获取或生成得到。
当理赔责任的属性值与目标案件的属性值匹配成功时，表明该理赔责任从核心属性方面考虑是满足目标案件的要求或情况的，因此可以将匹配成功的理赔责任确定为目标案件的理赔责任。例如，若意外医疗责任，其事故性质为意外，细化治疗类型为门诊和住院，费用项目包含医疗费，诊疗费，床位费，药品费等。当某一目标案件的事故性质、案件账单的治疗类型，费用项目与意外医疗责任的属性值均相同，则可以认为该目标案件匹配上了意外医疗责任。
对于步骤406，在确定出目标案件的各个理赔责任之后，可以根据各个理赔责任的属性值和上述各个子案件下账单的属性值进行匹配，将该目标案件的各个理赔责任细分为各个子案件对应的理赔责任。
对于步骤407，在得到各个子案件对应的理赔责任之后，可以分别提取各个所述子案件对应的理赔责任下预定义的各个场景。可以理解的是，本实施例中，对每个理赔责任下应当进行理赔的场景均预先约定、定义并记录。例如，对于医疗理赔责任，其会预先约定哪些场景属于医疗理赔责任的理赔范围，哪场场景则不属于医疗理赔责任的理赔范围。
对于步骤408，可以理解的是，在得到一个子案件对应的理赔责任下预定义的各个场景之后，并不代表这些预定义的各个场景就适用于该子案件。因此，对于一个子案件来说，需要将该子案件的属性值与这些场景的属性值进行匹配，若匹配成功，则可以将匹配成功的场景确定为该子案件的待赔付场景，也即适用场景。
对于步骤408，更进一步地，为了提高场景匹配成功率，在将所述子案件的各个场景的属性值按照预设的场景顺序依次与所述子案件的属性值进行匹配时，若所述子案件的各个场景均未匹配成功，则可以将位于所述场景顺序中最后一个场景确定为所述子案件的待赔付场景。从而提高场景的匹配效率，也间接提高了目标案件的待赔付场景的确定效率。
对于步骤409，通过步骤408可以分别确定出各个子案件的待赔付场景，一个子案件可以确定出一个以上的待赔付场景，在确定出各个子案件的待赔付场景之后，所有这些子案件的待赔付场景即可以确定为该目标案件的各个待赔付场景。
对于上述步骤303，本实施例中，在确定出目标案件的各个待赔付场景之后，可以根据所述目标案件下各个受理保单的保单信息和所述各个账单的账单信息按照预设的理算规则分别计算各个所述待赔付场景的赔付金额。可以理解的是，在该计算各个待赔付场景的赔付金额的过程中，是以场景作为最小维度计算的，即计算每个待赔付场景的赔付金额。
进一步地，如图5所示，上述步骤303可以包括：
501、获取所述各个受理保单在所述待赔付场景下的剩余保额；
502、计算所述各个账单在所述待赔付场景下的应赔付费用；
503、判断所述应赔付费用是否大于所述待赔付场景的赔付费用限额，若是，则执行步骤504，若否，则执行步骤505；
504、将所述应赔付费用的值更新为所述赔付费用限额的值；
505、根据所述应赔付费用、所述各个受理保单在所述待赔付场景下的剩余免赔额以及对应的赔付比例计算得到所述各个受理保单在所述待赔付场景下的理赔金额；
506、取所述理赔金额与所述剩余保额中的较小值作为所述待赔付场景的赔付金额。
对于步骤501，受理保单在待赔付场景下的剩余保额，也即该待赔付场景下的最大可赔付金额。该剩余保额可以包括三部分：保单的剩余保额、责任的剩余保额、场景的剩余保额，对以上三部分的保额取最小值则得到这些受理保单在该待赔付场景下的剩余保额。
对于步骤502，根据各个账单的账单信息，可以计算这些账单在该待赔付场景下的应赔付费用。具体地，该应赔付费用=账单金额-不合理医疗费用-自费金额-医保给付金额。
对于步骤503，所述待赔付场景的赔付费用限额是指该待赔付场景下的最大可赔付的金额。可以理解的是，当该应赔付费用大于该待赔付场景的赔付费用限额时，应该执行步骤504，将该应赔付费用的值调整为该待赔付场景的赔付费用限额。
对于步骤505，该剩余免赔额是指这些受理保单在该待赔付场景下的免赔的额度，具体的免赔的额度是由保险人和被保险人事先约定，损失额在规定数额之内，被保险人自行承担损失，保险人不负责赔偿的额度。若该待赔付场景下没有免赔的额度，则可以认为该剩余免赔额为0。
具体地，如图6所示，上述步骤505具体可以包括：
601、获取所述各个受理保单在所述待赔付场景下的剩余免赔额；
602、计算所述应赔付费用与所述剩余免赔额之差，得到合理赔付费用；
603、根据所述合理赔付费用落入的费用区间确定所述各个受理保单在所述待赔付场景下赔付比例，所述费用区间与所述赔付比例存在对应关系；
604、根据所述赔付比例和所述合理赔付费用计算得到所述各个受理保单在所述待赔付场景下的理赔金额。
对于上述步骤601和602，考虑到该待赔付场景下的剩余免赔额，在计算理赔金额之前，应当从应赔付费用中减去这部分剩余免赔额，从而得到合理赔付费用。
对于步骤603，本实施例中，预先对不同的费用区间设置有不同的赔付比例。例如，在场景A中，费用区间可能有两个：当0<合理赔付费用<999时，赔付比例为0.9；当合理赔付费用>=1000,赔付比例则为0.8。
对于步骤604，在计算得到合理赔付费用以及确定出对应的赔付比例之后，可以根据该合理赔付费用和对应的赔付比例计算得到该待赔付场景下的理赔金额。具体地，该待赔付场景下的理赔金额=合理赔付费用*赔付比例。从而计算出各个受理保单在该待赔付场景下的理赔金额。
对于上述步骤506，由于步骤501获取到该待赔付场景下的剩余保额，而理赔金额不能大于该剩余保额，因此，可以取所述理赔金额与所述剩余保额中的较小值作为所述待赔付场景的赔付金额。
对于上述步骤304，通过上述步骤303，可以计算出各个待赔付场景的赔付金额，而由于该目标案件可能存在一个或多个待赔付场景，因此，该目标案件的理赔金等于其对应的所有待赔付场景的赔付金额之和。例如，假设目标案件有三个待赔付场景，分别为场景A、场景B和场景C，场景A的赔付金额为A1，场景B的赔付金额为B1，场景C的赔付金额为C1，则该目标案件的理赔金=A1+B1+C1。
在步骤107中，可以根据目标案件的各个账单确定出目标案件的各个待赔付场景，然后以这些待赔付场景作为维度分别计算各个待赔付场景的赔付金额，最后计算这些赔付金额之和得到目标案件的理赔金，不仅实现了案件理赔金的自动化计算，大大提高了理赔金的计算效率，从而提高了理赔案件的结案效率，而且以场景为维度对理赔金的计算过程进行了精细化，使得理赔金的计算更加准确。
在步骤107计算出目标案件的理赔金之后，则可以根据计算得到的所述理赔金进行相应的赔付处理。
108、生成并反馈所述目标案件审核不通过的相关信息。
本实施例中，对于审核不通过的目标案件，可以生成并反馈所述目标案件审核不通过的相关信息，例如审核不通过的原因、相关建议等。另外，当目标案件审核不通过时，还可以将目标案件流转至人工审核的环节，通过相关工作人员对该目标案件进行人工审核。
本实施例中，可以在请求人报案、受理后，选取与报案信息对应的案件模板，并通过数据直连的方式快速提取并录入相关信息，从而生成案件并进行自动审核处理，最后给出相关审核结果。可见，本方案减少了录入环节耗费的时间成本，大大提高了案件相关信息的录入效率，从而也间接提升了理赔案件的结案效率。
对应于上文实施例所述的理赔案件处理方法，图7示出了本申请实施例提供的理赔案件处理装置的结构框图，为了便于说明，仅示出了与本申请实施例相关的部分。
如图7所示，一种理赔案件处理装置，包括：
报案受理模块701，用于获取请求人的理赔报案请求并受理，得到报案信息，所述理赔报案请求中包括所述报案信息；
案件类型确认模块702，用于根据所述报案信息确定对应的案件类型；
模板选取模块703，用于根据确定的所述案件类型从预设的案件模板中选取一个案件模板作为目标模板；
信息录入模块704，用于将所述报案信息和案件关键信息录入至所述目标模板中，得到报案文件，所述案件关键信息为根据所述报案信息采用数据直连的方式从保险公司的后台数据库和/或预设的对接系统中提取得到；
目标案件生成模块705，用于通过保险公司的案件生成系统根据所述报案文件生成与所述理赔报案请求对应的目标案件；
案件审核模块706，用于按照预设的审核规则对所述目标案件进行审核；
理赔模块707，用于若所述案件审核模块706的审核结果为审核通过，则计算所述目标案件的理赔金，并根据计算得到的所述理赔金进行赔付处理；
反馈模块708，用于若所述案件审核模块706的审核结果为审核不通过，则生成并反馈所述目标案件审核不通过的相关信息。
进一步地，所述案件类型确认模块702可以包括：
险种查询单元，用于查询保险公司的后台数据库确定与所述报案信息对应的有效保单的险种；
第一确认单元，用于根据所述险种确定所述报案信息对应的所述案件类型。
或
关键字提取单元，用于从所述报案信息中提取预设关键字属性的值；
类型匹配单元，用于将提取得到的所述关键字属性的值与预设的案件类型集合中各个案件类型的属性值进行一一匹配，选取匹配度最高的一个案件类型作为所述报案信息对应的案件类型。
进一步地，所述案件关键信息可以通过以下模块提取得到：关键信息提取模块，用于根据所述目标模板从保险公司的后台数据库中提取所需的案件关键信息；第一触发模块，用于若所述关键信息提取模块提取得到的所述案件关键信息已完整，则触发所述信息录入模块；第二触发模块，用于若所述关键信息提取模块提取得到的所述案件关键信息未完整，则确定所述案件关键信息的缺失部分所对应的对接系统，然后从确定的所述对接系统中提取所述案件关键信息的缺失部分，在所述缺失部分提取成功后，触发所述信息录入模块。
进一步地，所述案件审核模块706可以包括：征信信息获取单元，用于从对接的征信系统中获取所述目标案件对应出险人的征信信息；风险评估单元，用于根据所述出险人的征信信息和预设的风控规则对所述目标案件进行风险评估，得到所述目标案件的风险等级；第一不通过确定单元，用于若所述目标案件的风险等级高于预设的风控等级阈值，则确定所述目标案件的审核不通过；
或
剩余保额获取单元，用于从保险公司的后台数据库中获取所述目标案件对应有效保单的剩余保额；第二不通过确定单元，用于若所述剩余保额为0，则确定所述目标案件的审核不通过。
进一步地，所述理赔模块707可以包括：
案件账单获取单元，用于通过保险公司的后台数据库获取所述目标案件的各个账单；
赔付场景确定单元，用于根据所述目标案件的案件信息和所述各个账单的账单信息确定所述目标案件的各个待赔付场景；
赔付金额计算单元，用于根据所述目标案件下各个受理保单的保单信息和所述各个账单的账单信息按照预设的理算规则分别计算各个所述待赔付场景的赔付金额；
案件理赔金计算单元，用于计算各个所述待赔付场景的赔付金额之和，得到所述目标案件的理赔金。
图8是本申请一实施例提供的终端设备的示意图。如图8所示，该实施例的终端设备8包括：处理器80以及存储器81，所述存储器81中存储有可在所述处理器80上运行的计算机可读指令82，例如理赔案件处理程序。所述处理器80执行所述计算机可读指令82时实现上述各个理赔案件处理方法实施例中的步骤，例如图1所示的步骤101至108。或者，所述处理器80执行所述计算机可读指令82时实现上述各装置实施例中各模块/单元的功能，例如图7所示模块701至708的功能。
示例性的，所述计算机可读指令82可以被分割成一个或多个模块/单元，所述一个或者多个模块/单元被存储在所述存储器81中，并由所述处理器80执行，以完成本申请。所述一个或多个模块/单元可以是能够完成特定功能的一系列计算机可读指令段，该指令段用于描述所述计算机可读指令82在所述终端设备8中的执行过程。
所述终端设备8可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。所述终端设备可包括，但不仅限于处理器80和存储器81。本领域技术人员可以理解，图8仅仅是终端设备8的示例，并不构成对终端设备8的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如所述终端设备还可以包括输入输出设备、网络接入设备、总线等。
所称处理器80可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器 (Digital Signal Processor，DSP)、专用集成电路 (Application Specific Integrated Circuit，ASIC)、现成可编程门阵列 (Field-Programmable Gate Array，FPGA) 或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
所述存储器81可以是所述终端设备8的内部存储单元，例如终端设备8的硬盘或内存。所述存储器81也可以是所述终端设备8的外部存储设备，例如所述终端设备8上配备的插接式硬盘，智能存储卡（Smart Media Card，SMC），安全数字（Secure Digital，SD）卡，闪存卡（Flash Card）等。进一步地，所述存储器81还可以既包括所述终端设备8的内部存储单元也包括外部存储设备。所述存储器81用于存储所述计算机可读指令以及所述终端设备所需的其他程序和数据。所述存储器81还可以用于暂时地存储已经输出或者将要输出的数据。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器（Read-Only Memory，ROM）、随机存取存储器（Random Access Memory，RAM）、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (20)

  1. 一种理赔案件处理方法，其特征在于，包括：
    获取请求人的理赔报案请求并受理，得到报案信息，所述理赔报案请求中包括所述报案信息；
    根据所述报案信息确定对应的案件类型；
    根据确定的所述案件类型从预设的案件模板中选取一个案件模板作为目标模板；
    将所述报案信息和案件关键信息录入至所述目标模板中，得到报案文件，所述案件关键信息为根据所述报案信息采用数据直连的方式从保险公司的后台数据库和/或预设的对接系统中提取得到；
    通过保险公司的案件生成系统根据所述报案文件生成与所述理赔报案请求对应的目标案件；
    按照预设的审核规则对所述目标案件进行审核；
    若审核通过，则计算所述目标案件的理赔金，并根据计算得到的所述理赔金进行赔付处理；
    若审核不通过，则生成并反馈所述目标案件审核不通过的相关信息。
  2. 如权利要求1所述的理赔案件处理方法，其特征在于，所述根据所述报案信息确定对应的案件类型包括：
    查询保险公司的后台数据库确定与所述报案信息对应的有效保单的险种；
    根据所述险种确定所述报案信息对应的所述案件类型；
    或
    从所述报案信息中提取预设关键字属性的值；
    将提取得到的所述关键字属性的值与预设的案件类型集合中各个案件类型的属性值进行一一匹配，选取匹配度最高的一个案件类型作为所述报案信息对应的案件类型。
  3. 如权利要求1所述的理赔案件处理方法，其特征在于，所述案件关键信息通过以下步骤提取得到：
    根据所述目标模板从保险公司的后台数据库中提取所需的案件关键信息；
    若提取得到的所述案件关键信息已完整，则执行将所述报案信息和案件关键信息录入至所述目标模板中的步骤；
    若提取得到的所述案件关键信息未完整，则确定所述案件关键信息的缺失部分所对应的对接系统，然后从确定的所述对接系统中提取所述案件关键信息的缺失部分，在所述缺失部分提取成功后，执行将所述报案信息和案件关键信息录入至所述目标模板中的步骤。
  4. 如权利要求1所述的理赔案件处理方法，其特征在于，所述按照预设的审核规则对所述目标案件进行审核包括：
    从对接的征信系统中获取所述目标案件对应出险人的征信信息；
    根据所述出险人的征信信息和预设的风控规则对所述目标案件进行风险评估，得到所述目标案件的风险等级；
    若所述目标案件的风险等级高于预设的风控等级阈值，则确定所述目标案件的审核不通过；
    或
    从保险公司的后台数据库中获取所述目标案件对应有效保单的剩余保额；
    若所述剩余保额为0，则确定所述目标案件的审核不通过。
  5. 如权利要求1至4任一项所述的理赔案件处理方法，其特征在于，所述计算所述目标案件的理赔金包括：
    通过保险公司的后台数据库获取所述目标案件的各个账单；
    根据所述目标案件的案件信息和所述各个账单的账单信息确定所述目标案件的各个待赔付场景；
    根据所述目标案件下各个受理保单的保单信息和所述各个账单的账单信息按照预设的理算规则分别计算各个所述待赔付场景的赔付金额；
    计算各个所述待赔付场景的赔付金额之和，得到所述目标案件的理赔金。
  6. 一种理赔案件处理装置，其特征在于，包括：
    报案受理模块，用于获取请求人的理赔报案请求并受理，得到报案信息，所述理赔报案请求中包括所述报案信息；
    案件类型确认模块，用于根据所述报案信息确定对应的案件类型；
    模板选取模块，用于根据确定的所述案件类型从预设的案件模板中选取一个案件模板作为目标模板；
    信息录入模块，用于将所述报案信息和案件关键信息录入至所述目标模板中，得到报案文件，所述案件关键信息为根据所述报案信息采用数据直连的方式从保险公司的后台数据库和/或预设的对接系统中提取得到；
    目标案件生成模块，用于通过保险公司的案件生成系统根据所述报案文件生成与所述理赔报案请求对应的目标案件；
    案件审核模块，用于按照预设的审核规则对所述目标案件进行审核；
    理赔模块，用于若所述案件审核模块的审核结果为审核通过，则计算所述目标案件的理赔金，并根据计算得到的所述理赔金进行赔付处理；
    反馈模块，用于若所述案件审核模块的审核结果为审核不通过，则生成并反馈所述目标案件审核不通过的相关信息。
  7. 根据权利要求6所述的理赔案件处理装置，其特征在于，所述案件类型确认模块包括：
    险种查询单元，用于查询保险公司的后台数据库确定与所述报案信息对应的有效保单的险种；
    第一确认单元，用于根据所述险种确定所述报案信息对应的所述案件类型；
    或
    关键字提取单元，用于从所述报案信息中提取预设关键字属性的值；
    类型匹配单元，用于将提取得到的所述关键字属性的值与预设的案件类型集合中各个案件类型的属性值进行一一匹配，选取匹配度最高的一个案件类型作为所述报案信息对应的案件类型。
  8. 根据权利要求6所述的理赔案件处理装置，其特征在于，所述案件关键信息通过以下模块提取得到：
    关键信息提取模块，用于根据所述目标模板从保险公司的后台数据库中提取所需的案件关键信息；
    第一触发模块，用于若所述关键信息提取模块提取得到的所述案件关键信息已完整，则触发所述信息录入模块；
    第二触发模块，用于若所述关键信息提取模块提取得到的所述案件关键信息未完整，则确定所述案件关键信息的缺失部分所对应的对接系统，然后从确定的所述对接系统中提取所述案件关键信息的缺失部分，在所述缺失部分提取成功后，触发所述信息录入模块。
  9. 根据权利要求6所述的理赔案件处理装置，其特征在于，所述案件审核模块包括：
    征信信息获取单元，用于从对接的征信系统中获取所述目标案件对应出险人的征信信息；
    风险评估单元，用于根据所述出险人的征信信息和预设的风控规则对所述目标案件进行风险评估，得到所述目标案件的风险等级；
    第一不通过确定单元，用于若所述目标案件的风险等级高于预设的风控等级阈值，则确定所述目标案件的审核不通过；
    或
    剩余保额获取单元，用于从保险公司的后台数据库中获取所述目标案件对应有效保单的剩余保额；
    第二不通过确定单元，用于若所述剩余保额为0，则确定所述目标案件的审核不通过。
  10. 根据权利要求6至9任一项所述的理赔案件处理装置，其特征在于，所述理赔模块包括：
    案件账单获取单元，用于通过保险公司的后台数据库获取所述目标案件的各个账单；
    赔付场景确定单元，用于根据所述目标案件的案件信息和所述各个账单的账单信息确定所述目标案件的各个待赔付场景；
    赔付金额计算单元，用于根据所述目标案件下各个受理保单的保单信息和所述各个账单的账单信息按照预设的理算规则分别计算各个所述待赔付场景的赔付金额；
    案件理赔金计算单元，用于计算各个所述待赔付场景的赔付金额之和，得到所述目标案件的理赔金。
  11. 一种终端设备，其特征在于，包括存储器以及处理器，所述存储器中存储有可在所述处理器上运行的计算机可读指令，所述处理器执行所述计算机可读指令时实现如下步骤：
    获取请求人的理赔报案请求并受理，得到报案信息，所述理赔报案请求中包括所述报案信息；
    根据所述报案信息确定对应的案件类型；
    根据确定的所述案件类型从预设的案件模板中选取一个案件模板作为目标模板；
    将所述报案信息和案件关键信息录入至所述目标模板中，得到报案文件，所述案件关键信息为根据所述报案信息采用数据直连的方式从保险公司的后台数据库和/或预设的对接系统中提取得到；
    通过保险公司的案件生成系统根据所述报案文件生成与所述理赔报案请求对应的目标案件；
    按照预设的审核规则对所述目标案件进行审核；
    若审核通过，则计算所述目标案件的理赔金，并根据计算得到的所述理赔金进行赔付处理；
    若审核不通过，则生成并反馈所述目标案件审核不通过的相关信息。
  12. 根据权利要求11所述的终端设备，其特征在于，所述根据所述报案信息确定对应的案件类型包括：
    查询保险公司的后台数据库确定与所述报案信息对应的有效保单的险种；
    根据所述险种确定所述报案信息对应的所述案件类型；
    或
    从所述报案信息中提取预设关键字属性的值；
    将提取得到的所述关键字属性的值与预设的案件类型集合中各个案件类型的属性值进行一一匹配，选取匹配度最高的一个案件类型作为所述报案信息对应的案件类型。
  13. 根据权利要求11所述的终端设备，其特征在于，所述案件关键信息通过以下步骤提取得到：
    根据所述目标模板从保险公司的后台数据库中提取所需的案件关键信息；
    若提取得到的所述案件关键信息已完整，则执行将所述报案信息和案件关键信息录入至所述目标模板中的步骤；
    若提取得到的所述案件关键信息未完整，则确定所述案件关键信息的缺失部分所对应的对接系统，然后从确定的所述对接系统中提取所述案件关键信息的缺失部分，在所述缺失部分提取成功后，执行将所述报案信息和案件关键信息录入至所述目标模板中的步骤。
  14. 根据权利要求11所述的终端设备，其特征在于，所述按照预设的审核规则对所述目标案件进行审核包括：
    从对接的征信系统中获取所述目标案件对应出险人的征信信息；
    根据所述出险人的征信信息和预设的风控规则对所述目标案件进行风险评估，得到所述目标案件的风险等级；
    若所述目标案件的风险等级高于预设的风控等级阈值，则确定所述目标案件的审核不通过；
    或
    从保险公司的后台数据库中获取所述目标案件对应有效保单的剩余保额；
    若所述剩余保额为0，则确定所述目标案件的审核不通过。
  15. 根据权利要求11至14任一项所述的终端设备，其特征在于，所述计算所述目标案件的理赔金包括：
    通过保险公司的后台数据库获取所述目标案件的各个账单；
    根据所述目标案件的案件信息和所述各个账单的账单信息确定所述目标案件的各个待赔付场景；
    根据所述目标案件下各个受理保单的保单信息和所述各个账单的账单信息按照预设的理算规则分别计算各个所述待赔付场景的赔付金额；
    计算各个所述待赔付场景的赔付金额之和，得到所述目标案件的理赔金。
  16. 一种计算机可读存储介质，所述计算机可读存储介质存储有计算机可读指令，其特征在于，所述计算机可读指令被至少一个处理器执行时实现如下步骤：
    获取请求人的理赔报案请求并受理，得到报案信息，所述理赔报案请求中包括所述报案信息；
    根据所述报案信息确定对应的案件类型；
    根据确定的所述案件类型从预设的案件模板中选取一个案件模板作为目标模板；
    将所述报案信息和案件关键信息录入至所述目标模板中，得到报案文件，所述案件关键信息为根据所述报案信息采用数据直连的方式从保险公司的后台数据库和/或预设的对接系统中提取得到；
    通过保险公司的案件生成系统根据所述报案文件生成与所述理赔报案请求对应的目标案件；
    按照预设的审核规则对所述目标案件进行审核；
    若审核通过，则计算所述目标案件的理赔金，并根据计算得到的所述理赔金进行赔付处理；
    若审核不通过，则生成并反馈所述目标案件审核不通过的相关信息。
  17. 根据权利要求16所述的计算机可读存储介质，其特征在于，所述根据所述报案信息确定对应的案件类型包括：
    查询保险公司的后台数据库确定与所述报案信息对应的有效保单的险种；
    根据所述险种确定所述报案信息对应的所述案件类型；
    或
    从所述报案信息中提取预设关键字属性的值；
    将提取得到的所述关键字属性的值与预设的案件类型集合中各个案件类型的属性值进行一一匹配，选取匹配度最高的一个案件类型作为所述报案信息对应的案件类型。
  18. 根据权利要求16所述的计算机可读存储介质，其特征在于，所述案件关键信息通过以下步骤提取得到：
    根据所述目标模板从保险公司的后台数据库中提取所需的案件关键信息；
    若提取得到的所述案件关键信息已完整，则执行将所述报案信息和案件关键信息录入至所述目标模板中的步骤；
    若提取得到的所述案件关键信息未完整，则确定所述案件关键信息的缺失部分所对应的对接系统，然后从确定的所述对接系统中提取所述案件关键信息的缺失部分，在所述缺失部分提取成功后，执行将所述报案信息和案件关键信息录入至所述目标模板中的步骤。
  19. 根据权利要求16所述的计算机可读存储介质，其特征在于，所述按照预设的审核规则对所述目标案件进行审核包括：
    从对接的征信系统中获取所述目标案件对应出险人的征信信息；
    根据所述出险人的征信信息和预设的风控规则对所述目标案件进行风险评估，得到所述目标案件的风险等级；
    若所述目标案件的风险等级高于预设的风控等级阈值，则确定所述目标案件的审核不通过；
    或
    从保险公司的后台数据库中获取所述目标案件对应有效保单的剩余保额；
    若所述剩余保额为0，则确定所述目标案件的审核不通过。
  20. 根据权利要求16至19任一项所述的计算机可读存储介质，其特征在于，所述计算所述目标案件的理赔金包括：
    通过保险公司的后台数据库获取所述目标案件的各个账单；
    根据所述目标案件的案件信息和所述各个账单的账单信息确定所述目标案件的各个待赔付场景；
    根据所述目标案件下各个受理保单的保单信息和所述各个账单的账单信息按照预设的理算规则分别计算各个所述待赔付场景的赔付金额；
    计算各个所述待赔付场景的赔付金额之和，得到所述目标案件的理赔金。
PCT/CN2018/081825 2017-04-14 2018-04-04 理赔案件处理方法、装置、终端设备及介质 WO2018188505A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201710245716.1A CN108257024B (zh) 2017-04-14 2017-04-14 一种理赔案件处理方法和装置
CN201710245716.1 2017-04-14

Publications (1)

Publication Number Publication Date
WO2018188505A1 true WO2018188505A1 (zh) 2018-10-18

Family

ID=62721828

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/081825 WO2018188505A1 (zh) 2017-04-14 2018-04-04 理赔案件处理方法、装置、终端设备及介质

Country Status (2)

Country Link
CN (1) CN108257024B (zh)
WO (1) WO2018188505A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111127222A (zh) * 2019-11-25 2020-05-08 泰康保险集团股份有限公司 业务服务的处理方法、装置、设备及存储介质

Families Citing this family (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109165849A (zh) * 2018-08-27 2019-01-08 众安信息技术服务有限公司 风险评估方法和装置
CN109472705B (zh) * 2018-09-26 2024-04-26 平安健康保险股份有限公司 理赔方法、系统、计算机设备以及存储介质
CN109447828A (zh) * 2018-10-22 2019-03-08 平安医疗健康管理股份有限公司 一种保险理赔方法及装置
CN109492135B (zh) * 2018-10-27 2024-03-19 平安科技（深圳）有限公司 一种基于数据处理的数据审核方法以及装置
CN109559237B (zh) * 2018-10-27 2024-06-18 深圳平安医疗健康科技服务有限公司 药品报销信息异常的方法和装置
CN109523398B (zh) * 2018-10-27 2024-05-14 深圳平安医疗健康科技服务有限公司 药品报销信息异常的方法和装置
CN109522387B (zh) * 2018-10-27 2023-07-14 平安医疗健康管理股份有限公司 基于数据处理的腰椎盘突出资质认证方法、设备及服务器
CN109615534A (zh) * 2018-10-29 2019-04-12 平安医疗健康管理股份有限公司 风控审核模型生成方法、装置、设备及可读存储介质
CN109636624A (zh) * 2018-10-29 2019-04-16 平安医疗健康管理股份有限公司 风控审核模型的生成方法、装置、设备及存储介质
CN109636625A (zh) * 2018-10-31 2019-04-16 深圳壹账通智能科技有限公司 保险电子合同的处理方法及装置、存储介质、计算机设备
CN109523409A (zh) * 2018-11-09 2019-03-26 泰康保险集团股份有限公司 数据处理方法、装置、介质及电子设备
CN109271564B (zh) * 2018-11-13 2021-03-23 泰康保险集团股份有限公司 保单查询方法及设备
CN109697673B (zh) * 2018-12-13 2024-06-25 深圳平安医疗健康科技服务有限公司 失业险核损数据分析方法、服务器及计算机可读存储介质
CN109785164A (zh) * 2018-12-13 2019-05-21 平安医疗健康管理股份有限公司 一种意外险核责数据处理方法、服务器及计算机可读介质
CN109710568A (zh) * 2018-12-18 2019-05-03 深圳壹账通智能科技有限公司 理赔文件格式标准化处理的方法、装置、介质及电子设备
CN109801174B (zh) * 2018-12-26 2023-11-17 平安科技（深圳）有限公司 理赔数据处理方法、装置、设备及计算机可读存储介质
CN111445261A (zh) * 2018-12-29 2020-07-24 达丰(上海)电脑有限公司 客户理赔案件的处理方法、系统、电子终端、及存储介质
CN110147982A (zh) * 2019-04-16 2019-08-20 深圳壹账通智能科技有限公司 基于客户请求的自动审核方法、装置、计算机设备及存储介质
CN110246046B (zh) * 2019-04-24 2023-01-10 创新先进技术有限公司 健康告知案例维护系统、方法以及装置
CN110276520B (zh) * 2019-05-15 2023-01-10 创新先进技术有限公司 项目案件筛选方法以及装置
CN110276696A (zh) * 2019-05-20 2019-09-24 阿里巴巴集团控股有限公司 基于互助项目的资助处理系统、方法以及装置
CN110310208B (zh) * 2019-05-27 2023-01-10 创新先进技术有限公司 项目赔审申请处理方法及装置
CN110689441B (zh) * 2019-08-15 2023-06-27 平安健康保险股份有限公司 基于共性抽取的案件审核方法、装置、设备及存储介质
CN110728582B (zh) * 2019-09-05 2022-03-08 德联易控科技(北京)有限公司 信息处理的方法、装置、存储介质和处理器
CN110675270A (zh) * 2019-09-05 2020-01-10 平安健康保险股份有限公司 基于发票信息的医保扣费金额的确定方法和装置
CN111104779B (zh) * 2019-11-13 2023-09-29 泰康保险集团股份有限公司 理赔业务处理方法、装置、介质及电子设备
CN111179092A (zh) * 2019-11-15 2020-05-19 泰康保险集团股份有限公司 一种保险理赔方法、装置、电子设备及存储介质
CN111161088A (zh) * 2019-12-31 2020-05-15 上海亿保健康管理有限公司 票据处理方法、装置和设备
CN111784525A (zh) * 2020-07-10 2020-10-16 支付宝(杭州)信息技术有限公司 基于多方安全计算的保险理赔请求处理方法、装置和系统
CN112288584B (zh) * 2020-10-29 2024-05-17 泰康保险集团股份有限公司 保险报案处理方法、装置、计算机可读介质及电子设备
CN112634064A (zh) * 2020-12-02 2021-04-09 北京健康之家科技有限公司 理赔智能审核方法及装置、系统、存储介质
CN113283996A (zh) * 2021-05-27 2021-08-20 北京健康之家科技有限公司 一种保单筛选方法及存储介质
CN113537774B (zh) * 2021-07-16 2023-04-07 精英数智科技股份有限公司 一种煤矿企业保单是否有效的检测方法及系统
CN113723812A (zh) * 2021-08-30 2021-11-30 平安国际智慧城市科技股份有限公司 基于项目申报的数据处理方法及装置
CN114372890B (zh) * 2022-01-12 2023-03-07 中国人民健康保险股份有限公司深圳分公司 一种保险自助理赔管理方法和系统
CN115049512A (zh) * 2022-06-27 2022-09-13 安诚财产保险股份有限公司 一种智能理赔核算系统

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101546416A (zh) * 2009-04-27 2009-09-30 谢谦 一种远程处理汽车保险业务的方法及其系统
CN105355034A (zh) * 2015-10-28 2016-02-24 重庆邮电大学 一种交通事故现场证据采集与保全系统及其方法
CN105915853A (zh) * 2016-05-27 2016-08-31 大连楼兰科技股份有限公司 基于红外感知的远程无人定损方法及系统
US20160275521A1 (en) * 2015-03-19 2016-09-22 Warrantx, Inc. Integrated electronic warranty platform
CN106056451A (zh) * 2016-05-27 2016-10-26 大连楼兰科技股份有限公司 基于车辆obd传感器的远程无人定损系统
CN106530093A (zh) * 2016-08-29 2017-03-22 惠州市沛宸信息技术有限公司 交通事故保险理赔案件质量的评估系统

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101546416A (zh) * 2009-04-27 2009-09-30 谢谦 一种远程处理汽车保险业务的方法及其系统
US20160275521A1 (en) * 2015-03-19 2016-09-22 Warrantx, Inc. Integrated electronic warranty platform
CN105355034A (zh) * 2015-10-28 2016-02-24 重庆邮电大学 一种交通事故现场证据采集与保全系统及其方法
CN105915853A (zh) * 2016-05-27 2016-08-31 大连楼兰科技股份有限公司 基于红外感知的远程无人定损方法及系统
CN106056451A (zh) * 2016-05-27 2016-10-26 大连楼兰科技股份有限公司 基于车辆obd传感器的远程无人定损系统
CN106530093A (zh) * 2016-08-29 2017-03-22 惠州市沛宸信息技术有限公司 交通事故保险理赔案件质量的评估系统

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111127222A (zh) * 2019-11-25 2020-05-08 泰康保险集团股份有限公司 业务服务的处理方法、装置、设备及存储介质
CN111127222B (zh) * 2019-11-25 2023-04-18 泰康保险集团股份有限公司 业务服务的处理方法、装置、设备及存储介质

Also Published As

Publication number Publication date
CN108257024A (zh) 2018-07-06
CN108257024B (zh) 2020-04-24

Similar Documents

Publication Publication Date Title
WO2018188505A1 (zh) 理赔案件处理方法、装置、终端设备及介质
US11791046B2 (en) Systems and methods of managing payments that enable linking accounts of multiple guarantors
CN109509078B (zh) 基于区块链的借贷运行方法、系统、服务器及存储介质
US11657912B2 (en) Devices, systems, and their methods of use for evaluating and processing remuneration claims from third-party obligator
US11170376B2 (en) Informational and analytical system and method for ensuring the level of trust, control and secure interaction of counterparties when using electronic currencies and contracts
US10262374B2 (en) System and method for processing payment bundles
US20180089379A1 (en) Healthcare claim analysis network
CN110458691B (zh) 一种贷前风险监控方法及装置
WO2020119097A1 (zh) 一种数据标准化处理方法、装置及存储介质
WO2018184550A1 (zh) 理赔金的计算方法、装置、终端设备及介质
US10366351B2 (en) Information standardization and verification
US20180365761A1 (en) Platform for financing healthcare services
US20230306526A1 (en) Retail hsa funding and payment mechanism
CN110489434B (zh) 一种信息处理方法及相关设备
CN109035033B (zh) 一种减保业务的信息处理方法及终端
CN111161088A (zh) 票据处理方法、装置和设备
Trish Medicare Part D: Time for Re‐Modernization?
US20220093225A1 (en) System and Method for Patient Data Provision, Consumption, and Royalty Processing
CN111932196A (zh) 案件处理方法、装置、设备及可读存储介质
CN110704866B (zh) 基于区块链的请求处理方法及请求处理装置
AU2015100898A4 (en) A method and apparatus for facilitating capital raising
US20220101426A1 (en) Platform for financing healthcare services
Corlette et al. Proposed 2025 payment rule: marketplace standards and insurance reforms
US20160203553A1 (en) Method and apparatus for facilitating capital raising
CN113888335A (zh) 保险理算方法、装置、计算机设备及存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18784051

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 22/01/2020)

122 Ep: pct application non-entry in european phase

Ref document number: 18784051

Country of ref document: EP

Kind code of ref document: A1