An electronic ticket data processing method, device and system

Abstract

This application discloses an electronic invoice data processing method, apparatus, and system, solving the problems of low efficiency, inaccurate verification, and easy occurrence of duplicate or fraudulent claims in the manual processing of medical electronic invoice claims in the prior art. The method is executed by a first server device and includes: receiving claim initiation data containing electronic invoice identification information; determining and querying the target external system based on the identification information to obtain invoice status information (authenticity, cancellation, interbank reimbursement status) and invoice details; performing logical judgment on the invoice status information according to insurance claim rules to generate claim judgment status data; when a claim is deemed eligible, associating it with the insurance policy and calculating the claim amount based on policy rules and invoice details; and finally sending the claim result. This application achieves full-process automation from invoice verification and risk control decision-making to claim calculation and payment, significantly improving processing efficiency and accuracy, and effectively preventing risks such as invoice forgery and duplicate claims.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to an electronic ticket data processing method, apparatus and system. Background Technology

[0002] With the comprehensive advancement of electronic medical billing management reform, more and more customers are using electronic bills to apply for insurance claims, a stark contrast to the previous method of submitting paper invoices. To address this change, corresponding electronic billing claims service application models and systems have emerged in the existing technology landscape. This system, based on big data, the internet, intelligent technologies, and automation, utilizes an open platform with multiple service interfaces specifically designed to connect internal systems with external data sources. It also deploys various data interaction standards and rules in the data transmission interfaces and core systems. The system supports automatic recognition of electronic bill numbers, verification codes, and other information using technologies such as Optical Character Recognition (OCR). After recognition, it automatically verifies the authenticity of the bill with third-party systems and automatically acquires the electronic bill data. Simultaneously, the system can obtain the latest status of electronic bills, such as whether the bill has been reversed, whether the invoice has been reimbursed by the insurance company, and whether the invoice has been verified by the insurance company, and can also obtain the insurance company's reimbursement records. Furthermore, after a customer's medical treatment is completed and an electronic bill is generated, the system can obtain the customer's accident information, thereby providing proactive services such as visiting and offering condolences, and assisting in compiling claims documents. Finally, after receiving the electronic invoice data, the system can intelligently match the customer's policy liability, compensation plan and settlement rules, and realize the rapid processing and payment of insurance claims through fully automated settlement.

[0003] However, the existing technical solution still faces the following prominent problems when processing electronic invoices: First, electronic invoices pose a significant risk of forgery. Electronic invoices downloaded and printed by customers are easily forged or altered, and the existing solution's verification process lacks sufficient automation and closed-loop functionality, making it difficult to effectively prevent fraudulent claims. Second, electronic invoice claims carry the risk of duplicate reimbursements from other companies and the risk of invoices being reversed (refunded) after a claim is made. Because the existing solution lacks a real-time, reliable, and systematic verification mechanism with an authoritative source of invoice status, it cannot ensure the uniqueness and validity of invoices during the claims decision-making process, potentially leading to duplicate payments or financial losses due to invoices becoming invalid after payment. Finally, the existing claims service still starts with the customer reporting and applying after an incident, which is a passive response model. It fails to fully utilize the invoice generation event to proactively trigger the entire process, resulting in a need to improve both service experience and processing efficiency.

[0004] Therefore, there is an urgent need for a processing method and device that can process electronic invoices more securely and efficiently, and can realize proactive, closed-loop claims services. Summary of the Invention

[0005] This application proposes an electronic invoice data processing method, apparatus, and system to solve the problems of unreliable invoice authenticity verification and lack of real-time status verification caused by the lack of an automated and reliable closed-loop interaction with external authoritative systems in the prior art.

[0006] In a first aspect, embodiments of this application provide an electronic invoice data processing method for a first server device, comprising the following steps:

[0007] Receive claim initiation data containing identification information of electronic invoices;

[0008] Based on the identification information, the target external system is identified and a query is initiated to obtain the electronic invoice's status information and detailed data; the invoice status information indicates at least one or more of the following: invoice authenticity status, invoice cancellation status, and interbank reimbursement status.

[0009] According to the insurance claims rules, the status information of the invoice is logically judged to generate claims judgment status data;

[0010] When the claims assessment status data indicates that the invoice is eligible for claim, the corresponding policy is associated with the identification information, and the claim amount is calculated based on the policy's claims rules and the invoice details.

[0011] Send claim result information containing the claimed amount.

[0012] In one embodiment, determining the target external system identifier includes any of the following methods:

[0013] Extract the target external system identifier from the claim initiation data;

[0014] Based on the identification information of the electronic ticket, a predetermined mapping relationship is queried to determine the identifier of the target external system;

[0015] The predetermined fixed identifier is used as the identifier of the target external system.

[0016] In one embodiment, the request to initiate the query includes a bill query instruction, specifically an instruction to request the bill service system of a finance or medical institution to verify the authenticity of the bill and query the reimbursement status of the bill.

[0017] In one embodiment, the invoice status information includes at least the invoice authenticity status, invoice cancellation status, and interbank reimbursement status provided by the external system authority.

[0018] In one embodiment, the claims judgment status data is a binary decision identifier generated after logically judging the authenticity status of the invoice, the invoice cancellation status, and the interbank reimbursement status according to the insurance claims rules.

[0019] In one embodiment, before transmitting the claims result information, the method further includes: generating an active claims service trigger instruction based on the claims judgment status data.

[0020] In one embodiment, after generating the claims assessment status data, the method further includes:

[0021] Based on the claims assessment status data and user historical behavior data, the risk score of the current invoice is calculated through a risk decision model.

[0022] If the risk score is lower than the first threshold, the step of calculating the claim amount is automatically triggered;

[0023] If the risk score is between the first threshold and the second threshold, the case will be transferred to the manual review queue.

[0024] If the risk score is higher than the second threshold, a fraud investigation process will be triggered and the claims processing rights of the associated policies will be frozen.

[0025] In one embodiment, the step of calculating the claim amount is performed by a second server device; the second server device adopts a microservice architecture, receives data through an API gateway, and asynchronously notifies the payment service and message push service through a message middleware after the calculation is completed.

[0026] Secondly, embodiments of this application also provide an electronic invoice data processing apparatus for implementing the electronic invoice data processing method described in any embodiment of the first aspect, comprising: a receiving module, configured to receive claim initiation data containing identification information of an electronic invoice; and further configured to acquire invoice status information and invoice detail data of the electronic invoice; wherein the invoice status information indicates at least one or more of the following: invoice authenticity status, invoice cancellation status, and interbank reimbursement status. A determining module, configured to determine a target external system based on the identification information. A sending module, configured to send a query request to the target external system; and further configured to send claim result information containing the claim amount. A processing module, configured to perform logical judgment on the invoice status information according to insurance claim rules to generate claim judgment status data; and further configured to, when the claim judgment status data indicates that the invoice is eligible for claim, associate the corresponding insurance policy with the identification information, and calculate the claim amount based on the claim rules of the insurance policy and the invoice detail data.

[0027] Thirdly, embodiments of this application also provide an electronic invoice claims processing system, including:

[0028] A first server device is deployed with the apparatus described in the second aspect embodiment, or configured to perform the method described in any of the first aspect embodiments. A second server device, communicatively connected to the first server device, is configured to, when the claims assessment status data generated by the first server device indicates that the invoice is eligible for claim, determine the associated policy based on the identification information, and determine the claim amount based on the policy's claims rules and the invoice details data. A terminal device, communicatively connected to the first server device and / or the second server device, is configured to send claims initiation data containing electronic invoice identification information and receive claims result information containing the claim amount.

[0029] The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects:

[0030] This application achieves intelligent processing of the entire process from electronic invoice generation to insurance payout by constructing an automated data interaction channel with external invoice service systems (such as those of finance and medical institutions). First, the system can automatically and in real-time verify the authenticity of electronic invoices and obtain their authoritative status (e.g., whether they have been cancelled or reimbursed by other institutions), fundamentally solving the problems of easy forgery and alteration of electronic invoices, as well as the risks of duplicate reimbursement and returned invoices, significantly strengthening the risk management capabilities of claims processing. Second, through the aforementioned reliable data acquisition and standardized processing, the system can automatically match policy liabilities and intelligently calculate insurance claims, greatly reducing manual data entry, verification, and calculation steps, lowering operating costs, and improving the efficiency and accuracy of claims processing. Finally, by proactively acquiring invoice generation information or standardized data, the system can proactively trigger service processes such as reporting incidents and providing customer support, changing the traditional passive response service model and improving customer experience and service stickiness. In summary, this application provides a secure, efficient, and proactive overall solution for electronic invoice insurance claims processing. Attached Figure Description

[0031] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0032] Figure 1 This is a schematic diagram illustrating the interaction timing of the electronic invoice insurance claims processing method according to an embodiment of this application;

[0033] Figure 2 This is a flowchart of the electronic invoice data processing method according to an embodiment of this application;

[0034] Figure 3 This is a flowchart illustrating electronic invoice data processing for a first server device, as described in an embodiment of this application.

[0035] Figure 4 This is a flowchart illustrating electronic invoice data processing for a second server device, as described in an embodiment of this application.

[0036] Figure 5 This is a flowchart illustrating the electronic invoice data processing for a terminal device according to an embodiment of this application;

[0037] Figure 6 This is a schematic diagram of the proactive service and risk control system architecture according to an embodiment of this application;

[0038] Figure 7 This is an end-to-end flowchart of the customer's medical visit to the claims process, as illustrated in this application.

[0039] Figure 8 This is a flowchart illustrating the overall claims and invoice processing procedures in an embodiment of this application.

[0040] Figure 9 This is an architecture diagram of a medical image recognition and medical data open platform according to an embodiment of this application;

[0041] Figure 10 This is a structural diagram of an electronic invoice data processing device according to an embodiment of this application;

[0042] Figure 11 This is a system diagram illustrating an application scenario in an embodiment of this application;

[0043] Figure 12 This is a structural diagram of the first server device according to an embodiment of this application;

[0044] Figure 13 This is a structural diagram of the second server device according to an embodiment of this application;

[0045] Figure 14 This is a structural diagram of a terminal device according to an embodiment of this application;

[0046] Figure 15 This is a schematic diagram of the structure of a first server device according to another embodiment of this application;

[0047] Figure 16 This is a schematic diagram of the structure of a second server device according to another embodiment of this application;

[0048] Figure 17 This is a schematic diagram of the structure of a terminal device according to another embodiment of this application. Detailed Implementation

[0049] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0050] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0051] Figure 1 This is a schematic diagram illustrating the interaction timing of the electronic invoice insurance claims processing method according to an embodiment of this application.

[0052] like Figure 1 As shown, this application embodiment provides a complete interactive process from electronic invoice generation to proactive claims service. First, after the patient completes their medical treatment and payment at the medical institution, a third-party invoice service platform generates an electronic invoice and issues an invoice notification (step ③). The system of this application (such as deployed on the first server) obtains this notification through interface listening or receiving, and automatically initiates a claims inquiry to the third-party platform (step ④). After the customer's medical treatment is completed and an electronic invoice is generated, the company can obtain the customer's claim information immediately. After obtaining the invoice information and performing automated verification and status checks, the system internally generates claim information and transmits it (step ⑧), and can simultaneously report the reimbursement status of the invoice to the third-party platform (step ⑨). On the other hand, the system proactively pushes service reminders containing the claim entry point to the user's terminal through messaging services (such as mini-program notifications), thereby transforming the traditional passive claims application into a proactive service driven by invoice events. In addition, users can also download the invoice themselves through their terminals (step ⑦) and submit it to trigger subsequent processing.

[0053] Figure 2 This is a flowchart of an electronic invoice data processing method according to an embodiment of this application.

[0054] In a first aspect, embodiments of this application provide an electronic invoice data processing method for a first server device, comprising the following steps:

[0055] Step 210: Receive claim initiation data containing identification information of electronic invoices.

[0056] Specifically, the first server device serves as the core of the claims system's access and processing, receiving data input from upstream. For example, when a customer submits a claims application through a terminal application, the terminal sends a data packet containing an image of the electronic invoice or an invoice identifier to the server; or, after integration with the hospital information system, the server directly receives structured messages pushed by the hospital system when the electronic invoice is generated. The core of this data input is information that uniquely identifies an electronic invoice, such as the invoice code and invoice number of a fiscal electronic invoice.

[0057] Step 220: Based on the identification information, identify the target external system and initiate a query to obtain the electronic invoice status information and invoice details; the invoice status information indicates at least one or more of the following: invoice authenticity status, invoice cancellation status, and interbank reimbursement status.

[0058] Specifically, the system parses the ticket identifier according to a preset routing strategy to determine the external system identifier for authoritative verification and status query. After determining the target system, the system assembles a standardized query request according to pre-configured interface rules and sends it.

[0059] Step 230: According to the insurance claim rules, perform logical judgment on the status information of the invoice to generate claim judgment status data.

[0060] Specifically, upon receiving a response from an external system, the system performs a comprehensive logical judgment on the acquired invoice status information (such as authenticity, cancellation status, and interbank reimbursement status) based on preset insurance claims business rules. This rule is often a logical "AND" relationship: for example, the most basic conditions for claim acceptance are met only when the invoice verification result is true, the invoice cancellation status is not cancelled, and the interbank reimbursement status is not reimbursed.

[0061] Step 240: When the claims judgment status data indicates that the invoice is eligible for claim, the corresponding policy is associated with the identification information, and the claim amount is calculated based on the policy's claims rules and the invoice details.

[0062] Specifically, when the claims assessment status data indicates that a claim is eligible (e.g., marked as 1), the system automatically queries and associates the corresponding valid policy in the policy database based on the identification information of the electronic invoice (such as the patient's identity information contained therein). Then, the system extracts the policy's insurance liability, deductible, reimbursement ratio, and other rules, and combines this with structured invoice details obtained from external systems (such as the amount paid out of pocket after medical insurance settlement and a detailed list of expenses eligible for insurance coverage), automatically executing the claims calculation logic to determine the amount to be reimbursed.

[0063] Step 250: Send claim result information containing the claim amount.

[0064] Finally, the system will send out the processing result information, including the calculated claim amount.

[0065] The first server device can serve as the carrier for more detailed modules in subsequent specific embodiments.

[0066] It should be noted that, Figures 3-5 Specific implementations of the electronic invoice data processing method of this application are provided on different devices or at different levels of detail. They are related to... Figure 2 The core method embodiments shown belong to the same inventive concept. The specific wording of the terminology may differ in different embodiments, but the technical features referred to correspond to the functions implemented. For example, Figure 3 The first data set in the middle corresponds to Figure 2 Claim initiation data in the example; Figure 5 Actions on the mid-terminal side and Figure 2 The process of receiving claim initiation data from the first server in China is coordinated.

[0067] Figure 3 This is a flowchart illustrating electronic invoice data processing for a first server device, as described in an embodiment of this application.

[0068] The electronic invoice data processing method provided in this application encompasses multiple stages, including system integration, intelligent invoice recognition, automatic data transmission, automatic invoice data acquisition, automatic invoice verification, and proactive electronic invoice services. This invention includes processes such as system integration, intelligent invoice OCR recognition, automatic data transmission, automatic invoice data acquisition, automatic invoice verification, and proactive electronic invoice services. The following is a detailed explanation... Figure 3 A specific implementation method will be described in detail.

[0069] This application provides an electronic invoice data processing method for a first server device, comprising the following steps:

[0070] Step 310: Receive the first data set; the first data set contains the identification information of the electronic ticket.

[0071] In this embodiment of the application, the first server device first receives data input from the upstream.

[0072] This data input is collectively referred to as the first data set, the core of which contains information that can uniquely identify an electronic ticket.

[0073] Step 320: Determine the target external system identifier based on the predetermined routing strategy and the identification information.

[0074] Determining the target external system identifier involves analyzing the ticket identifier based on preset logical rules to generate an internal code pointing to a specific external query system.

[0075] In one embodiment, determining the target external system identifier includes any of the following methods:

[0076] Method 1: Extract the target external system identifier from the first data set.

[0077] In addition to the ticket identification information, the first dataset may already contain explicit target system instruction information. The system can obtain the target identifier by directly reading the field value corresponding to this instruction information.

[0078] This approach is suitable when the upstream caller has clearly known and specified the query target, and the routing decision is made upfront.

[0079] Method 2: Based on the identification information of the electronic ticket, query the predetermined mapping relationship to determine the target external system identifier;

[0080] The system makes routing decisions by parsing the ticket identifier and querying this mapping table.

[0081] The predetermined fixed identifier is used as the identifier of the target external system.

[0082] In scenarios where the system interfaces with only a single, fixed external invoice service system, dynamic judgment is unnecessary. A fixed target identifier is pre-defined in the system configuration, and all invoice query requests are directed to this system.

[0083] Step 330: Based on the target external system identifier, obtain the corresponding pre-configured interface rules and generate request data.

[0084] Once the target system is determined, the system invokes pre-configured communication rules for that external system. These rules typically include network addresses, communication protocols, data format templates, and necessary security authentication information. The system then uses the ticket identification information obtained in step 310 to fill in the template and assemble a formatted query request. This process is known as generating request data.

[0085] Step 340: Send request data; the request data includes a ticket query instruction generated based on the identification information.

[0086] The system will send the generated request data to the target external system through the interface rules determined in step 330.

[0087] After automatically recognizing electronic invoice information, the system automatically sends the electronic invoice recognition data through system integration and interacts with third-party systems.

[0088] For example, the requested data sent is essentially an instruction that asks the other system to verify the authenticity of the ticket and return its current status.

[0089] In one embodiment, the request data includes a bill inquiry instruction, specifically an instruction to request verification of the authenticity of a bill and to inquire about the reimbursement status of a bill from the bill service system of a finance or medical institution.

[0090] This embodiment specifies the purpose and target of the request instruction.

[0091] The core of the request instruction is to request a comprehensive query, and its target system is a financial or medical institution invoice service platform with authoritative data sources.

[0092] The embodiments of this application ensure that the requested data can accurately obtain two types of key information necessary for subsequent claims decisions: the authenticity of the invoice and the availability status of the invoice.

[0093] Step 350: Receive response data; the response data includes the ticket status information and ticket details data corresponding to the identification information.

[0094] After a request is sent, the system waits for and receives a response from the external system, i.e., response data. By transmitting electronic invoice information through the system, customer invoices can be directly located. Based on the invoice information, the current status of the invoice can be automatically queried, such as whether the electronic invoice is in a normal state, whether it has been reversed, whether the intermediary company has reimbursed it, whether the intermediary company has verified it, and whether the intermediary company is processing the claim. Simultaneously, after locating electronic invoices through system integration, detailed electronic invoice data and medical insurance reimbursement data can be directly obtained, allowing for direct system invoice entry and direct use in case settlement.

[0095] In one embodiment, the invoice status information included in the response data includes at least the invoice authenticity status, invoice cancellation status, and interbank reimbursement status provided by the external system authority.

[0096] This application embodiment clarifies the key state dimensions from an external authoritative source that must be included in the response data.

[0097] The authenticity status of a negotiable instrument is provided directly by the issuer or the verification platform, and is a determination of whether the instrument itself is genuine and valid.

[0098] The status of a bill being reversed indicates whether the bill has been voided or reversed in the issuer's system, and is used to determine whether the bill is currently valid and usable.

[0099] The interbank reimbursement status indicates whether the invoice has been processed or settled by other insurance institutions, thus preventing the risk of duplicate reimbursement. This effectively solves the problem of duplicate reimbursement of electronic invoices across different insurance companies.

[0100] For example, a response from a financial verification platform will inform you of the authenticity of the invoice and whether it has been reversed, while a response from a medical institution may provide additional information on the invoice's settlement and reimbursement records within the hospital.

[0101] Integrating these status information provided by different external systems forms a complete and reliable data foundation for subsequently determining whether the invoice can enter the claims process.

[0102] Step 360: Parse the response data according to the preset data parsing rules to generate a second data set; the second data set includes the identification information of the electronic invoice, the claims judgment status data, and the invoice details data; the claims judgment status data indicates at least one or more of the following: invoice authenticity status, invoice cancellation status, and interbank reimbursement status.

[0103] Upon receiving a response from an external system, the system needs to extract key information from the response based on pre-defined parsing rules, as the data formats may vary.

[0104] After automatically receiving the status of electronic invoices, reimbursement status from other companies, and structured invoice data, the system intelligently matches the customer's disease diagnosis, policy liability, claims settlement plan, and settlement rules in the core system.

[0105] After parsing, the system reorganizes all necessary information and packages it into a new, internally standardized data packet, namely the second data set.

[0106] This data package not only contains the original invoice identifier and details, but also status information that can be used for claims decisions after preliminary assessment, such as a clear conclusion: the invoice is genuine, there has been no red-inking, and no reimbursement records from other companies have been found.

[0107] In one embodiment, the claims judgment status data is a binary decision identifier generated after logically judging the authenticity status of the invoice, the invoice cancellation status, and the interbank reimbursement status according to the insurance claims rules.

[0108] Step 370: Send the second data set.

[0109] Sending the second data set is the operation of transmitting the data packets, which have undergone standardization and risk assessment, from the first server device to the downstream business system.

[0110] In another embodiment, a risk intelligence decision-making step is included after step 370:

[0111] Based on the claims assessment status data and user historical behavior data, the risk score of the current invoice is calculated through a risk decision model.

[0112] If the risk score is lower than the first threshold, the step of calculating the claim amount is automatically triggered;

[0113] If the risk score is between the first threshold and the second threshold, the case will be transferred to the manual review queue.

[0114] If the risk score is higher than the second threshold, a fraud investigation process will be triggered and the claims processing rights of the associated policies will be frozen.

[0115] The risk decision-making model integrates multi-factor verification mechanisms such as device fingerprinting, geographic location, and behavioral sequence analysis to perform real-time fraud scoring on claim initiation data.

[0116] In one embodiment, before sending the second data set in step 370, the method further includes the step of generating an active claims service trigger instruction based on the claims judgment status data.

[0117] When the claims status data indicates that the current invoice meets the claims conditions (i.e., claims can be processed), the system does not simply transmit data, but simultaneously generates an instruction to initiate proactive services. Specifically, the system publishes a "Pending Claims" event to the message queue, the task scheduling service consumes the event, and calls the customer relationship management system interface to automatically create a proactive outreach task and assign it to the appropriate customer service personnel.

[0118] Figure 4 This is a flowchart illustrating electronic ticket data processing for a second server device, as described in an embodiment of this application.

[0119] like Figure 4 As shown, this embodiment describes the aforementioned method (such as...). Figure 2 or Figure 3 As shown in the figure, after generating the judgment data indicating that the invoice is eligible for claim, the second server device performs subsequent claim calculations in a collaborative implementation method.

[0120] This application also provides an electronic invoice claims decision-making method for a second server device, comprising the following steps:

[0121] Step 410: Receive the second data set; the second data set includes the identification information of the electronic invoice, the claim assessment status data, and the invoice details data.

[0122] The second data set is a structured data packet transmitted from the first server or a third-party invoice service platform, which already contains key identification information, verification status, and expense details of the electronic invoice. This data set is used by the second server (i.e., the insurance company's claims system) for subsequent claims calculation and decision-making.

[0123] Step 420: In response to the claim determination status data indicating that the invoice is eligible for claim, associate the corresponding policy information according to the identification information.

[0124] When the claims assessment status data indicates that the electronic invoice meets the claims conditions, the system automatically queries the policy database and associates the corresponding policy information based on the identification information in the invoice. The identification information includes at least one or more of the following: invoice code, patient identification, and invoicing institution information. This association process is achieved by matching the patient identification with the policyholder information, or by binding the invoice code with pre-registered invoice information.

[0125] In one embodiment, the claimability of the bill is specifically as follows:

[0126] The claims assessment status data includes decision indicators that represent that the invoice has been verified, has not been reversed, and has not been reimbursed by other companies.

[0127] This decision identifier is generated by the first server or a third-party service platform after completing the invoice verification and status query. Its logic is based on a comprehensive judgment of the following three conditions:

[0128] Authenticity verified: This electronic invoice has been automatically verified by the system and confirmed to be genuine, valid, and unaltered.

[0129] Not cancelled: After checking the status of the invoice, the invoice has not been cancelled or cancelled by the issuer and is still in a valid state that can be reimbursed.

[0130] No reimbursement from other insurance companies: Through information sharing or inquiry mechanisms within the insurance industry, it is confirmed that the invoice has not been used for claims or has been reimbursed by other insurance companies.

[0131] Step 430: Generate a claims calculation instruction based on the policy information and the invoice details; the claims calculation instruction is used to calculate the claims amount according to preset claims calculation rules.

[0132] The system generates an instruction for calculating the claim amount based on the associated policy information (including but not limited to the scope of insurance liability, deductible, reimbursement ratio, limit, and exclusions) and detailed invoice data (including total cost, medical insurance settlement cost, personal out-of-pocket amount, and detailed expense items). This instruction determines the base amount and calculation method for the expenses to be included in the claim calculation according to the calculation rules stipulated in the policy.

[0133] Step 440: Run the claim calculation instruction to obtain the claim amount.

[0134] The second server executes the claims calculation instructions, automatically calculates the final claims amount, and completes the claims decision-making process. If the invoice details data supports further subdivision (such as including detailed items for medicines, medical treatments, etc.), the system can also filter and accumulate the detailed items according to the policy's coverage scope to achieve more accurate claims calculation.

[0135] The calculation results can be directly used to trigger subsequent payment processes.

[0136] Figure 5 This is a flowchart illustrating the electronic ticket data processing used in a terminal device according to an embodiment of this application. Figure 5 As shown, this embodiment provides an implementation method from the terminal device side that works in conjunction with the aforementioned first server-side method. The first data set or claim request sent by the terminal constitutes the claim initiation data received by the first server side.

[0137] This application also provides an electronic invoice claims information processing method for a terminal device, comprising the following steps:

[0138] Step 510: Send the first data set; the first data set contains the identification information of the electronic ticket.

[0139] The terminal device is used to initiate the claims process. When a user operates the terminal, the terminal sends claims initiation data containing electronic invoice identification information to the first server device to trigger subsequent invoice verification and claims calculation processes. The identification information of the electronic invoice can be obtained by the user scanning the invoice's QR code through the terminal application, or it can be pushed from the hospital system to the terminal and confirmed by the user.

[0140] Step 520: Receive processing result data; the processing result data shall include at least the claim amount.

[0141] The terminal device receives processing result data from the claims system server. This data includes at least the calculated claim amount, and may also include supplementary information such as claim status, estimated payment time, and reasons for rejection. Users can view the claim processing results directly on the terminal device without actively inquiring or waiting for manual notification.

[0142] In one embodiment, the method further includes:

[0143] Step 530: Send a claim request to the server based on the first data set; the claim request includes at least the identification information of the electronic invoice and the user's identity information.

[0144] After receiving the first set of data, the user terminal can automatically or after user confirmation send a claim request to the claims system server, thereby triggering the subsequent invoice verification and claims calculation process.

[0145] Figure 6 This is a schematic diagram of the proactive service and risk control system architecture in an embodiment of this application.

[0146] like Figure 6 As shown, this system adopts a cloud-native microservice architecture and achieves unified governance through an API gateway. External requests (from terminal devices or third-party platforms) all enter through the API gateway. Core business capabilities are provided by multiple independent microservices, including: invoice recognition service, verification gateway service, claims processing engine service, risk control decision service, message push service, and task scheduling service. Services communicate with each other via lightweight RPC or message queues. The verification gateway service in the system asynchronously processes invoice query requests through a message queue, temporarily storing the requests before forwarding them sequentially to the claims processing engine service. Specifically, the event listening module listens for external invoice events and publishes them to the message queue; the task scheduling service consumes events and generates proactive service tasks; and the risk control decision service provides real-time risk scoring. All microservices share a unified data persistence layer (policy database, invoice database, and log database). This architecture supports high concurrency, elastic scaling, and rapid iteration, and ensures loose coupling between proactive services, risk control, and core claims processes. This architecture is the core technological foundation for this application to realize a new model of big data and Internet+ insurance services, as well as to improve the quality of claims services and reduce claims processing costs.

[0147] Figure 7 This is an end-to-end flowchart of the customer's medical visit to the claims process in this application embodiment.

[0148] The electronic invoice data processing method provided in this application can automate the entire process from patient visit to insurance payment. This process involves collaborative operations between patient-side terminal devices, hospital electronic invoice systems, third-party invoice service platforms, and insurance claims systems.

[0149] The process includes the following steps in sequence, and these steps are consistent with those in this application. Figure 2 The steps in the illustrated method embodiments have a corresponding relationship:

[0150] ① The patient completes the consultation and treatment at the hospital.

[0151] Patients receive medical services at partner medical institutions and proceed to the settlement process after treatment.

[0152] ② The hospital's electronic invoice system generates electronic invoices.

[0153] Based on the settlement results, the hospital's internal information system automatically issues compliant electronic medical bills through an electronic billing platform approved by the local finance department or health commission. These bills contain detailed data such as the bill code, number, amount, chargeable items, and basic patient information.

[0154] ③ Patients pay and receive electronic invoices

[0155] After a patient completes payment via mobile payment or medical insurance settlement, the electronic invoice is automatically pushed to the patient's designated terminal device (such as a mobile app, WeChat mini-program, etc.). The patient can view, download, or forward the invoice in applications such as the electronic invoice wallet.

[0156] ④ The patient submits a claim application through the terminal.

[0157] After receiving the electronic invoice, the terminal device automatically or upon user confirmation initiates a claim application to the insurance claims system. The application information includes at least the electronic invoice's identification information (such as invoice code and number) and the patient's identity identifier. This step corresponds to step 210, where the first server device receives claim initiation data containing the electronic invoice's identification information.

[0158] ⑤ The claims system sends a data retrieval request to the third-party platform.

[0159] Upon receiving a claim application, the insurance claims system automatically initiates a data retrieval request to the connected third-party invoice service platform, carrying the invoice identifier and patient authorization information. This step corresponds to step 220, where the first server device identifies the target external system based on the identifier information and initiates a query against it.

[0160] ⑥-⑦ The third-party platform obtains and returns invoice verification and detail data.

[0161] The third-party platform retrieves complete invoice data from the hospital's electronic invoice system or the fiscal invoice database based on the invoice identifier, and performs authenticity verification, invoice cancellation status inquiry, and peer reimbursement status deduplication. After successful verification, the platform returns structured invoice details (such as total cost, medical insurance payment, personal out-of-pocket amount, and detailed expense list) to the insurance claims system. This step corresponds to the latter half of step 220, where the first server device obtains the invoice status information and invoice details of the electronic invoice.

[0162] ⑧ The claims system sends back structured data and triggers claims calculation.

[0163] After receiving structured data from a third-party platform, the insurance claims system automatically associates the patient's insurance policy, extracts the insurance liability rules, and executes the claims calculation logic based on the invoice details to generate the claims amount. This step corresponds to steps 230 and 240, where the first server device performs logical judgments based on the insurance claims rules to generate claims judgment status data, and calculates the claims amount by associating the policy when a claim is eligible.

[0164] 9. The claims system pays insurance benefits.

[0165] After the calculation is completed, the system automatically triggers the payment process, paying the claim amount to the patient's designated account and sending a claim settlement notification to the patient's terminal. This step corresponds to step 250, where the first server device sends claim result information containing the claim amount.

[0166] ⑩ The new generation claims platform supports full-process automation.

[0167] All the above steps are automatically scheduled and executed by the new generation claims platform, achieving fully automated processing from invoice delivery to claims payment. This step corresponds to this application. Figure 2 The complete process shown is a manifestation of the overall automated claims process consisting of steps 210 to 250.

[0168] Figure 8 This is a flowchart illustrating the overall claims and invoice processing process in an embodiment of this application.

[0169] The claims processing method provided in this application covers the entire process from the submission of a claims application to the closure of the case.

[0170] The process mainly includes the following stages, which are related to this application. Figure 3 , Figure 4 , Figure 5 The steps in the illustrated method embodiments have a corresponding relationship:

[0171] Phase 1: Claims Application and Image Entry

[0172] Users submit claims through the terminal. After receiving the claim, the system automatically links the electronic invoice image data and stores it in the image database, providing a data source for subsequent processing. This stage corresponds to... Figure 5 In step 510, the terminal device sends a first data set containing electronic ticket identification information.

[0173] Phase Two: Automated Processing of Invoices

[0174] The system invokes the invoice robot module to automatically identify and extract key information from the images of incoming invoices. Through integration with a third-party invoice service platform, it completes invoice authenticity verification, status query, and structured data extraction. This stage achieves full automation of invoice processing without manual intervention.

[0175] The ticket robot module has the following functions, which are consistent with those in this application. Figure 3 The method steps of the first server device shown have a corresponding relationship:

[0176] (1) Automatically identify key elements such as codes, numbers, amounts, and dates in the invoice image, i.e., automatic classification and identification of electronic invoices. This function corresponds to step 310, receiving the first data set.

[0177] (2) Automatically query the status of invoices on the fiscal platform or third-party service system, i.e., automatic verification of electronic invoice status. This function corresponds to steps 320-340, which involves identifying the target external system identifier and sending a query request.

[0178] (3) Verify the authenticity of the invoice and determine its status based on the query results. This function corresponds to steps 350-360, receiving response data and generating a second data set.

[0179] (4) Convert the verified invoice data into a structured format and transmit it to the claims calculation engine, i.e., automatically acquire electronic invoice data. This function corresponds to step 370, sending the second data set.

[0180] Phase Three: Claims Calculation and Decision-Making

[0181] Based on extracted structured data (such as total costs, medical insurance settlement costs, and out-of-pocket expenses) and associated policy information, the system automatically executes claims calculation logic, generates claims amounts, and completes claims approval decisions—that is, intelligent insurance claims calculation. This stage corresponds to steps 410-440, where the second server device receives the second data set, associates the policies, and calculates the claims amount.

[0182] Phase Four: Case Closure and Notification

[0183] Once the claim amount is determined, the system automatically completes the case closure process and sends a claim result notification to the user's terminal. If payment is involved, the system simultaneously triggers the insurance payment process. This stage corresponds to the latter half of step 440 and... Figure 5 In step 520, the second server device sends the claim result information, and the terminal device receives the processing result data.

[0184] Figure 9 This is an architecture diagram of a medical image recognition and medical data open platform according to an embodiment of this application.

[0185] The electronic invoice claims processing system provided in this application includes two core components: medical image recognition and a medical data open platform. Its architecture and functional composition can be found in [reference needed]. Figure 9 These functional modules are related to this application. Figure 2 , Figure 3 , Figure 4 , Figure 5 The steps of the method embodiments shown have a corresponding relationship.

[0186] Medical image recognition function

[0187] This function is implemented by an intelligent recognition engine deployed on the insurance company's side, and has the following capabilities:

[0188] Automatic classification of medical electronic invoice images: The system can automatically distinguish between invoice types such as outpatient invoices, inpatient settlement statements, and medical insurance settlement lists. This function corresponds to... Figure 5 In step 510, the terminal device sends a first data set containing electronic ticket identification information.

[0189] Intelligent recognition of key elements in electronic invoices: Based on OCR technology, key fields such as invoice code, number, amount, date, patient name, and issuing institution are extracted, with an accuracy rate of no less than 99%. This function corresponds to... Figure 3 In step 310, the first server device receives the first dataset and identifies the identification information therein.

[0190] Medical Data Open Platform

[0191] This platform acts as an intermediary layer between the insurance company's system and external systems, providing the following services:

[0192] Two-way interface capability: Supports standardized interface with various external systems such as hospital information systems, fiscal invoice platforms, and third-party invoice service providers. This function corresponds to... Figure 2 Step 220 and Figure 3 In steps 320-340, the first server device identifies the target external system and initiates a query against it.

[0193] Rapid multi-system integration: Through configurable interfaces and protocol adaptation, multiple medical institutions can quickly integrate their systems. The platform offers more secure data management and allows for flexible combinations to meet diverse collaboration needs.

[0194] Core service modules

[0195] Based on this platform, the system provides the following automated services:

[0196] Electronic invoice verification: Through system integration, the authenticity, status of invoices, and duplicate reimbursement checks are completed in real time, preventing risks such as invoices not belonging to the invoice holder, tampered invoices, and fake invoices, thus resolving the risks of invoice forgery and duplicate reimbursement. This function corresponds to... Figure 2 Step 220 and Figure 3 In step 350, the first server device obtains the ticket status information.

[0197] Structured data acquisition: Automatically extracts fields such as total cost, medical insurance settlement cost, and personal out-of-pocket amount from invoices to form standardized claims data, achieving automatic data acquisition and eliminating manual data entry. This function corresponds to... Figure 3 In step 360, the first server device generates the second data set.

[0198] Detailed Expense Retrieval: Supports retrieving original hospital expense details, such as settlement items for medications, treatment procedures, and materials, for refined cost accounting. This function corresponds to... Figure 4 In steps 430-440, the second server device calculates the claim amount based on the invoice details data.

[0199] Data security and protection mechanisms

[0200] The platform employs multiple security measures at the data transmission and access control levels:

[0201] The transmitted data is encrypted using the national cryptographic algorithm.

[0202] Ensure link security through HTTPS protocol;

[0203] Access control is implemented using point-to-point leased lines or firewall IP whitelisting. This further ensures more secure dedicated data management.

[0204] Figure 10 This is a structural diagram of an electronic invoice data processing device according to an embodiment of this application.

[0205] This application also provides an electronic invoice data processing apparatus for implementing the above method. The apparatus includes:

[0206] The receiving module 601 is used to receive claim initiation data containing identification information of electronic tickets, as described in step 210 of the embodiment.

[0207] It is also used to obtain the status information and detailed data of the electronic invoice, as described in step 220 of the embodiment; the status information indicates at least one or more of the following: the authenticity status of the invoice, the invoice cancellation status, and the interbank reimbursement status.

[0208] The determination module 602 is used to determine the target external system based on the identification information, as described in step 220 of the embodiment.

[0209] The sending module 603 is used to send a query request to the target external system, as described in step 220 of the embodiment.

[0210] It is also used to send claim result information containing the claim amount, as described in step 250 of the embodiment.

[0211] The processing module 604 is used to perform logical judgment on the status information of the bill according to the insurance claim rules and generate claim judgment status data, as described in step 230 of the embodiment.

[0212] It is also used to associate the corresponding insurance policy with the identification information when the claim judgment status data indicates that the invoice is eligible for claim, and to calculate the claim amount based on the claim rules of the insurance policy and the invoice details, as described in step 240 of the embodiment.

[0213] Furthermore, the receiving module includes a first receiving unit for receiving claim initiation data containing identification information of electronic invoices.

[0214] It also includes a second receiving unit for acquiring the electronic invoice's status information and detailed data; the invoice status information indicates at least one or more of the following: invoice authenticity status, invoice cancellation status, and interbank reimbursement status.

[0215] The determining module includes a first determining unit, used to determine the target external system based on the identification information.

[0216] The sending module includes a first sending unit for sending a query request to the target external system.

[0217] It also includes a second sending unit for sending claim result information containing the claim amount.

[0218] The processing module includes a first processing unit, which is used to perform logical judgment on the status information of the invoice according to the insurance claim rules and generate claim judgment status data.

[0219] It also includes a second processing unit, which is used to associate the corresponding insurance policy with the identification information and calculate the claim amount based on the claim rules of the insurance policy and the bill details when the claim judgment status data indicates that the bill is eligible for claim.

[0220] In one embodiment, the determining module further includes a third determining unit, used to determine the target external system identifier in any of the following ways: extracting the target external system identifier from the claim initiation data; querying a predetermined mapping relationship based on the identifier information of the electronic invoice to determine the target external system identifier; and using a predetermined fixed identifier as the target external system identifier, as described in step 320 of the embodiment.

[0221] In one embodiment, the sending module further includes a third sending unit, used to send a query request to the target external system containing a bill query instruction, specifically an instruction to request the bill service system of a finance or medical institution to verify the authenticity of the bill and query the bill reimbursement status, as described in step 340 of the embodiment.

[0222] In one embodiment, the receiving module further includes a third receiving unit for receiving the invoice status information, which includes at least the invoice authenticity status, invoice cancellation status, and interbank reimbursement status provided by the external system authority, as described in step 350 of the embodiment.

[0223] In one embodiment, the processing module further includes a third processing unit for generating the claims judgment status data, which is a binary decision identifier generated after logically judging the authenticity status of the invoice, the invoice cancellation status, and the interbank reimbursement status according to the insurance claims rules, as described in step 360 of the embodiment.

[0224] In one embodiment, the processing module further includes a fourth processing unit, which is used to generate an active claims service trigger instruction based on the claims judgment status data before sending the claims result information, as described in step 370 of the embodiment.

[0225] In one embodiment, the processing module further includes a fifth processing unit, used to calculate the risk score of the current invoice based on the claim judgment status data and user historical behavior data after generating claim judgment status data; if the risk score is lower than a first threshold, the step of calculating the claim amount is automatically triggered; if the risk score is between the first threshold and a second threshold, the case is transferred to the manual review queue; if the risk score is higher than the second threshold, a fraud investigation process is triggered and the claim rights of the associated policy are frozen, as described in step 370 of the embodiment.

[0226] In one embodiment, the processing module further includes a sixth processing unit, which is used when the step of calculating the claim amount is performed by the second server device, the second server device adopts a microservice architecture, receives data through an API gateway, and asynchronously notifies the payment service and message push service through a message middleware after the calculation is completed, as described in step 440 of the embodiment.

[0227] In one embodiment, the processing module further includes a seventh processing unit, used to verify the authenticity and status of electronic invoices based on the acquired invoice authenticity status, invoice cancellation status, and interbank reimbursement status.

[0228] In one embodiment, the processing module further includes an eighth processing unit, which is used to automatically match the policy liability and complete the intelligent calculation of insurance claims based on the policy's claims rules and the invoice details data.

[0229] In one embodiment, the processing module further includes a ninth processing unit, which generates an active service trigger instruction based on the claims judgment status data to trigger active service processes such as reporting incidents and customer condolences.

[0230] Figure 11 This is a system diagram illustrating an application scenario of an embodiment of this application.

[0231] This application also provides an electronic invoice claims processing system, such as... Figure 11 As shown, it includes:

[0232] Terminal device 1100, which is a mobile communication device, personal computer or smart terminal operated by a user or insurance service personnel, includes a user interface and a client application module for collecting electronic invoice images, submitting claim requests, and receiving and displaying claim processing status and results, as described in steps 510-520; the terminal device is communicatively connected to the first server for sending claim initiation data containing electronic invoice identification information and receiving claim result information containing claim amount.

[0233] The first server 900 serves as the access and data processing intermediary layer for the claims system and is specifically configured with an access gateway. To fully consider the system integration of different partners and different electronic invoice service models, and to enable arbitrary combinations based on cooperation needs, while also avoiding the impact on the company's core business system after data is directly accessed, an access gateway is innovatively used as an intermediary library for system integration at the front end of the system. This access gateway acts as a logical isolation layer, achieving security domain isolation between external data and the core system, and ensuring transmission security through national cryptographic algorithms and HTTPS protocol. The access gateway includes multiple pre-configured data interaction interfaces and a rule engine for adapting communication with different external invoice service systems. It is specifically responsible for receiving electronic invoice identifiers, routing to target systems, sending verification and status query requests to external systems, receiving response data, and standardizing processing, as described in steps 210-250 and 310-360. The first server is deployed with the apparatus described in the second aspect embodiment, or configured to execute the method described in any embodiment of the first aspect.

[0234] In one embodiment, the first server 900 is further configured to perform entity alignment and association between electronic invoice data obtained from the access gateway and policy data based on preset matching rules. Specifically, it matches the patient identification information (such as name and ID number) and consultation time information contained in the electronic invoice with the insured information in the policy database. When a match is successful, an accident report record is automatically generated.

[0235] The second server 1000 serves as the core processing layer for claims operations, running the core insurance claims system. This core system includes a policy database, a claims rule base, and a claims calculation engine. It receives standardized data from the first server, performs automatic policy matching, claims eligibility assessment, intelligent calculation of insurance claims, and generates claims conclusions, as described in steps 410-440. The second server is communicatively connected to the first server. When the claims assessment status data generated by the first server indicates that the invoice is eligible for claims, the second server determines the associated policy based on the identification information and determines the claims amount based on the policy's claims rules and the invoice details.

[0236] The terminal device is communicatively connected to the first server for data submission and result reception; the first server is communicatively connected to the second server to form a collaborative working link for data processing and business decision-making; the first server also communicates and interacts with an external invoice service system through its access gateway.

[0237] Figure 12 This is a structural diagram of the first server device in an embodiment of this application.

[0238] This application also proposes a first server device for implementing the method of any embodiment of this application, particularly for performing the electronic ticket processing method described in the first aspect embodiment, as described in steps 210-250 and 310-360.

[0239] To implement the above technical solution, this application proposes a first server device 900, which includes a first server receiving module 901, a first server determining module 902, a first server sending module 903, a ticket image database 904, a logical rule base 905, and a structured data cache database 906, all interconnected.

[0240] The first server receiving module 901 is used to receive a claim request from a terminal device, the claim request including the identification information of the electronic invoice, as described in step 210; and response data including invoice status information and invoice details transmitted from a third-party service platform, as described in step 220.

[0241] The first server determination module 902 is used to determine the target external system based on the identification information, as described in step 220; determine the type of ticket corresponding to the ticket image; determine the key information extraction rules; and determine the verification strategy and data forwarding rules, as described in step 320.

[0242] The first server sending module 903 is used to send a query request to the target external system, as described in step 220; send a verification request and invoice image to the third-party service platform; send a second data set to the second server device; and return claim result information containing the claim amount to the terminal device, as described in step 250.

[0243] The first database 904 is a ticket image database that stores original ticket image data from terminal devices or third-party systems and supports indexing and querying by ticket identifier, upload time, and user identifier.

[0244] The second database, 905, is a logical rule base that stores invoice classification rules, key information extraction templates, verification process rules, and protocol adaptation rules for interfacing with different third-party service platforms.

[0245] The third database 906 is a structured data cache library that temporarily stores identified and verified structured invoice data, including invoice code, number, amount, fee details, etc., for subsequent transmission, as described in step 360.

[0246] In another embodiment, the first server device further includes a risk control decision engine module and an active service scheduling module. The risk control decision engine module is connected to the logical rule base and the external user behavior database, and is used to perform the risk scoring calculation and case routing described in the above embodiment, as described in step 370. The active service scheduling module includes an event monitoring submodule, a task generation submodule, and a task distribution submodule, and is used to implement the functions of the aforementioned electronic invoice data processing device.

[0247] The specific methods for implementing the functions of the first server receiving module, the first server determining module, and the first server sending module are as described in the various method embodiments of this application, and will not be repeated here.

[0248] Figure 13 This is a structural diagram of the second server device according to an embodiment of this application.

[0249] This application also proposes a second server device for implementing the method of any embodiment of this application, particularly for executing the method provided by… Figure 4 The electronic invoice claims decision-making method implemented by the second server device as described in the illustrated embodiment is as follows: steps 410 to 440.

[0250] To implement the above technical solution, this application proposes a second server device 1000, which includes a second server receiving module 1001, a second server determining module 1002, a second server sending module 1003, a fourth database 1004, a fifth database 1005, and a sixth database 1006 that are interconnected.

[0251] The second server receiving module 1001 is used to receive a second data set transmitted from the first server device or a third-party platform. The second data set includes the identification information of the electronic invoice, the claim judgment status data, and the invoice details data, as described in step 410.

[0252] The second server determination module 1002 is used to determine whether the invoice is eligible for claim based on the claim judgment status data, and to determine the associated policy information based on the identification information, as described in step 420; it is also used to determine the claim calculation logic based on the policy rules and invoice details data, as described in step 430, and to run the claim calculation instruction to obtain the claim amount, as described in step 440.

[0253] The second server sending module 1003 is used to send a claim payment instruction to the payment system, send a claim result notification containing the claim amount to the terminal device, and return a status confirmation to the first server device or a third-party platform, as described in step 440.

[0254] The fourth database, 1004, is a policy information database that stores user policy data, including policy number, insured information, insurance liability, deductible, payout ratio, validity period, and historical claims records.

[0255] The fifth database, 1005, is a claims rules database that stores claims calculation rules, liability exclusion clauses, white lists of medical institutions, and comparison tables of drug and treatment item catalogs for different insurance products.

[0256] Database 1006, the sixth database, is a cache library for the claims process. It temporarily stores claims requests currently being processed, associated invoice data, intermediate calculation results, and the final claims amount, and is used to track process status and audit traceability.

[0257] The specific methods for implementing the functions of the second server receiving module, the second server determining module, and the second server sending module are as described in the various method embodiments of this application, and will not be repeated here.

[0258] Figure 14 This is a structural diagram of a terminal device according to an embodiment of this application.

[0259] This application also proposes a terminal device for implementing the method of any embodiment of this application, particularly for performing the electronic bill claim information processing method described in the third aspect embodiment, as described in steps 510 to 520.

[0260] To implement the above technical solution, this application proposes a terminal device 1100, which includes a terminal receiving module 1101, a terminal determining module 1102, and a terminal sending module 1103 connected to each other.

[0261] The terminal receiving module 1101 is used to receive a first data set from a first server or a third-party platform, the first data set containing identification information of electronic invoices, as described in step 510; and is also used to receive processing result data from a second server, the processing result data containing at least the claim amount, as described in step 520.

[0262] The terminal determination module 1102 is used to determine whether to automatically initiate a claim request after receiving the first data set; it is also used to determine whether to view the invoice details or claim progress based on the user's operation, as described in step 530.

[0263] The terminal sending module 1103 is used to send a claim request to the first server. The claim request includes at least the identification information of the electronic invoice and the user's identity information, as described in step 510. It is also used to upload supplementary information or confirmation information to the server after user authorization.

[0264] The specific methods for implementing the functions of the terminal receiving module, the terminal determining module, and the terminal sending module are as described in the various method embodiments of this application, and will not be repeated here.

[0265] Based on the foregoing Figure 12 , Figure 13 and Figure 14 The first server device, the second server device, and the terminal device shown are combined with... Figure 11 The system architecture shown in this application also provides a specific configuration of an electronic invoice claims processing system. This system is used to implement the aforementioned electronic invoice data processing method and includes:

[0266] A first server device, the first server device comprising:

[0267] The first receiving module is used to receive claim initiation data containing electronic invoice identification information, as described in step 210; it is also used to receive response data from the target external system containing invoice status information and invoice detail data, as described in step 220.

[0268] The first determining module is used to determine the target external system based on the identification information, as described in step 220; it is also used to perform logical judgment on the bill status information according to the insurance claim rules and generate claim judgment status data, as described in step 230.

[0269] The first sending module is used to send a query request to the target external system, as described in step 220; it is also used to send a second data set containing the claim judgment status data and the invoice details data, as described in steps 250 and 370.

[0270] The first receiving module, the first determining module, and the first sending module included in the first server device correspond to the receiving module, the determining module, and the sending module in the aforementioned electronic ticket data processing device, and have the same functions; the function of its processing module is jointly implemented by the first determining module in this system and the second determining module of the second server device.

[0271] A second server device, the second server device comprising:

[0272] The second receiving module is used to receive the second data set from the first server device, as described in step 410.

[0273] The second determining module is used to determine the associated policy based on the identification information when the claim judgment status data indicates that the invoice is eligible for claim, as described in step 420, and to determine the claim amount based on the claim rules of the policy and the invoice details data, as described in steps 430-440.

[0274] The second sending module is used to send claim result information containing the claim amount, as described in step 440.

[0275] Through the synergy of the aforementioned modular devices, this system forms the hardware foundation for achieving fully automated claims processing. Figure 11 and Figure 6 The architecture of the system is shown at different levels.

[0276] Figure 15 A schematic diagram of the structure of a first server device according to another embodiment of this application is shown.

[0277] As shown in the figure, the first server device 1200 includes a processor 1201, a communication interface 1202, and a memory 1203. The communication interface includes a transmitting unit and a receiving unit, providing a unit for communicating with a terminal device, a second server device, and a third-party service platform over a transmission medium. The communication interface implements communication functions with the terminal device, processes the second data set through receiving and transmitting devices, and its data is connected to the memory or processor via an internal bus structure.

[0278] The memory 1203 contains a computer program that executes the first server-side method of any embodiment of this application, and the computer program runs or is modified on the processor 1201. When the memory, processor, and communication interface circuit are connected via a bus system, the bus system includes a data bus, a power bus, a control bus, and a status signal bus, which will not be described in detail here.

[0279] The memory 1203 can store the operating system and application programs. The operating system includes various system programs, such as the framework layer, core library layer, and driver layer, used to implement various basic business functions and handle hardware-based tasks. The application programs include a ticket recognition module, a verification and scheduling module, and a data conversion module, used to implement application functions such as ticket image processing, data forwarding, and status notification.

[0280] The processor 1201 reads information from the memory 1203 and, in conjunction with its hardware, completes the steps of the above method. Specifically, the computer-readable storage medium stores a computer program, which, when executed by the processor 1201, implements the first server-side method as described in any of the above embodiments.

[0281] Figure 16 A schematic diagram of the structure of a second server device according to another embodiment of this application is shown.

[0282] As shown in the figure, the second server device 1300 includes at least one processor 1301, a memory 1302, and a communication interface 1303. The various components in the second server device 1300 are coupled together via a bus system. The bus system is used to enable communication between these components. The bus system includes a data bus, a power bus, a control bus, and a status signal bus.

[0283] The communication interface 1303 includes a transmitter and a receiver for exchanging data with the first server device, terminal device and payment system.

[0284] The memory 1302 stores executable modules or data structures. The memory may store an operating system and application programs. The operating system contains various system programs used to implement various basic business processes and handle hardware-based tasks. The application programs include a claims calculation engine, a policy matching module, a decision recording module, etc., used to implement claims decision-making and payment triggering processes.

[0285] In this embodiment of the application, the memory 1302 contains a computer program that executes a second server-side method of any embodiment of the application, the computer program being run on or modified by the processor 1301.

[0286] The processor 1301 reads information from the memory 1302 and, in conjunction with its hardware, completes the steps of the above method. Specifically, the computer-readable storage medium stores a computer program, which, when executed by the processor 1301, implements the second server-side method as described in any of the above embodiments.

[0287] Figure 17 A schematic diagram of the structure of a terminal device according to another embodiment of this application is shown.

[0288] As shown in the figure, terminal device 1400 includes at least one processor 1401, memory 1402, user interface 1403, and at least one network interface 1404. The various components in terminal device 1400 are coupled together via a bus system. The bus system is used to enable communication between these components. The bus system includes a data bus, a power bus, a control bus, and a status signal bus.

[0289] User interface 1403 includes one or more of a display, touch screen, keyboard or voice input device, for receiving user operations and displaying claims progress, invoice information and notification content.

[0290] Network interface 1404 is used to communicate with the first server device, the second server device, and the third-party service platform to receive invoice data, claim status, and processing results.

[0291] The memory 1402 stores executable modules or data structures. The memory may store an operating system and application programs. The operating system includes various system programs, such as a framework layer, core library layer, and driver layer, used to implement various basic business functions and handle hardware-based tasks. The application programs include electronic ticket module, claims application module, and message push processing module, used to implement application functions such as ticket reception, claims initiation, and results viewing.

[0292] In this embodiment of the application, the memory 1402 contains a computer program that executes the terminal-side method of any embodiment of the application, and the computer program runs on or modifies the processor 1401.

[0293] The processor 1401 reads information from the memory 1402 and, in conjunction with its hardware, completes the steps of the above method. Specifically, the computer-readable storage medium stores a computer program, which, when executed by the processor 1401, implements the terminal-side method as described in any of the above embodiments.

[0294] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. In a typical configuration, the device involved in this application includes one or more processors, a communication interface, a user interface, and memory.

[0295] Furthermore, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, semiconductor storage, etc.) containing computer-usable program code.

[0296] Therefore, this application also proposes a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the method described in any embodiment of this application. For example, the memories 1203, 1302, and 1402 of this invention may all include non-permanent memory in a computer-readable storage medium, such as random access memory (RAM), and / or non-volatile storage medium, such as read-only memory (ROM) or flash memory.

[0297] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0298] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the term “comprising” as used in this application means the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. It should be understood that when an element is “connected” or “coupled” to another element, it may be directly connected or coupled to the other element, or there may be intermediate elements. Furthermore, “connected” or “coupled” as used herein may include wireless connections or wireless coupling. The term “and / or” as used herein includes all or any units and all combinations of one or more associated listed items.

[0299] Those skilled in the art will understand that, unless otherwise defined, all terms used herein (including technical, terminological, and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains.

[0300] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. An electronic ticket data processing method, characterized by, Includes the following steps: Receive claim initiation data containing identification information of electronic invoices; Based on the identification information, the target external system is identified and a query is initiated to obtain the electronic invoice's status information and detailed data; the invoice status information indicates at least one or more of the following: invoice authenticity status, invoice cancellation status, and interbank reimbursement status. According to the insurance claims rules, the status information of the invoice is logically judged to generate claims judgment status data; When the claims status data indicates that the invoice is eligible for claim, the corresponding policy is associated with the identification information, and the claim amount is calculated based on the policy's claims rules and the invoice details. Send claim result information containing the claimed amount.

2. The electronic ticket data processing method of claim 1, wherein, Determining the target external system identifier can be done in any of the following ways: Extract the target external system identifier from the claim initiation data; Based on the identification information of the electronic ticket, a predetermined mapping relationship is queried to determine the identifier of the target external system; The predetermined fixed identifier is used as the identifier of the target external system.

3. The electronic ticket data processing method of claim 1, wherein, The request to initiate an inquiry includes a document inquiry instruction, specifically an instruction used to request the document service system of the finance or medical institution to verify the authenticity of the document and inquire about the reimbursement status of the document.

4. The electronic ticket data processing method of claim 1, wherein, The invoice status information includes at least the invoice authenticity status, invoice cancellation status, and interbank reimbursement status provided by the external system authority.

5. The electronic ticket data processing method of claim 1, wherein, The claims assessment status data is a binary decision identifier generated after logically judging the authenticity status, invoice cancellation status, and interbank reimbursement status of the invoices according to insurance claims rules.

6. The electronic ticket data processing method of claim 1, wherein, Before transmitting the claims result information, the method further includes: generating an active claims service trigger instruction based on the claims judgment status data.

7. The electronic ticket data processing method of claim 1, wherein, After generating the claims assessment status data, the following is also included: Based on the claims assessment status data and user historical behavior data, the risk score of the current invoice is calculated through a risk decision model. If the risk score is lower than the first threshold, the step of calculating the claim amount is automatically triggered; If the risk score is between the first threshold and the second threshold, the case will be transferred to the manual review queue. If the risk score is higher than the second threshold, a fraud investigation process will be triggered and the claims processing rights of the associated policies will be frozen.

8. The electronic ticket data processing method of claim 1, wherein, The step of calculating the claim amount is performed by the second server device; the second server device adopts a microservice architecture, receives data through an API gateway, and asynchronously notifies the payment service and message push service through a message middleware after the calculation is completed.

9. An electronic ticket data processing apparatus for implementing the electronic ticket data processing method according to any one of claims 1 to 8, characterized by include: The receiving module is used to receive claim initiation data containing identification information of electronic invoices; It is also used to obtain the status information and detailed data of the electronic invoice; the status information indicates at least one or more of the following: authenticity status, invoice cancellation status, and interbank reimbursement status. The determination module is used to determine the target external system based on the identification information; The sending module is used to send a query request to the target external system; it is also used to send claim result information containing the claim amount; The processing module is used to perform logical judgment on the status information of the invoice according to the insurance claim rules and generate claim judgment status data; it is also used to associate the corresponding insurance policy with the identification information when the claim judgment status data indicates that the invoice is eligible for claim, and calculate the claim amount based on the claim rules of the insurance policy and the invoice details data.

10. An electronic ticket claim handling system, characterized by include: A first server device is deployed with the device as described in claim 9, or configured to perform the method as described in any one of claims 1 to 8; The second server device is communicatively connected to the first server device and is used to determine the associated policy based on the identification information when the claim judgment status data generated by the first server device indicates that the invoice is eligible for claim, and to determine the claim amount based on the claim rules of the policy and the invoice details data. The terminal device is communicatively connected to the first server device and / or the second server device, and is used to send claim initiation data containing electronic invoice identification information and receive claim result information containing the claim amount.

Images