A medical claim settlement data processing method, device and system

Abstract

This application discloses a method, apparatus, and system for processing medical claims data, relating to the field of computer technology. It solves the technical problems of existing technologies being unable to automatically respond to the arrival events of multi-source heterogeneous claims data and automatically execute processing flows upon data access, leading to fragmented system processing flows and idle computing resources. The method includes: performing OCR recognition on a set of image files to generate annotated result data; matching medical expense invoice data with standard expense items according to preset matching rules to generate standardized detailed data; and, in response to a claims calculation trigger command, executing predetermined claims calculation logic based on the annotated result data and standardized detailed data to generate claims conclusion data. This application achieves automatic response to data arrival events and full-process calculation through a phased data processing pipeline, solving the problems of fragmented processes and idle resources.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus and system for processing medical claims data. Background Technology

[0002] In the commercial health insurance sector, complex medical insurance products such as comprehensive medical insurance are becoming increasingly popular due to their high coverage and broad applicability. These products typically feature multiple liabilities, complex payout conditions, detailed cost control rules, and differentiated reimbursement ratios. These characteristics directly lead to exceptionally complex claims processing logic, placing extremely high demands on the completeness of claims application materials, the logical order of applications, and the professional competence of claims personnel. In practice, such cases generally suffer from long claims processing times, heavy workloads for staff, high error rates in claims settlement, and numerous customer complaints.

[0003] Currently, the industry's general claims process can be horizontally divided into three main stages: initial claims review, claims processing, and claims approval. In the initial claims review stage, staff are required to review basic case information, verify the necessity and completeness of medical imaging data, and collect and input medical expense invoices. In the claims processing stage, the core task is to confirm insurance liability and calculate the specific compensation amount. The claims approval stage involves reviewing and finally confirming the aforementioned claims results.

[0004] For the aforementioned complex medical insurance products, the existing claims processing workflow, particularly the manual operation portion, faces three major bottlenecks:

[0005] First, the workload for image review and invoice collection is heavy and inefficient. Statistics show that for complex medical insurance claims, the average workload for image review is approximately 1.42 times that of ordinary cases, the amount of invoice collection is approximately 1.33 times, and the average time spent on manual processing is 1.77 times that of ordinary cases. Furthermore, approximately 2% of complex cases require manual intervention, significantly extending the overall claims processing time. The manual workload required for the initial review stage of complex medical insurance claims is significantly higher than that of ordinary medical insurance cases. Regarding image review, complex cases require reviewing up to 19 images of identification documents, medical expense receipts, and medical records, while ordinary cases average about 13 images, making the former's workload approximately 1.42 times that of the latter. In terms of medical expense invoice collection, complex cases require collecting approximately 2.8 invoices, while ordinary cases require collecting about 2.1, making the former's collection volume approximately 1.33 times that of the latter. In addition, the proportion of complex cases requiring detailed entry of each expense item is also higher than that of ordinary cases. The data above shows that such cases consume a lot of manpower and time in the basic stages of document review and information entry.

[0006] Secondly, the claims settlement rules are complex, making manual processing difficult and prone to errors. The average processing time for complex medical insurance claims is significantly longer than for ordinary claims. Data shows that the average processing time for manual cases is 1.77 times that of ordinary cases. Even after excluding a small number of extremely time-consuming and complex cases, the average processing time decreases but remains significantly higher than the benchmark, with the median time still being 1.5 times that of ordinary cases. This reflects a considerable proportion of ineffective or repetitive operations in the processing stage. The root cause of this inefficiency lies in the extreme complexity of the claims settlement rules for this type of insurance, coupled with insufficient support from the current claims system for key operational points. For example, the system lacks flexible and automated support in areas such as deductible calculation (especially involving the accumulation of historical claims), coordinated claims across multiple valid policies, priority calculation order among different insurance liabilities, and the order of deduction for medical expenses based on whether social medical insurance has made advance payments. For a few complex cases, claims personnel have to perform extensive manual adjustments and calculations, which is not only time-consuming but also prone to inconsistencies or errors.

[0007] Third, the existing system lacks sufficient intelligence and relies excessively on human experience and operation. From an overall process perspective, the current solution heavily depends on manual intervention in areas such as image review, information entry, and logical judgment. During image review, staff must compare image content with case information image by image; during invoice collection, a large number of expense details must be manually entered or matched; and during liability calculation, complex priority orders and deduction rules must be manually memorized and applied. This reliance on manual operation has become a major obstacle to improving the overall efficiency, accuracy, and consistency of claims processing.

[0008] Therefore, there is an urgent need for a claims processing method that can handle complex medical insurance products in order to solve the aforementioned technical problems of inefficiency, complexity and error-proneness. Summary of the Invention

[0009] This application proposes a medical claims data processing method, apparatus, and system, which solves the problem that the existing technology cannot automatically respond to the arrival of multi-source heterogeneous claims data and automatically execute the processing flow when the data is accessed, resulting in fragmented system processing flow and idle computing resources.

[0010] In a first aspect, embodiments of this application provide a method for processing medical claims data, comprising the following steps:

[0011] Obtain the first claims dataset; the first claims dataset contains claims case identifiers and a set of image files;

[0012] The image file set is subjected to optical character recognition processing to generate annotation result data corresponding to the claim case identifier;

[0013] Obtain the second claims dataset; the second claims dataset contains medical expense invoice data;

[0014] The medical expense invoice data is subjected to standardized matching processing to generate standardized detailed data; the standardized matching processing includes: matching the expense details in the invoice with standard expense items according to preset matching rules;

[0015] In response to receiving a claim settlement trigger instruction for the claim case identifier, the system executes the predetermined claim settlement logic corresponding to the target medical insurance type based on the annotation result data and the standardized detailed data, and generates claim settlement conclusion data.

[0016] In one embodiment, executing the predetermined computational logic specifically includes the following steps:

[0017] Based on the preset liability priority rules, and the expense types and treatment information in the medical expense invoice data and the annotation result data, the order of execution of multiple claims is determined;

[0018] According to the aforementioned claim calculation execution order, the corresponding claim calculations are performed on the expense items in the standardized detailed data in sequence.

[0019] In one embodiment, the pre-calculation logic includes rules for processing deductibles, the rules including:

[0020] Based on the claim case identifier, retrieve all claim settlement records with the same policy identifier from the historical claims database;

[0021] Sum the deductible field in all retrieved claims settlement records to obtain the cumulative historical deductible value;

[0022] The cumulative historical deductible is used as an input parameter for calculating the current claim amount.

[0023] In one embodiment, the calculation trigger instruction includes selection information for treatment method options generated based on the annotation result data or the standardized detail data.

[0024] In one embodiment, generating the annotation result data specifically includes the following steps:

[0025] Create an annotation record; the annotation record includes the image file identifier, key field types, and field content;

[0026] The annotation records are associated with and stored in relation to the corresponding image files.

[0027] In one embodiment, matching the expense details with the standard expense items specifically includes the following steps:

[0028] Calculate the text similarity between the text description of the expense details item and the name of the standard expense item;

[0029] The standard cost item with the highest similarity is selected as the matching result to generate the standardized detailed data.

[0030] In one embodiment, the annotation result data is used to display the image file in association with the user interface, and supports filtering or sorting the image file based on fields in the annotation result data.

[0031] In one embodiment, before performing the step of generating claims conclusion data, the method further includes:

[0032] Based on the annotation results data and the standardized detailed data, determine whether the claim case is an abnormal case;

[0033] If the case is determined to be abnormal, a manual intervention flag is generated, and the execution of the predetermined processing logic is terminated.

[0034] Secondly, embodiments of this application also provide a medical claims data processing apparatus for the medical claims data processing method described in any embodiment of the first aspect, comprising: an acquisition module for acquiring a first claims dataset; the first claims dataset includes a claims case identifier and an image file set; and is further configured to acquire a second claims dataset; the second claims dataset includes medical expense invoice data. A determination module is configured to perform optical character recognition processing on the image file set to generate annotation result data corresponding to the claims case identifier; and is further configured to perform item standardization matching processing on the medical expense invoice data to generate standardized detail data; the item standardization matching processing includes: matching the expense detail items in the invoice with standard expense items according to preset matching rules. An execution module is configured to respond to receiving a claims calculation trigger instruction for the claims case identifier, and, based on the annotation result data and the standardized detail data, execute a predetermined claims calculation logic corresponding to the target medical insurance type to generate claims conclusion data.

[0035] Thirdly, embodiments of this application also provide a medical claims data processing system, comprising: a first computer device, which is equipped with the apparatus described in the second aspect embodiment, or configured to execute the method described in any one of the first aspect embodiments; and a second computer device, communicatively connected to the first computer device, for providing a set of image files, medical expense invoice data, and claims triggering instructions, and for receiving and presenting annotation result data, standardized detail data, and claims conclusion data.

[0036] Fourthly, embodiments of this application also provide a computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the method described in any one of the embodiments of the first aspect.

[0037] Fifthly, embodiments of this application also provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method as described in any embodiment of the first aspect.

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

[0039] This application achieves automatic response of the claims processing system to the arrival of multi-source heterogeneous data by constructing a phased asynchronous data processing pipeline. First, optical character recognition (OCR) technology is used to automatically convert unstructured images into structured annotated data, allowing subsequent processing units to directly read it. Second, pre-defined matching rules automatically map non-standard invoice details to standard expense items, eliminating data format heterogeneity barriers. Finally, with the help of a pre-configured claims calculation rule engine, complex calculations such as multi-liability sorting and deductible accumulation are automatically completed and conclusions are output upon receiving a claims calculation trigger command. The above technical solution enables automatic connection between various processing stages through standardized data interfaces, solving the problems of repetitive data conversion and idle computing resources caused by fragmented processes, and significantly improving the system's event response speed and processing throughput.

[0040] Building upon this foundation, this application significantly reduces the reliance on manual labor in traditional operational models and drastically shortens overall operational timelines: automatic annotation in the image review process reduces manual comparison workload; intelligent matching in the document collection process eliminates tedious manual entry; and a rules engine enables precise output within seconds in the liability calculation process. Simultaneously, fully automated data processing ensures the consistency and accuracy of compensation results, effectively reducing error rates and workload caused by human intervention, ultimately improving the claims service experience and operational efficiency. Attached Figure Description

[0041] 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:

[0042] Figure 1 This is a schematic diagram of the claims process in the existing technology;

[0043] Figure 2 A flowchart of a medical claims data processing method provided in this application embodiment;

[0044] Figure 3A server-side flowchart of a medical claims data processing method provided in this application embodiment;

[0045] Figure 4 A terminal-side flowchart of a medical claims data processing method provided in this application embodiment;

[0046] Figure 5.1 An image list interface with annotation fields provided for embodiments of this application;

[0047] Figure 5.2 An interface for sorting by comment field provided in this application embodiment;

[0048] Figure 5.3 An interface for filtering by comment field provided in this application embodiment;

[0049] Figure 6 A schematic diagram illustrating the core technical points of the intelligent claims processing solution provided in the embodiments of this application;

[0050] Figure 7 A structural diagram of a medical claims data processing device provided in this application embodiment;

[0051] Figure 8 This is a schematic diagram of an application scenario system according to an embodiment of this application;

[0052] Figure 9 This is a schematic diagram of the logical architecture of the intelligent claims processing system provided in the embodiments of this application;

[0053] Figure 10 A structural diagram of a server-side device embodiment provided in this application;

[0054] Figure 11 This is a structural diagram of a terminal device embodiment provided in this application. Detailed Implementation

[0055] 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.

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

[0057] Figure 1 This is a schematic diagram of the claims processing workflow in existing technology. For example... Figure 1As shown, the existing process is typically divided horizontally into three main stages: initial claims review, claims processing, and claims approval. In the initial claims review stage, staff need to review case image data and collect and input medical expense receipts. In the claims processing stage, they need to select insurance coverage and calculate the compensation amount. In the claims approval stage, the aforementioned results are reviewed and confirmed. This process heavily relies on manual operation and suffers from inefficiency and error-proneness when handling complex medical insurance policies.

[0058] Vertically, the existing technical architecture reveals its technical shortcomings when dealing with complex medical insurance products that involve multiple liability logics, multi-dimensional judgment conditions, nested cost control rules, and differentiated reimbursement ratio matrices. These shortcomings manifest as the following interrelated systemic bottlenecks:

[0059] First, there is a bottleneck in the efficiency of the data processing front-end. The image review process lacks batch processing and automatic extraction capabilities for key information. Operators must perform serial visual inspections and information comparisons on each image, significantly extending the processing time of the image review unit. The invoice collection process relies on a manual input interface and lacks an automated mapping mechanism from unstructured invoices to structured claim items. This not only results in low data input throughput but also becomes a major source of data consistency errors. Statistics show that the data preparation delay for such complex cases in the initial review stage can be more than 1.4 times that of ordinary cases, constituting the primary source of delay in the entire claims pipeline.

[0060] Second, the core computing engine lacks intelligence. The core of the claims processing lies in executing logical judgments and calculations involving multiple rules and conditions. Existing systems store complex calculation rules (such as deductible accumulation, priority ranking of multiple liabilities, and third-party expense deductions) in unstructured natural language or simple scripts, failing to transform them into pre-configured rule logic that can be automatically parsed and executed within the system. This results in a lack of a built-in rule engine, making the calculation process highly dependent on manual intervention. Staff are forced to perform extensive manual searches, memorize rule sequences, and perform repetitive calculations, leading not only to an order-of-magnitude increase in processing time per case (averaging 1.77 times that of ordinary cases), but also to inconsistencies in calculation logic and errors in payout conclusions due to human error or misunderstanding.

[0061] Third, human-computer interaction and system support are insufficient. Existing processes lack intelligent assistance at key decision points. For example, during image review, the system does not provide content-understanding-based annotation and filtering tools; during responsibility matching, it does not integrate a medical knowledge graph to assist in refined selection of treatment methods; and during calculation execution, the interface cannot dynamically prompt the calculation order and intermediate results. This current state of coarse-grained system support and low level of interactive intelligence forces operators to bear excessive cognitive load and operational steps, which is the root cause of so-called ineffective work (i.e., redundant data verification and repetitive operations) and low user (operator) satisfaction.

[0062] The aforementioned technical bottlenecks combined result in existing claims systems exhibiting technical deficiencies when dealing with complex insurance products, including high latency in the processing pipeline, low system throughput, poor consistency of output results, and heavy reliance on specific personnel skills. These deficiencies severely restrict business scalability and service experience.

[0063] This application proposes an intelligent claims processing system, aiming to use technical means to... Figure 1 Each step shown is restructured for automation and intelligence. This application's intelligent claims settlement solution for million-dollar medical insurance series aims to address the most time-consuming manual processing in the workflow. Through OCR technology, a professional database, and adjustments to the claims calculation engine, it creates three core capabilities: intelligent image annotation, intelligent detail matching, and intelligent liability calculation. The entire process reduces the reliance on manual labor in traditional workflows and improves claims efficiency. The core of this application's technical solution lies in constructing a three-in-one intelligent processing pipeline to replace the traditional manual serial workflow. This pipeline consists of three collaborative technical subsystems: an intelligent image annotation subsystem based on Optical Character Recognition (OCR) and Natural Language Processing, used for automated extraction and structured annotation of image information; an intelligent invoice matching subsystem based on text similarity calculation and standard database mapping, used for automated and standardized entry of expense details; and a liability intelligent calculation subsystem based on a configurable rule engine and in-memory computing technology, used for internalizing and automating complex claims calculation logic. These subsystems collaborate with a unified data bus and workflow controller to achieve full-process automation from data entry to conclusion output.

[0064] Figure 2 This is a flowchart of a medical claims data processing method according to an embodiment of the present application, including steps 210-250.

[0065] Step 210: Obtain the first claims dataset; the first claims dataset contains claims case identifiers and a set of image files.

[0066] For example, the terminal device sends a first claims dataset to the server; the first claims dataset contains claims case identifiers and a set of image files.

[0067] Once the claims process is initiated, it is first launched by a terminal device (such as a computer operated by claims personnel or a mobile app used by the customer). The terminal device uploads a first claims dataset containing a claims case identifier and a set of image files to the server. The set of image files typically includes, but is not limited to, images of the insured's identification documents, medical records, diagnostic certificates, and other image materials.

[0068] It should be noted that the acquisition described in this step can be manifested as receiving data sent by the terminal device in a specific deployment architecture, but the method itself does not limit the type of device from which the data comes, nor does it depend on the specific interaction mode between the terminal device and the server, and the same applies below.

[0069] Step 220: Perform optical character recognition processing on the image file set to generate annotation result data corresponding to the claim case identifier.

[0070] For example, the server performs optical character recognition processing on the image file set, generates annotation result data, and sends a first response dataset containing the annotation result data to the terminal device.

[0071] After receiving the first claims dataset, the server initiates the intelligent image annotation process. Specifically, the server invokes its built-in or associated Optical Character Recognition (OCR) engine to perform batch recognition processing on the received image file set, automatically extracting key text information (such as name, date, diagnosis conclusion, amount, etc.) from the images. Subsequently, the server structures this key information, generates annotation result data, and returns the first response dataset containing this annotation result data to the terminal device.

[0072] In one embodiment, the server's processing procedure is as follows: Figure 3 As shown in the corresponding description, annotation records containing image file identifiers, key field types and content are generated and stored in association using OCR technology.

[0073] Step 230: Obtain the second claims dataset; the second claims dataset contains medical expense invoice data.

[0074] For example, the terminal device sends a second claims dataset to the server; the second claims dataset contains claims case identifiers and medical expense invoice data.

[0075] After receiving the annotation results (which operators typically quickly review and confirm), the terminal device initiates the invoice processing flow. The terminal device sends a second claims dataset containing the same claims case identifier and medical expense invoice data to the server. This medical expense invoice data can be a structured electronic invoice file or a standardized data package generated through terminal scanning or input.

[0076] Step 240: Perform standardized matching processing on the medical expense invoice data to generate standardized detailed data; the standardized matching processing includes: matching the expense details in the invoice with standard expense items according to preset matching rules.

[0077] For example, the server performs item standardization matching on the medical expense invoice data to generate standardized detailed data, and sends a second response dataset containing the standardized detailed data to the terminal device.

[0078] After receiving the second claims dataset, the server initiates an intelligent detail matching process. The server accesses the claims item database and compares and matches each expense detail (such as medication costs, examination fees, and treatment fees) in the invoice data with standard expense entries in the database. In one embodiment, this matching process is achieved by calculating text similarity, and the standard expense entry with the highest similarity is selected as the matching result. Upon successful matching, clear and standardized detail data is generated. Subsequently, the server returns a second response dataset containing this standardized detail data to the terminal device.

[0079] The specific implementation of this matching process, as described in the following detailed description of invoice matching, involves matching the detailed invoice expense items with standard expense items using a pre-defined standard database.

[0080] Step 250: In response to receiving the claim trigger instruction for the claim case identifier, execute the predetermined claim logic corresponding to the target medical insurance type based on the annotation result data and the standardized detailed data, and generate claim conclusion data.

[0081] For example, the terminal device sends a third claims dataset to the server; the third claims dataset contains a claims case identifier and a claims calculation trigger instruction.

[0082] After receiving and confirming the standardized cost details, the terminal device triggers a claims calculation instruction (either by the operator or automatically by the system). The terminal device then sends a third claims dataset, containing the claims case identifier and the claims calculation trigger instruction, to the server. This step marks the case's transition from the initial data preparation and review stage to the core claims calculation and decision-making stage.

[0083] In response to the claim triggering instruction, the server executes a predetermined claim calculation logic corresponding to the target medical insurance type based on the annotation result data and the standardized detailed data to generate claim conclusion data, and sends a third response dataset containing the claim conclusion data to the terminal device.

[0084] Upon receiving the claim settlement trigger command, the server initiates the intelligent liability claim settlement process. The server simultaneously retrieves the previously generated annotation data (from step 220) and standardized detailed data (from step 240) for this case, using them as core inputs. Subsequently, based on the target medical insurance type involved in the case, the server invokes the corresponding pre-configured claim settlement rule engine. This rule engine automatically performs a series of complex calculations, including but not limited to: determining the claim settlement order based on liability priority rules, accumulating historical deductibles, calculating medical insurance deductions, etc., ultimately generating claim settlement conclusion data. The server sends the third-party response dataset containing the final loss assessment results to the terminal device, completing the core automated processing flow for this claim.

[0085] The specific details of the predetermined claims settlement logic, such as the refined processing of multi-liability prioritization and deductible accumulation, will be discussed later in conjunction with... Figure 3 The embodiments are described in detail below.

[0086] Steps 210-250 above together constitute the core interactive processing method proposed in this application. To more clearly demonstrate the specific implementation details of this method on the server and terminal sides, the following combines... Figure 3 and Figure 4 Please explain separately. This is understandable. Figure 3 and Figure 4 The described process is Figure 1 The overall interaction method shown is specifically implemented in the two logical units of server and terminal.

[0087] Figure 3 A server-side flowchart of a medical claims data processing method provided in this application embodiment is used to implement... Figure 2 The server-side processing method of the interaction flow shown, when the server acts as... Figure 2 When a process is executed by one of the main entities, its internal processing includes the following steps 310-360.

[0088] Step 310: Receive the first claims dataset; the first claims dataset contains claims case identifiers and a set of image files;

[0089] For example, after a claim case enters the system, it first goes through a preliminary review stage. The data received by the server corresponds to the work that the operators need to complete as described in the handover document:

[0090] The initial review of claims mainly involves reviewing case information, verifying the necessity and completeness of images, and collecting receipts.

[0091] In this embodiment, the terminal automatically uploads these materials to form a first claims dataset. The server responds to the access request from the terminal device and determines the claims case identifier.

[0092] Step 320: Perform optical character recognition processing based on the image file set to generate annotation result data; send a first response dataset corresponding to the claim case identifier, which includes the annotation result data;

[0093] For example, this application uses the following techniques to generate annotation results:

[0094] Intelligent image annotation uses OCR recognition to extract key information from images, automatically tags the key information onto the corresponding images, and supports operators to modify, filter, and sort the annotation information.

[0095] For image review, staff need to check each uploaded image to ensure its information matches the case details. Intelligent image annotation uses OCR to extract key information from the images, automatically tagging them with labels, and allowing staff to modify, filter, and sort the annotations.

[0096] The server encapsulates the annotation results data obtained from the above processing into a first response dataset and returns it.

[0097] In one embodiment, step 320, generating the annotation result data, specifically includes the following steps:

[0098] Step 320-1: Create an annotation record; the annotation record includes image file identifier, key field types, and field content;

[0099] For example, to manage annotation information, the system creates structured records:

[0100] Key information is automatically tagged onto the corresponding images.

[0101] This tag is the annotation record, which contains the image file identifier, key field types, and field content.

[0102] For example, the annotation record is a structured data object. For an image file named "Medical Record Cover Page.jpg", the system might generate an example record as follows: the image file identifier is F_20231025001, the key field type is discharge diagnosis, and the field content is lung adenocarcinoma. All annotation records are generated according to this paradigm and managed uniformly.

[0103] Step 320-2: Associate the annotation records with the corresponding image files and store them.

[0104] Step 330: Receive the second claims dataset; the second claims dataset contains claims case identifiers and medical expense invoice data;

[0105] For example, in the invoice collection stage, the medical expense invoice data received by this application corresponds to the information described in the disclosure document:

[0106] For invoice collection, operators need to enter the invoice information of each case into the system, which is divided into two methods: summary entry and detailed entry.

[0107] This application embodiment replaces the traditional manual input interface by receiving a structured electronic invoice data stream and calls the invoice intelligent matching module to achieve automatic matching.

[0108] Step 340: Send a second response dataset corresponding to the claim case identifier and the second claim dataset; the second response dataset contains the standardized detail data; the standardized detail data is generated by performing item standardization matching processing on the medical expense invoice data; the item standardization matching processing includes: matching the expense details in the invoice with the standard expense entries in the claim item database;

[0109] For example, this application employs the following intelligent matching technology:

[0110] For electronic invoice information, we use a professional database for data comparison. Based on the similarity of the three major claims categories and the comparison data, we automatically match electronic invoices using the data with the highest similarity, without the need for manual operation.

[0111] Once a match is successful, standardized detailed data is generated and packaged into the second response dataset for return.

[0112] In one embodiment, after sending the second response dataset and before receiving the third claims dataset, the following steps are included:

[0113] The system performs information extraction operations. Specifically, it extracts structured diagnostic information from the annotation result data and structured medical item information from the standardized detailed data.

[0114] Step 345-1-1: Based on the annotation result data or the standardized detailed data, query the preset diagnosis and treatment method mapping rules and send the diagnosis and treatment method option list.

[0115] For example, the preset treatment method mapping rules are a pre-built logical judgment library in the system. This rule library uses structured diagnostic information (such as malignant tumors) from the annotation result data and medical item information (such as radiotherapy) from the standardized detailed data as joint input keys. By querying this rule library, the system can map and generate a detailed list of treatment method options for the user to choose from (e.g., mapping out radiotherapy for malignant tumors). This mechanism ensures the accuracy of responsibility matching.

[0116] Step 345-1-2: Receive response data; the response data contains items selected from the option list; the response data is included in the third claims dataset.

[0117] For example, in certain complex situations, this application provides further interactive capabilities to accurately match responsibilities:

[0118] Detailed list of treatment methods: In addition to the existing treatment methods, more specific treatment methods related to malignant tumors have been added to facilitate claims personnel to make more precise selections and thus accurately match liability in the future.

[0119] The server can proactively initiate detailed inquiries about treatment methods based on diagnostic or project information.

[0120] In one embodiment, matching the expense details with the standard expense items specifically includes the following steps:

[0121] Step 345-2-1: Calculate the text similarity between the text description of the expense details item and the name of the standard expense item.

[0122] For example, calculating the text similarity between the text description of the expense details item and the name of the standard expense item can be achieved using various text matching algorithms known in the art.

[0123] For example, preferably, a cosine similarity algorithm is used. First, the two text items are segmented and quantized separately. Then, the cosine of the angle between their corresponding vectors in space is calculated. This value is between 0 and 1, with the closer the value is to 1, the higher the similarity. The system can preset a similarity threshold, and a match is considered successful only when the calculated result is higher than this threshold.

[0124] Step 345-2-2: If there are multiple matching items, select the standard cost item with the highest similarity as the matching result.

[0125] Based on the similarity of the three major claims categories and the comparison data, the electronic invoices are automatically matched using the data with the highest similarity.

[0126] In some embodiments, the system is also configured with an abnormal case identification mechanism. If the OCR recognition confidence level is lower than a preset threshold, or the invoice matching similarity is lower than a threshold, or the calculation result deviates too much from historical data, the system automatically marks the case as an 'abnormal case' and triggers a manual review process, while recording the reason for the abnormality for rule optimization.

[0127] In some embodiments, the system is also configured with an abnormal case identification mechanism. If a case is determined to be an abnormal case based on the annotation result data and standardized detailed data, a manual intervention flag is generated, and the automatic settlement process is suspended. The conditions for determining an abnormal case may include: the confidence level of optical character recognition is lower than a preset threshold, the similarity of document matching is lower than a threshold, or the deviation between the intermediate settlement result and the historical data model exceeds a preset range.

[0128] After executing step 340, the system does not immediately proceed to step 350. Instead, it first enters an abnormal case judgment step, where the system verifies the generated annotation results data against the standardized detailed data. If the case is determined to be abnormal, a manual intervention flag is generated, the subsequent automatic settlement process is suspended, and the case is transferred to the manual processing path. If the case is determined to be normal, the system continues to execute step 350, waiting for and receiving settlement trigger instructions to execute subsequent automatic settlement.

[0129] In one embodiment, the system is also configured with an abnormal case identification mechanism. If the confidence level of optical character recognition in step 320 is lower than a preset threshold, or the similarity of bill matching in step 340 is lower than a preset threshold, or the deviation between the intermediate results of subsequent claims processing and the historical data model exceeds a preset range, the system automatically marks the case as an abnormal case, generates a manual intervention flag, suspends the automatic claims processing process, and triggers a manual review branch.

[0130] In one embodiment, after executing steps 320 (image annotation) and 340 (ticket matching), the system is further configured with an abnormal case identification mechanism. This mechanism is used to perform data quality and logical verification before executing the automatic processing flow. Specifically, the system evaluates the case status based on multiple preset judgment conditions, such as:

[0131] In one embodiment, image recognition anomaly judgment is implemented: if the overall confidence level or the recognition confidence level of key fields (such as name, amount, date) of the annotation result data generated by the optical character recognition processing in step 320 is lower than the first preset threshold, then the first type of anomaly mark is triggered.

[0132] In one embodiment, an anomaly detection for invoice matching can also be implemented: if the highest text similarity between the expense details item and the standard expense item is lower than the second preset threshold in the standardized matching process of the item in step 340, or if no matching item can be found, then a second type of anomaly marker is triggered.

[0133] In one embodiment, logical contradiction judgment can also be implemented: if there is a logical conflict between the annotation result data (such as diagnostic information) and the standardized detailed data (such as medical items) in the preset medical knowledge graph or rule base (for example, the diagnosis and treatment plan are obviously inconsistent), then the third type of abnormality marker is triggered.

[0134] When any one or more of the above abnormal conditions are met, the system determines the case to be an abnormal case. The system will then perform the following operations:

[0135] Generate and associate a manual intervention identifier with the claim case identifier;

[0136] Suspend subsequent automatic claims processing, meaning the system will not respond to or execute any claims triggering instructions based on this case;

[0137] The case status is switched to pending manual review, and the case can be routed to a dedicated review queue through the workflow engine.

[0138] For cases that are not marked as abnormal, the system will continue to wait for and receive claims trigger instructions, and then proceed to the subsequent automatic claims process.

[0139] Step 350: Receive the third claims dataset, which contains claims case identifiers and claims calculation trigger instructions;

[0140] Once the invoices are processed, the system waits for and receives the instruction to trigger the final settlement, and then proceeds to the claims processing stage.

[0141] The system determines whether a case is an anomaly. Based on the annotation results and standardized detailed data, the system executes anomaly judgment logic (specific judgment conditions are described in the relevant embodiments above). If the case is determined to be an anomaly, a manual intervention flag is generated, the automatic processing flow is paused, and the case is transferred to the manual processing path.

[0142] Step 360: If the case is determined to be non-abnormal, a third response dataset is sent; the third response dataset contains the claim case identifier and claim conclusion data; the claim conclusion data is generated in response to the claim triggering instruction, based on the annotation result data and the standardized detailed data, by executing the predetermined claim calculation logic corresponding to the target medical insurance type.

[0143] For example, in the claims processing stage, this application uses intelligent liability calculation to automate the payment of complex insurance products.

[0144] By reconstructing the claims calculation engine and adjusting the claims settlement plan and data entry method, automatic calculation is achieved. The specific operation is as follows:

[0145] In one embodiment, the claims processing engine is restructured and the claims settlement scheme is adjusted. Specifically, the previous method of writing rules is replaced with a built-in calculation process, which supports automatic sorting and priority calculation based on the presence or absence of medical insurance invoices and liabilities through in-memory calculation, and ensures correct deductible deduction when multiple policies are being processed.

[0146] In another embodiment, the list of treatment options is refined. Specifically, based on the existing treatment options, sub-categories related to malignant tumors are added to facilitate more precise selection by claims personnel, thereby ensuring accurate matching of liability subsequently.

[0147] The core of claims processing lies in confirming insurance liability and calculating the compensation amount. In existing technology, this step is highly dependent on manual labor: operators need to manually handle various complex rules such as deductible calculation, medical insurance expense deduction, and third-party payment offsetting, and perform calculations strictly in a specific order, which is cumbersome and prone to errors.

[0148] In this embodiment of the application, the server automatically generates claim conclusion data through the predetermined claim calculation logic described above, and encapsulates it into a third response dataset for return, thus completing the processing.

[0149] In one embodiment, step 360, which executes the predetermined computational logic, specifically includes the following steps:

[0150] Step 360-1: Based on the preset liability priority rules, and the expense types and treatment information in the medical expense invoice data and the annotation result data, determine the execution order of multiple claims liabilities; wherein, the liability priority rules are a logical judgment rule base or decision tree pre-configured in the system and bound to the target medical insurance type, used to replace manual memorization and application.

[0151] Step 360-2: According to the claim calculation execution order, perform the corresponding claim calculations on the expense items in the standardized detailed data in sequence.

[0152] In one embodiment, the predetermined compensation logic in step 360 includes rules for processing deductibles, the rules including:

[0153] Based on the claim case identifier, retrieve all claim settlement records with the same policy identifier from the historical claims database;

[0154] Sum the deductible field in all retrieved claims settlement records to obtain the cumulative historical deductible value;

[0155] The cumulative historical deductible is used as an input parameter for calculating the current claim amount.

[0156] One of the key aspects of the predetermined claims settlement logic is to automate the order of claims settlement. Specifically, this can be achieved by using in-memory computing to support automatic sorting and priority settlement based on the presence or absence of medical insurance invoices and the nature of the liability.

[0157] Another key aspect of the pre-defined claims settlement logic is the support for complex deductible rules, enabling correct deductible deduction when settling claims for multiple policies.

[0158] Figure 4 A terminal-side flowchart of a medical claims data processing method provided in this application embodiment is used to implement... Figure 2 The terminal-side processing method of the interactive flow shown is as follows: Figure 4 As shown, when the terminal device acts as Figure 2 When another entity executes the process, its interactive actions include the following steps 410-460.

[0159] Step 410: Send the first claims dataset, which contains claims case identifiers and a set of image files;

[0160] Once a claim is entered into the system, the process is initiated by the terminal.

[0161] The terminal can be operated by a customer or operator and includes a user interface and a client program execution module.

[0162] The terminal sends the first claims dataset, which includes claims case identifiers and a set of image files, effectively replacing the manual submission of paper documents in the traditional process.

[0163] Step 420: Receive and display the first response dataset; the first response dataset contains annotation result data;

[0164] The server will return the result after processing.

[0165] The terminal receives the first response dataset from the server, which contains annotation results for the image.

[0166] The annotation results are associated with the images in the form of tags, which can help operators quickly verify them.

[0167] In one embodiment, receiving and displaying the first response dataset in step 420 specifically includes the following steps:

[0168] Step 420-1: Display the image file and associated annotation result data;

[0169] The terminal displays both the image file and automatically generated annotation information on the user interface.

[0170] This allows operators to complete the review process directly within the interface without having to record information outside the system.

[0171] Step 420-2: Provide a user interface; the user interface is based on the field type or field content in the annotation result data and is used to filter or sort the image files.

[0172] Previously, each image required manual review, as the system lacked annotation functionality for critical information. Operators had to manually record supplementary information outside the system. Now, operators can filter and sort images based on annotations, significantly improving the efficiency of image review.

[0173] Furthermore, the user interface also provides a batch review mode, allowing operators to confirm the annotation information of multiple image files at once, significantly reducing click operations and interface switching, and solving the efficiency bottleneck of traditional serial review.

[0174] To further improve review efficiency, the terminal interface provides annotation-based interactive functions. Operators can modify, filter, and sort annotation information. Operators can quickly locate specific images based on key fields in the annotations (such as date and type).

[0175] For example, such as Figures 5.1 to 5.3 As shown, the user interface can intuitively display, sort, and filter annotation information, thereby assisting operators in quickly completing image review.

[0176] Figure 5.1 This is an example of annotating a specific image. The fields that can be annotated include: consultation time, annotation amount, treatment method, hospital, and remarks (which can be filled in by the user).

[0177] Figure 5.2 This is an example of an image review page. Images are filtered based on selection criteria. The fields highlighted in the image are: consultation time and annotation amount. Images can be filtered using these fields to display those that meet the requirements.

[0178] Figure 5.3 This is another example of an image review page, displaying images from a different perspective: grouping. The fields highlighted in the image are: consultation method, hospital, and remarks. All images can be grouped and displayed using these fields.

[0179] In conclusion, Figure 5.1 It involves annotating images. Figure 5.2 and Figure 5.3 It involves filtering and grouping images. The main purpose is to help reviewers quickly locate the images they need, as image review is often not completed in one go and may require multiple rounds of viewing. Using annotation information makes it easier for reviewers to quickly locate images.

[0180] Step 430: Send the second claims dataset, which contains the claims case identifier and medical expense invoice data.

[0181] Following the image review stage, the next step is invoice collection. The terminal sends a second claims dataset containing the same claims case identifier and medical expense invoice data. This essentially transforms the traditional manual entry of invoices into uploading structured electronic data.

[0182] Step 440: Receive and display the second response dataset; the second response dataset contains standardized detailed data.

[0183] The server performs intelligent matching of invoices and returns the results. The terminal receives and displays the second response dataset, which contains standardized cost details. Operators can then visually verify the accuracy of the system's automatic matching results.

[0184] Step 450: Send the third claims dataset, which contains the claims case identifier and the claims calculation trigger instruction.

[0185] Once the operator confirms the accuracy of the preliminary data, the final calculation can be triggered. The terminal sends a third claims dataset containing the claims case identifier and the calculation trigger instruction. This step is a crucial interaction point connecting the preliminary data preparation with the subsequent intelligent calculation.

[0186] Step 460: Receive and display the third response dataset; the third response dataset contains claims conclusion data.

[0187] After the server completes the intelligent claims calculation, it returns the final result. The terminal receives and displays the third response dataset, which contains the claims conclusion data automatically calculated by the system.

[0188] Figure 6 This is a schematic diagram of the core technical points of the intelligent claims processing solution provided in the embodiments of this application. This application realizes three core capabilities—intelligent image annotation, intelligent detail matching, and intelligent liability calculation—by intelligently transforming the traditional claims preliminary review and claims processing stages, thereby constructing a complete intelligent claims processing solution.

[0189] Figure 7 This application provides a structural diagram of a medical claims data processing device according to an embodiment of the present application. The device is used to implement the medical claims data processing method as described in any one of the first aspects, comprising:

[0190] The acquisition module 701 is used to acquire a first claims dataset; the first claims dataset contains claims case identifiers and a set of image files, as described in step 210 of the embodiment.

[0191] It is also used to obtain a second claims dataset; the second claims dataset contains medical expense invoice data, as described in step 230 of the embodiment.

[0192] The determination module 702 is used to perform optical character recognition processing on the image file set to generate annotation result data corresponding to the claim case identifier, as described in step 220 of the embodiment.

[0193] It is also used to perform standardized matching processing on the medical expense invoice data to generate standardized detailed data; the standardized matching processing includes: matching the expense details in the invoice with the standard expense items according to the preset matching rules, as described in step 240 of the embodiment.

[0194] The execution module 703 is used to respond to receiving a claim trigger instruction for the claim case identifier, and execute the predetermined claim logic corresponding to the target medical insurance type according to the annotation result data and the standardized detailed data, and generate claim conclusion data, as described in step 250 of the embodiment.

[0195] Figure 8 This is a schematic diagram of an application scenario system according to an embodiment of this application, including:

[0196] A first computer device 800 is deployed with the apparatus as described in the second aspect embodiment, or is configured to perform the method as described in any one of the first aspect embodiments, as described in steps 210-250, 310-360.

[0197] The second computer device 900 is communicatively connected to the first computer device and is used to provide a set of image files, medical expense invoice data and claims triggering instructions, and to receive and present annotation result data, standardized detailed data and claims conclusion data.

[0198] The first computer device is specifically implemented as a server-side device, and the second computer device is specifically implemented as a terminal device. The terminal device can be a personal computer, smartphone, or similar device operated by an insurance customer or claims personnel, used to initiate requests, upload data, and receive and display information. The server-side device is a backend server that has deployed the intelligent claims processing program of this application, used to receive requests, execute core data processing and calculation logic, and return a response.

[0199] The terminal equipment described in this application can refer to mobile communication user equipment, personal mobile terminals, smart terminals, mobile phones, tablet computers, computers with communication functions, electronic systems or computer systems that provide services to the aforementioned equipment, or any system, subsystem, module, circuit, chip, or software operating device that provides information reception, transmission, identification, and processing for the aforementioned equipment. In claims scenarios, it typically refers to the device operated by insurance customers or claims personnel and running corresponding client software.

[0200] The server-side equipment described in this application can refer to network infrastructure, network-side equipment connected to a communication system, or application servers. It can also be an electronic system or computer system providing services to the aforementioned equipment, or any system, subsystem, module, circuit, chip, or software operating device that provides information reception, transmission, identification, and processing for the aforementioned equipment. The server-side equipment can be a single physical or virtual server, or a cluster or distributed system composed of multiple devices connected through a communication network. For example, its functions can be performed by a single integrated server, or collaboratively by multiple logical servers dedicated to image processing, data matching, and rule calculation, respectively.

[0201] In another embodiment, the first computer device further includes at least one of the following:

[0202] Image annotation database 801, connected to the first computer device, is used to store annotation records associated with image files generated through optical character recognition processing;

[0203] Claims item database 802, connected to the first computer device, is used to store standard expense items;

[0204] The claims rule base 803 is connected to the first computer device and is used to store the predetermined claims logic corresponding to the target medical insurance type.

[0205] The aforementioned database can be used as an internal component of the first computer device, or it can be deployed as an independent database server connected to this system.

[0206] Figure 9 This is a schematic diagram illustrating the composition of the intelligent claims processing system provided in an embodiment of this application. Figure 9 As shown, the system is used to implement the aforementioned interactive processing method and includes a first computer device and a second computer device.

[0207] The first computer device 800 includes:

[0208] The first acquisition module 804 is used to acquire a first claims dataset, a second claims dataset, and a third claims dataset from a second computer device; wherein, the first claims dataset contains a set of image files, the second claims dataset contains medical expense invoice data, and the third claims dataset contains claims trigger instructions, as described in steps 310, 330, and 350 of the embodiment.

[0209] The first determining module 805 is used to perform optical character recognition processing on the image file set to determine annotation result data; it is also used to perform item standardization matching processing on the medical expense invoice data to determine standardized detailed data; and it is also used to respond to the claim triggering instruction and, based on the annotation result data and the standardized detailed data, execute predetermined claim logic to determine claim conclusion data, as described in steps 320, 340 and 360 of the embodiment.

[0210] The first sending module 806 is used to send a first response dataset containing the annotation result data, a second response dataset containing the standardized detailed data, and a third response dataset containing the claim conclusion data to the second computer device, as described in steps 320, 340, and 360 of the embodiment.

[0211] The second computer device 900 includes:

[0212] The second acquisition module 901 is used to acquire the image file set, the medical expense invoice data, and the settlement trigger instruction, as described in steps 410, 430, and 450 of the embodiment.

[0213] The second determining module 902 is used to determine and present the corresponding data contained in the first response dataset, the second response dataset, and the third response dataset sent by the first computer device, as described in steps 420, 440, and 460 of the embodiment.

[0214] The second sending module 903 is used to send the first claim dataset, the second claim dataset, and the third claim dataset to the first computer device, as described in steps 410, 430, and 450 of the embodiment.

[0215] It should be noted that in the above system, the first computer device typically corresponds to a backend server, which is used to execute core data processing and calculation logic; the second computer device typically corresponds to a frontend terminal device, which is used to initiate requests, upload data, and receive and display information. Figure 10 and Figure 11 A specific hardware implementation structure of the first computer device and the second computer device are shown respectively.

[0216] It should be noted that, Figure 9 The module division between the first and second computer devices is shown from a logical functional perspective, while Figure 10 and Figure 11 This illustrates a specific hardware implementation structure for each of the two logic devices. Figure 10 Corresponding to Figure 9 The first computer device 800 in the middle specifies its logical functions as a server sending module 1001, a server determining module 1002, and a server receiving module 1003, and supplements it with an image annotation database 1004, a claims item database 1005, and a claims calculation rule base 1006 as its supporting storage. Figure 11 Corresponding to Figure 9 The second computer device 900 in the system specifies its logical functions as a terminal sending module 1101, a terminal determining module 1102, and a terminal receiving module 1103.

[0217] Figure 10 This is a structural diagram of an embodiment of the server-side device of this application.

[0218] This application also provides a server-side device for implementing the method of any embodiment of this application, wherein the server-side device is used to implement, as in... Figure 2 , Figure 3 The method flow shown is as described in steps 210-250 and 310-360.

[0219] To implement the above technical solution, this application proposes a server-side device comprising a server sending module 1001, a server determining module 1002, a server receiving module 1003, an image annotation database 1004, a claims item database 1005, and a claims calculation rule database 1006, all interconnected.

[0220] The server sending module 1001 is used to send the first response dataset, the second response dataset, and the third response dataset.

[0221] The server determination module 1002 is used to determine the annotation result data, standardized detailed data, and claims conclusion data; specifically, it is used to perform optical character recognition processing to generate annotation result data, perform project standardization matching processing to generate standardized detailed data, and perform predetermined claims calculation logic to generate claims conclusion data.

[0222] The server receiving module 1003 is used to receive access requests from terminal devices and the first claim dataset, the second claim dataset, and the third claim dataset.

[0223] The image annotation database 1004 is used to store annotation records associated with image files generated through optical character recognition processing.

[0224] The claims database 1005 contains preset standard claims entries, which are used to match expense details in the standardized matching process.

[0225] The claim settlement rule base 1006 includes preset claim settlement logic corresponding to the target medical insurance type. The logic at least defines liability priority rules and deductible handling rules.

[0226] The specific methods for implementing the functions of the server sending module 1001, server determining module 1002, server receiving module 1003, image annotation database 1004, claims item database 1005, and claims calculation rule base 1006 are as described in the various method embodiments of this application, and will not be repeated here.

[0227] Figure 11 This application provides a structural diagram of a terminal device embodiment. The application also proposes a terminal device for implementing the method of any embodiment of the application. The terminal device is used to implement the method flow shown in FIG5, as described in steps 410 to 460.

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

[0229] The terminal receiving module 1103 is used to receive a first response dataset, a second response dataset, and a third response dataset from a server-side device.

[0230] The terminal determination module 1102 is used to determine the data content and interaction logic to be displayed; specifically, it is used to determine how to display the annotation result data in the first response dataset, the standardized detailed data in the second response dataset, and the claim conclusion data in the third response dataset, and to determine to provide a user interface for filtering or sorting based on the annotation result data.

[0231] The terminal sending module 1101 is used to send the first claim dataset, the second claim dataset, and the third claim dataset to the server device.

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

[0233] The server-side device and terminal device in the embodiments of this application can both be a computing device, which typically includes one or more processors (CPU), input / output interfaces, network interfaces, and memory (RAM / ROM). The memory stores instruction programs executable by the processor. When the processor executes the program, the device performs the steps described in any of the above embodiments. The computing device can be a physical server, a virtual machine, a personal computer, a smartphone, or a dedicated terminal, etc.

[0234] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0235] Therefore, this application also proposes a computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the methods described in any embodiment of this application.

[0236] Furthermore, this application also proposes an electronic device (or computing device) including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method described in any embodiment of this application.

[0237] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, a network interface, and memory. Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0238] 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.

[0239] 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.

[0240] 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.

[0241] 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. A method for processing medical claims data, characterized in that, Includes the following steps: Obtain the first claims dataset; the first claims dataset contains claims case identifiers and a set of image files; The image file set is subjected to optical character recognition processing to generate annotation result data corresponding to the claim case identifier; Obtain the second claims dataset; the second claims dataset contains medical expense invoice data; The medical expense invoice data is subjected to standardized matching processing to generate standardized detailed data; the standardized matching processing includes: matching the expense details in the invoice with standard expense items according to preset matching rules; In response to receiving a claim settlement trigger instruction for the claim case identifier, the system executes the predetermined claim settlement logic corresponding to the target medical insurance type based on the annotation result data and the standardized detailed data, and generates claim settlement conclusion data.

2. The medical claims data processing method as described in claim 1, characterized in that, Executing the predetermined computational logic specifically includes the following steps: Based on the preset liability priority rules, and the expense types and treatment information in the medical expense invoice data and the annotation result data, the order of execution of multiple claims is determined; According to the aforementioned claim calculation execution order, the corresponding claim calculations are performed on the expense items in the standardized detailed data in sequence.

3. The medical claims data processing method as described in claim 1, characterized in that, The predetermined compensation logic includes rules for handling deductibles, and these rules include: Based on the claim case identifier, retrieve all claim settlement records with the same policy identifier from the historical claims database; Sum the deductible field in all retrieved claims settlement records to obtain the cumulative historical deductible value; The cumulative historical deductible is used as an input parameter for calculating the current claim amount.

4. The medical claims data processing method as described in claim 1, characterized in that, The calculation trigger instruction includes selection information for treatment method options generated based on the annotation result data or the standardized detailed data.

5. The medical claims data processing method as described in claim 1, characterized in that, The process of generating the annotation result data specifically includes the following steps: Create an annotation record; the annotation record includes the image file identifier, key field types, and field content; The annotation records are associated with and stored in relation to the corresponding image files.

6. The medical claims data processing method as described in claim 1, characterized in that, The matching of the detailed cost items with the standard cost items includes the following steps: Calculate the text similarity between the text description of the expense details item and the name of the standard expense item; The standard cost item with the highest similarity is selected as the matching result to generate the standardized detailed data.

7. The medical claims data processing method as described in claim 1, characterized in that, The annotation result data is used to display the image file in association with the user interface, and supports filtering or sorting the image file based on the fields in the annotation result data.

8. The medical claims data processing method as described in claim 1, characterized in that, Before performing the step of generating claims conclusion data, the following steps are also included: Based on the annotation results data and the standardized detailed data, determine whether the claim case is an abnormal case; If the case is determined to be abnormal, a manual intervention flag is generated, and the execution of the predetermined processing logic is terminated.

9. A medical claims data processing apparatus, used to implement the medical claims data processing method according to any one of claims 1 to 8, characterized in that, Include: The acquisition module is used to acquire a first claims dataset, which contains claims case identifiers and a set of image files; it is also used to acquire a second claims dataset, which contains medical expense invoice data; The determination module is used to perform optical character recognition processing on the image file set to generate annotation result data corresponding to the claim case identifier; it is also used to perform item standardization matching processing on the medical expense invoice data to generate standardized detailed data; the item standardization matching processing includes: matching the expense details in the invoice with standard expense items according to preset matching rules; The execution module is used to respond to the claim trigger instruction received for the claim case identifier, and to execute the predetermined claim logic corresponding to the target medical insurance type according to the annotation result data and the standardized detailed data, and generate claim conclusion data.

10. A medical claims data processing system, characterized in that, include: A first computer device, having the apparatus as described in claim 9, or configured to perform the method as described in any one of claims 1 to 8; The second computer device is communicatively connected to the first computer device and is used to provide a set of image files, medical expense invoice data and claims triggering instructions, and to receive and present annotation result data, standardized detailed data and claims conclusion data.

Images