A medical insurance audit evidence matching and completeness evaluation method, system, electronic device and computer readable storage medium

Abstract

The embodiment of the application discloses a medical insurance audit evidence matching and completeness evaluation method and system, electronic equipment and computer readable storage medium, the method comprises the following steps: obtaining a medical insurance audit return task and analyzing and generating a return element structure body; determining evidence requirement information according to the return element structure body and generating an evidence list; according to the evidence list, corresponding evidence data is retrieved and bound from a medical data source to obtain evidence binding records; based on the matching result of the evidence list and the evidence binding record, an evidence completeness judgment result is generated, and the output is a to-be-supplemented evidence, an unappealable or appealable appeal suggestion result, which realizes the structured judgment of the evidence completeness, and improves the systematic level and processing efficiency of the appeal material preparation.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method, system, electronic device, and computer-readable storage medium for evidence matching and completeness assessment in medical insurance review. Background Technology

[0002] Against the backdrop of medical insurance payment reform and intelligent supervision, medical insurance agencies return suspected non-compliant items to hospitals through routine reviews, requiring them to appeal within a specified period. However, with the increasing workload and complexity of rules, the efficiency and quality of the traditional manual review model are under pressure.

[0003] The relevant technological accumulation is mainly reflected in the following three aspects: First, process management, building an online platform to realize the online appeal process; second, intelligent decision-making, introducing large language models and graph retrieval enhancement methods to conduct post-compliance assessment based on existing materials; and third, data association, constructing a multi-source data evidence chain to support the traceability of heterogeneous data.

[0004] However, the above solutions share common limitations at the hospital level: they cannot automatically determine whether the existing materials are sufficient to support the appeal before submission, nor can they distinguish between insufficient materials and failures due to rule incompatibility. The systems mostly only return simple statuses or binary suggestions, and in batch scenarios, they still heavily rely on manual review, making it difficult to systematically solve the problems of missing materials and insufficient retrieval. Summary of the Invention

[0005] This application proposes a method for evidence matching and completeness assessment in medical insurance review, aiming to solve the problem that existing technologies are unable to automatically distinguish between insufficient evidence and unsupported rules, resulting in the material preparation still relying on manual verification, retrieval omissions, and incomplete submissions.

[0006] This application provides a method for evidence matching and completeness assessment in medical insurance review, the method including: Obtain medical insurance review rejection tasks, parse the rejection information in the medical insurance review rejection tasks, and generate a rejection element structure; Based on the return element structure, determine the evidence requirement information suitable for the medical insurance review return task, and generate an evidence list containing at least one evidence requirement item based on the evidence requirement information; Based on the evidence requirement items in the evidence list, retrieve the evidence data corresponding to the evidence requirement items from the medical data source and bind them to obtain the evidence binding record; Based on the matching results between the evidence list and the evidence binding records, the evidence completeness determination result of the evidence list is generated, and the appeal suggestion result is output according to the evidence completeness determination result. The appeal suggestion result includes one of the following: evidence to be supplemented, no appeal, appealable.

[0007] Accordingly, this application also provides an evidence matching and completeness assessment system for medical insurance review, the system including: The task access module is used to obtain medical insurance review rejection tasks; The element parsing module is used to parse the return information in the medical insurance review return task and generate the return element structure. The mapping library management module is used to determine the evidence requirement information that is suitable for medical insurance review return tasks based on the return element structure; The list generation module is used to generate an evidence list containing at least one evidence requirement item based on the evidence requirement information. The multi-source retrieval and binding module is used to retrieve the evidence data corresponding to the evidence requirement items in the evidence list from medical data sources and bind them to obtain evidence binding records. The completeness calculation module is used to generate the evidence completeness judgment result of the evidence list based on the matching results between the evidence list and the evidence binding records; The suggestion output module is used to output the appeal suggestion results.

[0008] Accordingly, this application also provides an electronic device, including a memory, a processor, and a computer program stored on the memory and running on the processor, wherein the processor, when executing the program, implements the above-mentioned evidence matching and completeness assessment method for medical insurance review.

[0009] Accordingly, this application also provides a computer-readable storage medium storing a plurality of instructions adapted for loading by a processor to execute the above-described evidence matching and completeness assessment method for medical insurance review.

[0010] This application obtains medical insurance review return tasks, parses the return information in the medical insurance review return tasks, and generates a return element structure; determines the evidence requirement information suitable for the medical insurance review return tasks based on the return element structure, and generates an evidence list containing at least one evidence requirement item based on the evidence requirement information; retrieves the evidence data corresponding to the evidence requirement item from the medical data source according to the evidence requirement item in the evidence list and binds it to obtain an evidence binding record; generates an evidence completeness judgment result for the evidence list based on the matching result of the evidence completeness judgment result, and outputs an appeal suggestion result based on the evidence completeness judgment result. The appeal suggestion result includes one of the following: evidence to be supplemented, not appealable, and appealable. This realizes the structured judgment of evidence completeness and automated sorting in the scenario of batch daily review, and improves the systematization level and processing efficiency of appeal material preparation. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] in: Figure 1 This is a schematic diagram of an evidence matching and completeness assessment system for medical insurance review provided in an embodiment of this application.

[0013] Figure 2 This is a flowchart illustrating a method for evidence matching and completeness assessment in medical insurance review, provided as an embodiment of this application.

[0014] Figure 3 This is a flowchart illustrating another method for evidence matching and completeness assessment in medical insurance review provided in this application embodiment.

[0015] Figure 4 This is a schematic diagram illustrating the generation of the multi-layer mapping library and evidence list provided in the embodiments of this application.

[0016] Figure 5 This is a flowchart illustrating the completeness calculation and appeal suggestion determination process provided for embodiments of this application.

[0017] Figure 6 This is a structural block diagram of an evidence matching and completeness assessment device for medical insurance review provided in an embodiment of this application.

[0018] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0019] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0020] This application provides a method, system, electronic device, and computer-readable storage medium for evidence matching and completeness assessment in medical insurance review. Specifically, the evidence matching and completeness assessment method for medical insurance review in this application can be executed by an electronic device, which can be a terminal or a server. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, and big data and artificial intelligence platforms.

[0021] Based on the above problems, this application provides a method, system, electronic device and computer-readable storage medium for evidence matching and completeness assessment in medical insurance review, which realizes the structured determination of evidence completeness and automated sorting in batch daily review scenarios, and improves the systematization level and processing efficiency of appeal material preparation.

[0022] The following sections provide detailed descriptions of each example. It should be noted that the order in which the embodiments are described is not intended to limit the preferred order of the embodiments.

[0023] For example, please see Figure 1 , Figure 1 This diagram illustrates an evidence matching and completeness assessment system for medical insurance review, provided as an embodiment of this application. The system includes a task access module 101, an element parsing module 102, a mapping library management module 103, a list generation module 104, a multi-source retrieval and binding module 105, a completeness calculation module 106, and a suggestion output module 107. Specifically, the functions of each module are as follows: The task access module 101 is used to obtain medical insurance review return tasks. For example, the task access module 101 receives a daily review return task package transmitted through the hospital's medical insurance system. The task package contains at least one or more of the following fields: return or violation related code, medical insurance item name, hospital item name, rule name, violation content, preliminary review opinion, visit category, settlement or fee date, and diagnosis summary.

[0024] The element parsing module 102 is used to parse the return information in the medical insurance review return task and generate a return element structure. For example, the element parsing module 102 maps the task package received by the task access module 101 into a return element structure. The attributes of the return element structure include at least disease or diagnosis-related elements, treatment behavior elements, drug or consumable elements, laboratory test elements, inpatient / outpatient identification, and cost time point elements. The element parsing module also normalizes or aligns the hospital project name with the medical insurance project name to eliminate discrepancies in scope.

[0025] The mapping library management module 103 is used to determine the evidence requirements for medical insurance review return tasks based on the return element structure. For example, the mapping library management module 103 maintains a preset multi-layer mapping library, which includes a rule layer, a policy layer, and an evidence type layer. The rule layer is used to match daily review rule entries by rule name, medical insurance catalog code, or item name pattern; the policy layer is used to associate policy fragment identifiers such as limited payment, local medical insurance details, and drug instruction summary; and the evidence type layer is used to define the set of evidence types required for each return item. The mapping library management module 103 retrieves the mapping record associated with the return item in the mapping library based on the return item identifier in the return element structure.

[0026] The list generation module 104 is used to generate an evidence list containing at least one evidence requirement item based on the evidence requirement information. For example, the list generation module 104 generates an evidence list for each returned item according to the mapping record. Each evidence requirement in the list includes attributes such as evidence type identifier, whether it is mandatory, priority weight, time constraint, and cross-visit constraint. The time constraint includes that the date of the test sampling or report must cover a preset time window before and after the date of the violation fee. The cross-visit constraint includes that it needs to be associated with the medical record cover page or outpatient medical record of other visits. The evidence list is generated before the multi-source retrieval and binding module 105 performs the retrieval, so that the collection target of supplementary evidence is determined in advance.

[0027] The multi-source retrieval and binding module 105 is used to retrieve evidence data corresponding to the evidence requirements items in the evidence list from medical data sources and bind them to obtain evidence binding records. For example, the multi-source retrieval and binding module 105 retrieves data objects related to the current patient, current medical visit, and the associated medical visit required by the mapping record from at least two data sources such as hospital information systems, testing systems, billing systems, electronic medical records, and document storage. For each item in the list, the multi-source retrieval and binding module 105 locates candidate fragments in structured fields or unstructured documents and generates evidence binding records. The evidence binding records at least include the list item identifier, evidence type, source system type, original record identifier, binding confidence level, and original text or fragment summary.

[0028] The completeness calculation module 106 is used to generate an evidence completeness judgment result for the evidence list based on the matching results between the evidence list and the evidence binding records. For example, the completeness calculation module 106 first determines the individual satisfaction level of each evidence requirement item in the evidence list, then performs aggregate calculation based on the individual satisfaction level of each evidence requirement item and a preset weight to obtain the comprehensive completeness of the evidence list, and finally determines the evidence completeness judgment result of the evidence list based on the comprehensive completeness. In one implementation, the individual satisfaction level is determined based on whether there is a corresponding evidence binding record and whether the binding confidence level reaches a preset confidence threshold, and the comprehensive completeness is obtained by weighted calculation based on the completeness of the mandatory evidence layer and the completeness of the optional evidence layer.

[0029] The suggestion output module 107 is used to output the appeal suggestion result. For example, based on the evidence completeness determination result output by the completeness calculation module 106, and combined with the rule layer's determination result on whether the current returned matter supports an appeal, the suggestion output module 107 outputs one of three appeal suggestion states: evidence to be supplemented, no appeal, and appealable. In one embodiment, when the evidence completeness determination result indicates that the preset completeness condition is not met, evidence to be supplemented is output; when the preset completeness condition is met and the rule layer determines that the appeal is not supported, no appeal is output; when the preset completeness condition is met and the rule layer determines that the appeal is supported, appealable is output.

[0030] For further details, please refer to Figure 2 , Figure 2 This is a flowchart illustrating a method for evidence matching and completeness assessment in medical insurance review, provided as an embodiment of this application. The specific process of this method for evidence matching and completeness assessment in medical insurance review can be as follows: 201. Obtain medical insurance review return tasks, parse the return information in the medical insurance review return tasks, and generate a return element structure.

[0031] Among them, the task of medical insurance review and return refers to the task of medical insurance agencies, in the course of routine or special review, to review the medical expense declaration items of designated medical institutions, return the items suspected of being in violation to the medical institutions, and require the medical institutions to verify and supplement the evidence within a time limit and provide feedback on the appeal.

[0032] The task of returning medical insurance review requests is issued by the medical insurance agency through the review system. After receiving the request through the system, the medical institution must complete the supplementary evidence and appeal feedback within the prescribed appeal period.

[0033] In one implementation, obtaining medical insurance review rejection tasks may include receiving daily review rejection tasks from a message queue or service interface. The medical insurance agency's review system and the medical institution's system communicate via message queues (e.g., RabbitMQ, Kafka) or service interfaces (e.g., HTTP API, Web Service). When the medical insurance agency completes the review of medical expense claims and rejects items suspected of being non-compliant, the review system pushes a task message containing rejection information to the message queue or sends the task data to the medical institution's system via the service interface. The medical institution's system receives the task message by listening to the message queue or calling the service interface, thereby obtaining the medical insurance review rejection task.

[0034] It is understood that this application does not limit the specific method of task transmission. In other embodiments, medical insurance review rejection tasks can also be obtained through file transfer, email, manual import, etc., as long as task data containing rejection information can be obtained.

[0035] Obtaining medical insurance review return tasks through message queues or service interfaces enables real-time or near-real-time reception of review tasks, avoiding delays and errors caused by manual downloading or forwarding, improving the timeliness and reliability of task acquisition, and facilitating timely responses from medical institutions within the stipulated appeal period.

[0036] In some embodiments, the step "parse the return information in the medical insurance review and return task and generate a return element structure" may include the following operations: Retrieve return information from medical insurance review return tasks. The return information contains multiple fields. According to preset element categories, classify each field in the return information into the corresponding element category and generate a return element structure.

[0037] In this application, "return information" refers to the set of data carried in the medical insurance review return task, which describes the relevant circumstances of the returned item. During the medical insurance review, if the handling agency finds that a certain expense item or medical treatment is suspected of violating payment policies, it will return the item to the medical institution and request supplementary explanations, while generating a task record. All the data contained in this record constitutes the return information.

[0038] In some embodiments, the return information may be carried in the form of a task record, which includes at least one or more of the following fields: ID number, visit category, admission / discharge or visit date, department, rule name, hospital item name, medical insurance item name, medical insurance catalog code, violation content, preliminary review opinion, and document identifier.

[0039] In this application, the return element structure is a standard data container generated after structured parsing of return information. The original fields in the medical insurance review return task suffer from inconsistent naming and formatting, making them difficult to use directly for subsequent matching. By reclassifying the fields in the return information according to preset element categories, a uniformly formatted return element structure is generated, thereby masking data caliber differences between different systems.

[0040] Specifically, according to the preset element categories, each field in the returned information is classified into the corresponding element category to generate a returned element structure, which may include: parsing the diagnosis information field into diagnosis-related elements, mapping the hospitalization identifier or visit category into visit type identifier, mapping the rule name and violation content into treatment behavior elements, drug or consumable elements or test and examination elements, and mapping the fee date or settlement date into fee time point elements.

[0041] To avoid discrepancies between the names of medical insurance items and hospital items, in one embodiment, a synonym table is established for the names of medical insurance items and hospital items. The synonym table is used for normalization or alias alignment, unifying the same item with different names into a standard name before classifying it into the corresponding element category.

[0042] 202. Determine the evidence requirement information suitable for the medical insurance review return task based on the return element structure, and generate an evidence list containing at least one evidence requirement item based on the evidence requirement information.

[0043] In this application, the evidence requirement information refers to the set of types of evidence materials and their attribute requirements that need to be collected to prove the compliance of a medical insurance review rejection or the reasonable grounds for appeal.

[0044] In medical insurance reviews, different types of violations require different types of evidence to support the appeal. For example, for a return request related to "limited drug reimbursement scope," medical records (recording the patient's condition at the time of medication) and expense details (showing the occurrence of drug costs) are required as supporting materials; for a return request related to "exceeding the frequency limit," different types of evidence are required, such as test reports (showing the frequency of examinations) and doctor's orders (showing the frequency of treatments).

[0045] In some embodiments, the step "determine the evidence requirement information suitable for the medical insurance review return task based on the return element structure" may include the following operations: Based on the returned item identifier in the returned element structure, the associated mapping record is obtained from the preset multi-level mapping library. The preset multi-level mapping library includes at least a rule layer, a policy layer, and an evidence type layer. The rule layer is used to match the returned item identifier with the corresponding returned rule entry. The policy layer is used to associate the policy fragment identifier corresponding to the returned rule entry. The evidence type layer is used to define the evidence type set corresponding to the returned rule entry. Based on the evidence type set in the mapping record, the evidence requirement information is determined.

[0046] In this application, firstly, a pre-defined multi-layered mapping library is maintained, which includes at least a rule layer, a policy layer, and an evidence type layer. The rule layer stores daily review rule entries, each rule entry containing at least a rule code, a rule name pattern, an applicable medical insurance item pattern (e.g., medical insurance catalog code matching pattern), a visit type condition (e.g., inpatient or outpatient), and a corresponding policy identifier. Based on the returned item identifier in the returned element structure, the corresponding returned rule entry is matched from the rule layer to obtain a list of rule identifiers.

[0047] In one implementation, an exact match is first performed by rule name. If the match fails, a fuzzy match is performed by item name pattern. If the match still fails, a match is performed by medical insurance catalog code. The rule layer can be queried through an external rule base interface, or by querying a confirmed subset of rules by item code.

[0048] The policy layer stores policy fragment references associated with rule entries. Each policy fragment includes at least a policy number, policy name, a summary of the policy clauses, limited payment conditions, and a description of the scope of medication or treatment. The policy layer is used to associate the policy fragment identifiers corresponding to returned rule entries to determine which policy clause the rule is based on and the requirements of that policy clause regarding the type of evidence. For example, a "limited to work injury insurance" rule is associated with a work injury insurance payment policy fragment, and a "limited to emergency treatment indications" rule is associated with a summary of the corresponding drug's instruction leaflet.

[0049] The evidence type layer defines the set of evidence types required for each rule entry or "rule-item" combination. Each evidence type is configured with a standard name, data source type (such as HIS (Hospital Information System), LIS (Laboratory Information System), or electronic medical record system), structured / unstructured identifier, and cross-visit identifier. Evidence types include one or more of the following: medical records, laboratory reports, examination reports, medical orders, expense details, payment information, indication descriptions, and medical record cover sheets.

[0050] For rules that require evidence collection across multiple medical visits (e.g., comparing test results from multiple visits), the configuration at the evidence type layer also includes a cross-visit flag and associated visit selection conditions, such as the visit time range (e.g., within a preset number of days before and after the current visit) and visit type (same hospitalization, most recent outpatient visit, etc.). The mapping library can be implemented using relational configuration tables, rule packages, or ternary relations in a knowledge graph.

[0051] In one implementation, a relational configuration table is used. Each mapping record contains fields such as rule identifier, policy identifier, evidence type list, cross-treatment flag, and priority weight. This facilitates hot updates of configurations based on local medical insurance standards and adapts to differences in review rules across different regions without modifying the code. In another implementation, a knowledge graph is used. Rules, policies, and evidence types are nodes in the graph, and the relationships between them are edges. The set of evidence types associated with the current rejection rule is retrieved through graph queries.

[0052] Based on the returned item identifier in the returned element structure, the mapping record associated with the current returned item is matched from the preset multi-level mapping library; based on the evidence type set in the mapping record, the evidence requirement information is determined. Specifically, if multiple mapping records are matched (e.g., a returned item triggers multiple rules simultaneously), the evidence type sets in each mapping record are combined and deduplicated to obtain the final evidence requirement information for the current returned item. If no mapping record is matched, the rule coverage missing processing procedure is triggered, the current returned item is marked as "not covered by the rule library" and a status of "pending supplementation" (i.e., evidence to be supplemented) is output.

[0053] In this application, an evidence requirement item refers to the smallest unit in the evidence list, used to describe the specifications that a specific piece of evidence should meet. It must at least include an evidence type identifier and can also be configured with attributes such as mandatory / optional identifiers, time constraints, and cross-treatment constraints. The evidence list is a collection of one or more evidence requirement items, used to fully describe the specifications of all evidence materials required for a specific medical insurance review rejection. The evidence list is generated before retrieving evidence from medical data sources, giving subsequent retrieval and collection work a clear objective and measurable completion standards.

[0054] In some embodiments, the step "generating an evidence list containing at least one evidence requirement item based on evidence requirement information" may include the following operations: For each evidence type in the evidence type set, generate a corresponding evidence requirement item and configure constraints for each evidence requirement item; combine the evidence requirement items to generate an evidence list.

[0055] First, obtain the set of evidence types included in the evidence requirement information. The set of evidence types comes from the evidence type layer in the mapping record. For each evidence type in the set of evidence types, generate a corresponding evidence requirement item.

[0056] Then, constraints are configured for each evidence requirement item. These constraints include at least one of the following: Mandatory / Optional Identifier: Missing a mandatory item will result in additional documentation being required; optional items only affect overall completeness and do not affect the appeal decision; Priority Weight: Reflects the degree of influence of the evidence item on the appeal conclusion and is used for weighted completeness calculation; Time Limitation Constraint: Limits the effective time range of the evidence, such as the date of the test report must be within a specific time window before and after the date of the violation fee; Cross-Medical Treatment Constraint: Indicates whether it is necessary to link previous medical records, used in appeal scenarios that require longitudinal comparison, such as relying on historical medication indications; Document Name Matching Pattern: Matches the corresponding document type, such as "Medication Record" matching variant names like "First Medical Record"; Keyword Hints: Locates key content in the document, such as "Medication Indications" or "Emergency Record" in the medical record. Finally, the evidence requirements items are combined to obtain the evidence list.

[0057] In one implementation, the list generation module compiles the evidence collection configuration corresponding to each rule into an evidence list, ensuring consistency between the required items and the subsequent attachment collection logic. The evidence lists required for different rules differ in evidence types and constraints: for example, the "limited to drug payment scope" rule requires medical records (mandatory, with time constraints), cost details (mandatory), medical orders (mandatory), and laboratory reports (optional); while the "exceeding the limit on treatment frequency" rule requires laboratory reports (mandatory, with time constraints), medical orders (mandatory), and medical records (optional). In some embodiments, the evidence list is generated before retrieving evidence data from the medical data source. Generating the evidence list before subsequent evidence retrieval from the medical data source predetermines the collection targets for supplementary evidence, rather than retrospectively inferring missing items from already extracted attachments.

[0058] 203. Based on the evidence requirement items in the evidence list, retrieve the evidence data corresponding to the evidence requirement items from the medical data source and bind them to obtain the evidence binding record.

[0059] In this application, medical data sources refer to various information systems that store business data of medical institutions, serving as the source of evidentiary data. These include, but are not limited to: Hospital Information Systems (HIS), which store information such as expense details, medical orders, and registration records; Laboratory Information Systems (LIS), which store information such as test requests and results; Electronic Medical Record Systems (EMR), which store medical records such as progress notes and case summaries; Picture Archiving and Communication Systems (PACS), which store image reports and image files; and billing systems, which store billing documents and payment records. Evidence data refers to the specific data records or document content retrieved from medical data sources that match the required evidence items. The required evidence items are a specification (abstract, pre-defined) of "what evidence is needed," while evidence data is the specific record retrieved from the data source (concrete, instantiated). The multi-source retrieval and binding module matches and binds the required evidence items with evidence data instances, generating evidence binding records for subsequent completeness assessment.

[0060] In some embodiments, the step "retrieving evidence data corresponding to the evidence requirement items from the medical data source based on the evidence requirement items in the evidence list and binding them to obtain evidence binding records" may include the following operations: For each evidence requirement item in the evidence list, determine the evidence type corresponding to the evidence requirement item; determine the corresponding retrieval strategy based on the evidence type; retrieve evidence data matching the evidence requirement item from at least one medical data source according to the retrieval strategy, establish a binding relationship between the retrieved evidence data and the corresponding evidence requirement item, and generate an evidence binding record.

[0061] First, for each evidence requirement item in the evidence list, determine the corresponding evidence type. Evidence types include two main categories: structured data (such as test results, cost details, and medical records) and unstructured data (such as medical records, discharge summaries, and medical record cover sheets). Different evidence types correspond to different retrieval strategies.

[0062] Different strategies are used for evidence retrieval based on different data types: For structured data (such as expense details), precise matching is performed from medical data sources by code, name, and time window. Successful matches are used as candidate evidence, and the record ID is taken from the business primary key (such as expense detail ID); For unstructured data (such as documents), the file pool is first filtered by document name pattern (such as "medical record" and "discharge summary"), and then the target content is located by keywords (such as locating the "rescue record" paragraph in the medical record), or screenshot markers are generated as the location basis.

[0063] In one implementation, for evidence requirements with cross-visit constraints, related visits are first selected from the visit list (e.g., all visits within a preset number of days before and after the current visit), and then the target documents or structured data are merged to ensure that the search scope covers all related visit records.

[0064] In one implementation, before the search, a list of diagnoses, costs, tests, examinations, medical orders, and medical records from various medical data sources is aggregated according to patient identification and consultation time window, forming an aggregated data view centered on the current patient and current consultation. Then, various searches are performed within this view. During the search, electronic documents can be retrieved for format parsing or text recognition. After the search is completed, the retrieved evidence data is bound to the corresponding evidence requirement items, generating evidence binding records.

[0065] In one implementation, the evidence binding record includes at least the following fields: evidence requirement item identifier (indicating which requirement in the evidence list the binding record corresponds to), evidence type (indicating what type of evidence it is), source system type (indicating that the evidence data comes from HIS, LIS, or electronic medical record system, etc.), original record identifier (a unique identifier of the evidence data in the source system, such as expense detail ID or test report ID), and original text or fragment summary (a summary of the key content of the evidence data).

[0066] In one implementation, the evidence binding record also includes a binding confidence score. The binding confidence score measures the accuracy of the match between the retrieved evidence data and the evidence requirement. The binding confidence score can be determined based on the matching method: the binding confidence score for exact coded matching is higher than that for fuzzy name matching; consistency across different visit times increases the binding confidence score. The binding confidence score is used in subsequent completeness calculations to measure the degree to which each evidence requirement is met; a higher confidence score indicates a more accurate match between the retrieved evidence and the requirement.

[0067] The rules for determining the binding confidence level are as follows: The highest confidence level is for exact code matching. When the code of the evidence data (such as the medical insurance catalog code) is completely consistent with the code specified in the evidence requirement item, a high confidence level (e.g., 1.0) is assigned; the next highest confidence level is for fuzzy name matching. When the code cannot be exactly matched, name similarity or alias alignment is used for matching, assigning a medium confidence level (e.g., 0.6); the confidence level is increased when the comparison across different visit times is consistent. If the evidence requirement item contains cross-visit constraints, and the time information of the retrieved evidence data is consistent with the constraint conditions, a confidence bonus is added to the aforementioned confidence level (e.g., an increase of 0.2), but not exceeding the maximum value (e.g., 1.0).

[0068] In some embodiments, the original confidence score, calculated by combining the above factors, can be mapped to a range of 0 to 1 to obtain a normalized binding confidence score. The binding confidence score, as a field in the evidence binding record, is used for subsequent calculations of individual satisfaction: when the binding confidence score reaches a preset threshold, the evidence requirement is considered satisfied; if it does not reach the threshold, it is considered partially satisfied, and the individual satisfaction score is the ratio of the binding confidence score to the threshold. A higher confidence score indicates that the retrieved evidence is more likely to be the actual evidence needed for the current return request.

[0069] In some embodiments, the binding result can be converted into an evidence chain display table and associated with an attachment identifier for subsequent manual verification.

[0070] 204. Based on the matching results between the evidence list and the evidence binding records, generate the evidence completeness determination result of the evidence list, and output the appeal suggestion result based on the evidence completeness determination result.

[0071] In this application, the matching results reflect the correspondence between each requirement item in the evidence list and the search data (match / partial match / no match), representing the degree to which the current materials meet the requirements; the completeness determination is based on this comprehensive evaluation to draw an overall conclusion.

[0072] In some embodiments, the step "generating a completeness determination result for the evidence list based on the matching result between the evidence list and the evidence binding record" may include the following operations: Based on the evidence binding records, determine the individual satisfaction level of each evidence requirement item in the evidence list; based on the individual satisfaction level of each evidence requirement item and the preset priority weight, aggregate the individual satisfaction level of each evidence requirement item to obtain the comprehensive completeness of the evidence list; based on the comprehensive completeness, determine the evidence completeness judgment result of the evidence list.

[0073] The individual satisfaction level refers to the quantitative assessment of the degree to which each evidence requirement in the evidence list is satisfied, based on its matching with the evidence binding record. Each evidence requirement corresponds to an individual satisfaction level, ranging from 0 to 1, reflecting the current level of satisfaction of that evidence requirement: 1 represents complete satisfaction, and 0 represents complete non-satisfaction.

[0074] In some embodiments, the step "determining the individual satisfaction level of each evidence requirement item in the evidence list based on the evidence binding record" may include the following operations: For each evidence requirement item in the evidence list, retrieve the evidence binding record that matches the evidence requirement item and obtain the binding confidence level. If a matching evidence binding record exists and the corresponding binding confidence level reaches a preset confidence threshold, then assign the single-item satisfaction level of the evidence requirement item to the first value. If a matching evidence binding record exists but the corresponding binding confidence level does not reach the preset confidence threshold, then assign the single-item satisfaction level of the evidence requirement item to the ratio of the binding confidence level to the preset confidence threshold. If no matching evidence binding record exists, then assign the single-item satisfaction level of the evidence requirement item to the second value.

[0075] The first value can be 1, indicating that the evidence requirement has been fully met; the second value can be 0, indicating that the evidence requirement has not been met at all. For example, for the i-th evidence requirement r in the evidence list L... i Single item satisfaction degree s i The determination rule is as follows: Completely satisfies: If there exists a value with r... i The corresponding evidence is bound to record b, and the bound confidence level is c. i Reaching the preset threshold τ (i.e., c) i ≥τ), then s i =1. This indicates that the required evidence is fully supported by high-quality evidence data; partially satisfied: if there exists a value related to r i The corresponding candidate binding record, but the binding confidence level c i The preset threshold τ (i.e., c) has not been reached. i <τ), then s i =c i / τ. This indicates that although there is relevant evidence data, the matching accuracy is insufficient, and the satisfaction level is calculated proportionally to the confidence level and the threshold. For example, τ=0.8, c i =0.6, then s i =0.6 / 0.8=0.75; Not satisfied at all: if there is no value with r i If any corresponding evidence is linked to a record, then s i =0. This indicates that the required evidence is completely unsupported.

[0076] In some embodiments, the evidence list includes a mandatory subset of evidence and an optional subset of evidence; the step "aggregating and calculating the individual satisfaction of each evidence requirement item based on its individual satisfaction and preset priority weight to obtain the overall completeness of the evidence list" may include the following operations: The completeness of the mandatory evidence layer is calculated based on the individual satisfaction of each evidence requirement item within the mandatory evidence subset and the preset priority weight; the completeness of the optional evidence layer is calculated based on the individual satisfaction of each evidence requirement item within the optional evidence subset and the preset priority weight; and the overall completeness of the evidence list is calculated based on the completeness of the mandatory evidence layer, the completeness of the optional evidence layer, the first weight coefficient corresponding to the mandatory evidence subset, and the second weight coefficient corresponding to the optional evidence subset.

[0077] The mandatory evidence subset consists of the evidence items marked "mandatory" in the evidence list, which are the core materials that must be provided during the appeal process and are indispensable. The optional evidence subset consists of the evidence items marked "optional" in the evidence list, used to enhance the persuasiveness of the appeal. The mandatory layer completeness measures the overall degree to which all mandatory evidence items in the evidence list are met. In some embodiments, the mandatory layer completeness can be calculated based on the following formula: In Formula 1, This refers to the i-th evidence requirement item r within the mandatory evidence subset. i The degree of satisfaction of each item; For evidence requirement item r i The corresponding priority weights (the priority weight of the evidence requirement item within the mandatory evidence subset is ≥1 by default; the larger the weight value, the greater the impact of the evidence on the appeal conclusion). This is a mandatory subset of evidence. That is, the completeness of the required layers is calculated.

[0078] According to Formula 1 above, if and only if the individual satisfaction level of each evidence requirement item in the mandatory evidence subset is... When all values ​​are 1, it means that the binding confidence level of each required piece of evidence is not lower than the threshold. Equals 1. The degree of satisfaction of any one of the required pieces of evidence. Less than 1 (including partially satisfied or not satisfied at all). That is, less than 1.

[0079] In this application, the criterion for determining the completeness of the mandatory layer comes from the rule layer, rather than from a subjective assessment of existing materials—that is, the rules are first used to deduce "which mandatory evidence is needed," and then the criterion is determined based on the actual retrieved evidence data to see if all mandatory evidence meets the requirements, rather than first looking at "what existing materials are available" and then judging "whether they are sufficient." The completeness of the optional layer is used to measure the overall degree of satisfaction of all optional evidence requirements in the evidence list. In some embodiments, the calculation of the completeness of the optional layer can be based on the following formula: In Formula 2, This refers to the i-th evidence requirement item r within the optional subset of evidence. i The degree of satisfaction of each item; For evidence requirement item r i The corresponding priority weights; For optional subset of evidence (if) If empty, then =1); That is, the calculated completeness of the optional layers.

[0080] The overall completeness is a comprehensive quantitative assessment of the degree to which the evidence list is satisfied, and is obtained by weighted aggregation of the completeness of the mandatory layer and the completeness of the optional layer. In some embodiments, the calculation of the overall completeness can be based on the following formula three: in, The first weighting coefficient; This is the second weighting coefficient; ; This is the calculated overall completeness. In one embodiment, we take... =0.85、 =0.15, with essential evidence as the primary factor.

[0081] In this application, the suggested outcome of the appeal can include one of the following: "Needs Supplementary Evidence," "Unappealable," or "Appealable." "Needs Supplementary Evidence" means that a definitive appeal conclusion cannot be reached at present, and further supplementary materials or human intervention are required. "Unappealable" means that the required evidence layer has been fully met, but the rule layer determines that an appeal is not supported. "Appealable" means that the required evidence layer has been fully met, and the rule layer determines that an appeal is supported. For example, see Table 1 below: Table 1 Table 1 provides the logic for determining the appeal suggestion status. After completing the evidence completeness assessment, it is based on the completeness of the mandatory layer. Based on the rule-based judgment results, the corresponding appeal suggestion status is output. There are three suggestion statuses: "Needs Supplementation," "Unappealable," and "Appealable." "Needs Supplementation" indicates that a final appeal conclusion cannot be reached at present, and supplementary data, supplementary documents, or re-analysis are required. This status is triggered under the following circumstances: task analysis fails; patient or visit master data is missing; mandatory evidence layer is not fully satisfied (i.e., ...). <1) There are unmet required evidence items; key data sources are unavailable; or the binding confidence level is below a preset threshold. In one implementation, when outputting supplementary materials, the system simultaneously returns a list of missing items, specifying the unmet evidence requirements and the suggested data source types for supplementation. "Unappealable" indicates that an appeal is not recommended based on the existing materials. This status is fully satisfied at the required evidence level (i.e., ...). =1) Triggered when the rules or policies determine that an appeal is not supported, and also includes situations where policies exclude the space for appeal. In one implementation, when an "unappealable" output is displayed, the system also outputs a brief explanation of the rule-level determination that it is not supported, so that the person in charge can understand the reason. "Appealable" indicates that the required evidence is complete, and the rules or policies determine that there is grounds for appeal that can be submitted. This state is fully satisfied at the required evidence level (i.e. =1) Triggered when the business rules indicate a positive tendency to appeal. Outputting "Appealable" indicates that the current evidence meets the requirements of the rule layer and can be submitted for appeal after manual confirmation.

[0082] It should be noted that all three suggested states are submitted only after final manual confirmation; the system does not automatically submit appeals. In the "Pending Supplementation" state, the responsible personnel can resubmit for judgment after supplementing the materials according to the missing items list. In the "Appealable" and "Unappealable" states, the responsible personnel will confirm and submit an appeal or abandon the appeal according to the system prompts.

[0083] In some embodiments, the step "output appeal suggestion result based on the evidence completeness determination result" may include the following operations: Obtain the rule-level judgment result corresponding to the medical insurance review rejection task; if the evidence completeness judgment result indicates that the preset completeness conditions are not met, output the evidence to be supplemented; if the evidence completeness judgment result indicates that the preset completeness conditions are met, and the rule-level judgment result indicates that the appeal is not supported, output that the appeal is not allowed; if the evidence completeness judgment result indicates that the preset completeness conditions are met, and the rule-level judgment result indicates that the appeal is supported, output that the appeal is allowed.

[0084] Among them, the preset completeness condition is the completeness of the required layer. =1 indicates that every evidence requirement in the mandatory evidence subset has been fully satisfied. If the score is less than 1, it indicates that at least one required piece of evidence is not met. In this case, supplementary evidence will be output directly, and the rule-based appeal tendency assessment will not take effect. If the evidence completeness assessment result indicates that the preset completeness conditions are met (i.e., ... =1), and the rule-level judgment result is that appeal is not supported, output "no appeal". If the evidence completeness judgment result indicates that the preset completeness condition is met (i.e., =1), and the rule layer judgment result is that appeal is supported, so the output is "appeal is allowed". It should be noted that the above judgment branches are executed in order of priority: first check whether there are any anomalies (task analysis failure or missing master data) and whether the required evidence layer is fully satisfied ( =1), only when The appeal tendency determination at the rule or strategy level only takes effect after =1 is established. When the value is less than 1, regardless of the value of the "whether to appeal" flag in the rule layer (support or not support), the second branch will be executed first to output the evidence to be supplemented.

[0085] In one implementation, if =1 But if the rules or strategy layer cannot provide a definite appeal tendency (e.g., the rule base does not cover the current return item type or the judgment logic returns an anomaly), then the supplementary evidence will also be output, and the missing information or the information that the rule coverage is missing or the rule needs to be manually supplemented will be marked in the missing item description.

[0086] In one implementation, the rule-layer determination result is output in a binary form of "whether to appeal," where "yes" corresponds to supporting the appeal and "no" corresponds to not supporting the appeal. In another implementation, the rule-layer determination result can also be output in the form of confidence level, score, or grade, and the support or non-support of the appeal is determined by comparing it with a preset threshold. This application does not limit the scope of this implementation.

[0087] All three suggested statuses (Pending Supplementary Evidence, No Appeal, Appealable) require final manual confirmation before submission; the system does not automatically submit an appeal. In the "Pending Supplementary Evidence" status, the responsible personnel can supplement the materials according to the missing items list output by the system and resubmit for judgment. In the "No Appeal" and "Appealable" statuses, the responsible personnel should confirm whether to waive the appeal or submit an appeal according to the system prompts.

[0088] In one implementation, when outputting evidence to be supplemented, the system also lists the individual satisfaction levels. =0 or The system provides a list of missing items (<1) and suggested data source types for supplementation (e.g., "Medical records are missing; it is recommended to retrieve them from the electronic medical record system"), enabling administrators to accurately collect the necessary materials based on the list and avoid blind searching. When the system outputs "not appealable" or "appealable," it also provides a brief explanation of the rule-based judgment, allowing administrators to understand the basis for the decision.

[0089] In one implementation, the rule-level judgment result can be output in the form of an "appeal status" flag. A successful task with a true flag indicates an appeal is possible, while a false flag indicates no appeal is possible. A failed task indicates a need for supplementary materials, with the exception type recorded in the missing item description. The judgment result is written into the task output structure, carrying fields such as suggestion status, completeness, missing item list, rule-level appeal tendency, and attachment generation flag. The responsible personnel process the output accordingly: appealable items are confirmed and submitted; items requiring supplementary materials are reprocessed after submission; and non-appealable items are archived.

[0090] In one implementation, the system also provides a rule-based pre-reasoning module and an attachment generation module. The rule-based pre-reasoning module is a functional unit in the system responsible for making a deterministic determination of the appeal tendency of the current returned matter based on structured rules before invoking the large language model. The attachment generation module is a functional unit in the system responsible for retrieving corresponding evidence data from various medical data sources according to the evidence list and generating attachment files.

[0091] Specifically, the rule-pre-reasoning module can provide a definitive conclusion before calling the large language model, influencing the tendency to "appeal," but it does not replace the completeness of the mandatory layer. The constraint on the completeness of materials, as long as <1, always output "Required Documents". The attachment generation module pulls documents from the evidence list and generates screenshots. When the required document type evidence is not met and the attachments are empty, it is recommended to set the status to "Required Documents".

[0092] Among them, overall completeness Completeness of optional layers It does not participate in the decision-making gate of the three-state proposal state, but is output as an auxiliary display indicator along with the proposal state: Reflects the overall degree of satisfaction of both mandatory and optional evidence. The satisfaction of optional evidence is presented separately. In one embodiment, It can be used for priority sorting of similar returned work orders. (Higher priority processing) The staff may be advised to supplement the case with additional optional materials to enhance the persuasiveness of the appeal; neither suggestion changes the overall stance.

[0093] This application discloses a method for evidence matching and completeness assessment in medical insurance review. The method includes: obtaining medical insurance review return tasks and parsing them to generate a return element structure; determining evidence requirement information based on the return element structure and generating an evidence list; retrieving and binding corresponding evidence data from medical data sources based on the evidence list to obtain evidence binding records; generating an evidence completeness judgment result based on the matching result between the evidence list and the evidence binding records, and outputting appeal suggestions for supplementary evidence, non-appealable, or appealable evidence. This achieves a structured judgment of evidence completeness and improves the systematization level and processing efficiency of appeal material preparation.

[0094] This application applies to the material preparation stage after the medical insurance daily review has been returned and before the formal appeal. The core deliverables are a list of evidence, a completeness assessment result, and three suggested statuses (requiring supplementary documents / not appealable / appealable). The focus is on the completeness assessment, not on generating a full appeal document. The main application scenarios are as follows: Daily Medical Insurance Review and Handling for Designated Medical Institutions: The system generates batches of evidence requirements and missing item explanations for lists returned by the handling agency, sorting work orders into three states: those requiring supplementary materials, those eligible for appeal (submitted after confirmation), and those not eligible for appeal (archived). Quality Control Before Appeal Material Submission: Serving as an internal completeness gate, if mandatory evidence is incomplete, the system remains in the "required supplementary materials" state; only when all necessary evidence is complete and permitted by rules does it enter the appeal stage, preventing rejection due to incomplete materials. Cross-Patient and Multi-Source Data Returns: For returned items requiring association with multiple patient visits or various documents, the system outputs a cross-patient evidence list and calculates completeness within the same task, eliminating the need for manual association of multiple medical records. System Embedding: The system integrates independently with the existing review and appeal pipeline, loosely coupling with various hospital business systems. It can be deployed as a whole or only as a completeness determination submodule. Multiple Deployment Methods: Tasks from multiple institutions can be uniformly sorted into three states and deployed on the hospital intranet, dedicated cloud, or storage media. The system output does not replace the final review decision of the medical insurance handling agency.

[0095] The following uses the scenario of "return of drugs for limited indications" to fully illustrate the input, output and collaborative process of each step in this application.

[0096] Input task package: A daily review return task contains the following fields: the rule name is "Drugs for patients with specific indications are restricted", the medical insurance item name is a certain injectable biological agent, the hospital item name and the medical insurance item name have different aliases, the violation content field is marked "patients do not meet the payment conditions for the restricted indications", the treatment category is inpatient, and the expense date is during the current hospitalization period.

[0097] Returned Element Structured Parsing: The element parsing module extracts the returned element structure E from the above task package: the drug element identifier corresponds to the injectable biological agent specification; the treatment behavior dimension is marked as "limited to indication payment"; the disease element is parsed from the diagnosis summary field; the hospitalization identifier is set to hospitalization; the expense time point element is the expense occurrence date. The hospital project name and the medical insurance project name are normalized through a synonym table to eliminate naming differences.

[0098] Multi-layer mapping library matching: The rule name pattern in the returned element structure E and the medical insurance item pattern are searched in the rule layer of the mapping library M, and the rule entry "limited indication drug - hospitalization" is matched; the policy layer associates the rule entry and returns the indication paragraph identifier of the corresponding drug instruction manual and the paragraph identifier of the local medical insurance reimbursement details; the evidence type layer determines the set of evidence types required for this returned item and generates a mapping record R, which stipulates that: medical records, diagnostic certificates, relevant test or examination reports and medical order details are mandatory types, and indication description documents are optional types.

[0099] Evidence list generation: The list generation module outputs evidence list L based on the mapping record R, which consists of five items, as shown in Table 2 below: Table 2 Required subset Optional subset Sum of weights .

[0100] Multi-source retrieval and evidence fragment binding: The multi-source retrieval module retrieves relevant data from the electronic medical record system, laboratory system, and billing system based on patient identification and visit time window. Inpatient progress notes were filtered from the electronic medical record pool by document name pattern, with keywords matching indication-related phrases, and confidence levels were assigned. ( ), . Extract the discharge primary diagnosis directly from the fields on the medical record's homepage, and perform precise code matching. , . In the testing system, there were no test or examination reports related to this indication within 90 days prior to the date the expense was incurred, and there were no associated records. . The system accurately matches medical orders with drug specifications from the expense details system. , . The document pool contains no informed consent documents related to the indication. .

[0101] Completeness calculation and proposal output: Calculate the completeness of the required layer. : ,because <1, triggers the supplementary component suggestion state.

[0102] Missing item description: Required (Indication-related test or examination reports) not linked ( =0), it is recommended to supplement the relevant test data within the past 90 days into the testing system, or to supplement the test report documents; optional Not bound, does not affect the current suggested state but can be further improved.

[0103] The output result is written to the daily review work order: suggestion status = pending supplementary documents. ≈0.833, Missing Items List = [ The suggested missing documents are: [Search path and document name pattern]. After the responsible personnel supplement the missing data according to the missing information, the processing flow can be restarted; if the supplemented data is not found... Binding successful ( =1), When upgraded to level 1, the suggestion will be determined by the rule layer and output whether it is appealable or not.

[0104] Based on the above description, the following examples will further illustrate the evidence matching and completeness assessment methods for the medical insurance review of this application. Please refer to... Figure 3 , Figure 3 This is a flowchart illustrating another method for evidence matching and completeness assessment in medical insurance review provided in this application embodiment.

[0105] like Figure 3 As shown, the return task package issued by the medical insurance management system is transmitted to the supplementary evidence matching and completeness judgment system through the hospital's medical insurance system, forming a daily review return task package as the data input end of the entire method.

[0106] S1 Return Element Structured Parsing: The element parsing step parses the return information in the task package, classifies the original fields according to the preset element categories, and outputs the return element structure E, which includes standardized attributes such as drug or consumable elements, treatment behavior elements, disease elements, inpatient / outpatient identification, and cost time point elements.

[0107] S2 Multi-layer Mapping Library Matching: The mapping library matching step extracts the returned item identifier from E, retrieves the corresponding returned rule entry in the multi-layer mapping library M, associates the policy fragment identifier through the policy layer, determines the required set of evidence types through the evidence type layer, and outputs the mapping record R.

[0108] S3 Evidence List Generation: The list generation step converts the set of evidence types in R into evidence requirement items one by one, configures attributes such as mandatory / optional identifiers and time constraints for each item, and outputs the evidence list L. The evidence list is generated before the retrieval, so that the collection target is predetermined.

[0109] S4 Multi-Source Retrieval and Evidence Binding: The retrieval and binding steps retrieve corresponding evidence data from various business systems of the hospital according to each requirement in the evidence list L, establish a binding relationship between the retrieved data and the requirement item, calculate the binding confidence, and output the binding set B.

[0110] S5 Completeness Calculation and Recommendation Output: The completeness calculation step calculates the individual satisfaction level of each evidence requirement item based on L and B, then aggregates and calculates the required layer completeness Cmand and the overall completeness C, outputting the evidence completeness judgment result. The recommendation output step outputs a three-state judgment (requiring supplementary evidence, not appealable, or appealable) and appeal suggestions based on the completeness judgment result and the rule layer judgment result.

[0111] The results are either transmitted back to the medical insurance management system via the hospital's medical insurance system or placed in the local work order queue for processing by the responsible personnel. For items requiring supplementary documents, the responsible personnel will re-trigger the process after supplementing the materials according to the missing item list. For items eligible for appeal, an appeal will be submitted; for items not eligible for appeal, the case will be archived and closed.

[0112] This embodiment shows that the supplementary matching and completeness determination system is integrated into the existing review appeal process as an independent processing stage. Completeness determination is performed before the daily review return task enters the formal appeal, realizing automatic sorting and processing of work orders in the scenario of batch daily review.

[0113] For further details, please refer to Figure 4 , Figure 4 This is a schematic diagram illustrating the generation of the multi-layer mapping library and evidence list provided in the embodiments of this application.

[0114] like Figure 4 As shown, the return element structure E first enters the rule layer. The rule layer matches the corresponding return rule entries based on the rule name and medical insurance item name in E to obtain the rule identifier.

[0115] After the rule-level matching is completed, it is associated with the policy layer based on the rule identifier. The policy layer returns the policy segment identifier corresponding to the rule, such as the indication section identifier in the drug instruction manual, or the section identifier in the local medical insurance reimbursement rules.

[0116] Subsequently, the rule layer and policy layer work together on the evidence type layer. Based on the rule identifier and policy fragment identifier, the evidence type layer retrieves the set of evidence types corresponding to the rule. Each evidence type is configured with mandatory / optional attributes, priority weights, and time constraints.

[0117] Finally, the evidence type layer outputs an evidence list L. Each evidence requirement in the evidence list L is derived from an evidence type and is divided into two categories: mandatory and optional. Mandatory items are the core materials that must be present in the appeal and cannot be missing; optional items are supplementary materials used to enhance the persuasiveness of the appeal.

[0118] For example, regarding the "limited indication drugs" rule, the evidence type layer returns the following set of evidence types: medical records (mandatory, weight 2, covering ±7 days from the date of expense incurrence), diagnostic certificates (mandatory, weight 2, for the current hospitalization), laboratory reports (mandatory, weight 1, within 90 days prior to the date of expense incurrence), detailed medical orders (mandatory, weight 1, for the current hospitalization), and indication description documents (optional, weight 1, for the current hospitalization). The list generation step converts each of the above evidence types into evidence requirement items and then combines them into evidence list L.

[0119] This embodiment demonstrates that by matching and associating the rules, policies, and evidence types layer by layer, a structured derivation from the original returned items to specific evidence requirements is achieved, making the determination of evidence requirements independent of human experience judgment. The relationships between the layers can be implemented through configuration tables, supporting hot updates of local medical insurance standards.

[0120] For further details, please refer to Figure 5 , Figure 5This is a flowchart illustrating the completeness calculation and appeal suggestion determination process provided for embodiments of this application.

[0121] like Figure 5 As shown, the steps for calculating the completeness of the binding set B and the evidence list L are input together.

[0122] First, for each evidence requirement in the evidence list L, based on whether a corresponding binding record exists in the binding set B and whether the binding confidence level reaches a preset confidence threshold, calculate the individual satisfaction level s of each evidence requirement item. i .

[0123] Secondly, they are aggregated into the completeness of the required layers. Combined with the optional layer completeness Copt, then according to the formula Calculate the overall completeness .

[0124] Then, proceed to the decision node and check in order of priority: If the task analysis fails, output the missing parts directly.

[0125] If the task analysis is successful and <1, Output the missing parts, and list the missing items and the suggested data source types to be added.

[0126] like =1 and the rule layer determines that appeal is not supported, output "no appeal"; if If =1 and the rule layer determines that appeal is supported, output "appeal is possible"; if =1, but the rule layer cannot provide a deterministic tendency, outputs the missing part, and marks the rule coverage as missing.

[0127] Taking "return of drugs for limited indications" as an example, if the medical record, diagnosis certificate, and doctor's order details are all met, but the test report is not found, then Cmand=5 / 6<1, and the output "to be supplemented" is displayed, with the test report as the missing item list. If the test report is supplemented and meets the requirements, Cmand rises to 1, and the process enters the rule-level decision branch, outputting whether it is appealable or not based on whether the rule level supports appeal.

[0128] This embodiment shows that, As a necessary prerequisite for determining the recommended status, the system first checks whether the evidence is complete, and then checks whether the rules support it; these two processes are handled in layers. Missing items are located precisely at the list item level, providing an actionable path for supplementary documentation guidance.

[0129] To facilitate better implementation of the evidence matching and completeness assessment method for medical insurance review provided in this application, this application also provides an evidence matching and completeness assessment device for medical insurance review based on the aforementioned evidence matching and completeness assessment method. The meanings of the terms used are the same as in the aforementioned evidence matching and completeness assessment method for medical insurance review, and specific implementation details can be found in the descriptions in the method embodiments.

[0130] Please see Figure 6 , Figure 6 A structural block diagram of an evidence matching and completeness assessment device for medical insurance review provided in this application embodiment, the device comprising: The acquisition unit 301 is used to acquire medical insurance review return tasks, parse the return information in the medical insurance review return tasks, and generate a return element structure; the generation unit 302 is used to determine the evidence requirement information that matches the medical insurance review return task based on the return element structure, and generate an evidence list containing at least one evidence requirement item based on the evidence requirement information; the retrieval unit 303 is used to retrieve the evidence data corresponding to the evidence requirement item from the medical data source based on the evidence requirement item in the evidence list and bind it to obtain an evidence binding record; the output unit 304 is used to generate an evidence completeness judgment result of the evidence list based on the matching result of the evidence list and the evidence binding record, and output an appeal suggestion result based on the evidence completeness judgment result. The appeal suggestion result includes one of the following: evidence to be supplemented, no appeal, and appealable.

[0131] In some embodiments, the output unit 304 may include: a first determining subunit, configured to determine the individual satisfaction level of each evidence requirement item in the evidence list based on the evidence binding record; a first calculating subunit, configured to aggregate and calculate the individual satisfaction level of each evidence requirement item according to the individual satisfaction level and preset priority weight, to obtain the comprehensive completeness of the evidence list; and a second determining subunit, configured to determine the evidence completeness judgment result of the evidence list based on the comprehensive completeness. In some embodiments, the evidence list includes a mandatory evidence subset and an optional evidence subset; the first calculating subunit may specifically be configured to: calculate the mandatory layer completeness based on the individual satisfaction level and preset priority weight of each evidence requirement item in the mandatory evidence subset; calculate the optional layer completeness based on the individual satisfaction level and preset priority weight of each evidence requirement item in the optional evidence subset; and calculate the comprehensive completeness of the evidence list based on the mandatory layer completeness, the optional layer completeness, the first weight coefficient corresponding to the mandatory evidence subset, and the second weight coefficient corresponding to the optional evidence subset.

[0132] In some embodiments, the first determining subunit may be specifically used to: for each evidence requirement item in the evidence list, retrieve evidence binding records that match the evidence requirement item and obtain binding confidence; if there is a matching evidence binding record and the corresponding binding confidence reaches a preset confidence threshold, then assign a first value to the individual satisfaction of the evidence requirement item; if there is a matching evidence binding record and the corresponding binding confidence does not reach the preset confidence threshold, then assign the individual satisfaction of the evidence requirement item to the ratio of binding confidence to the preset confidence threshold; if there is no evidence binding record that matches the evidence requirement item, then assign a second value to the individual satisfaction of the evidence requirement item.

[0133] In some embodiments, the output unit 304 may include: a first acquisition subunit, configured to acquire the rule-level judgment result corresponding to the medical insurance review return task; a first output subunit, configured to output supplementary evidence if the evidence completeness judgment result indicates that the preset completeness condition is not met; a second output subunit, configured to output no appeal if the evidence completeness judgment result indicates that the preset completeness condition is met and the rule-level judgment result indicates that the appeal is not supported; and a third output subunit, configured to output appealable if the evidence completeness judgment result indicates that the preset completeness condition is met and the rule-level judgment result indicates that the appeal is supported.

[0134] In some embodiments, the generation unit 302 may include: a matching unit, configured to match associated mapping records from a preset multi-layer mapping library based on the returned item identifier in the returned element structure, wherein the preset multi-layer mapping library includes at least a rule layer, a policy layer, and an evidence type layer; wherein the rule layer is used to match the returned item identifier with the corresponding returned rule entry, the policy layer is used to associate the policy fragment identifier corresponding to the returned rule entry, and the evidence type layer is used to define the evidence type set corresponding to the returned rule entry; and a second determining subunit, configured to determine evidence requirement information based on the evidence type set in the mapping record.

[0135] In some embodiments, the generation unit 302 may include: a first generation subunit, configured to generate corresponding evidence requirement items for each evidence type in the evidence type set, and configure constraints for each evidence requirement item, the constraints including at least one of the following: mandatory / optional identifier, time limit constraint, cross-visit constraint; and a second generation subunit, configured to generate an evidence list by combining the evidence requirement items.

[0136] In some embodiments, the retrieval unit 303 may include: a third determining subunit, configured to determine the evidence type corresponding to each evidence requirement item in the evidence list; a fourth determining subunit, configured to determine the corresponding retrieval strategy based on the evidence type; and a third generating subunit, configured to retrieve evidence data matching the evidence requirement item from at least one medical data source according to the retrieval strategy, establish a binding relationship between the retrieved evidence data and the corresponding evidence requirement item, and generate an evidence binding record.

[0137] In some embodiments, the acquisition unit 301 may include: a second acquisition subunit, used to acquire return information in the medical insurance review return task, the return information containing multiple fields; and a classification subunit, used to classify each field in the return information into the corresponding element category according to a preset element category, and generate a return element structure; wherein the return element structure is configured with at least one of the following element categories: diagnosis-related elements, treatment behavior elements, drug or consumable elements, laboratory test elements, visit type identifier, and cost time point elements.

[0138] Accordingly, embodiments of this application also provide an electronic device. For example... Figure 7 As shown, Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device 400 includes a processor 401 with one or more processing cores, a memory 402 with one or more computer-readable storage media, and a computer program stored in the memory 402 and executable on the processor. The processor 401 and the memory 402 are electrically connected. Those skilled in the art will understand that... Figure 7 The electronic device structures shown herein do not constitute a limitation on electronic devices and may include, but are not limited to, those shown. Figure 7 It can show more or fewer parts, or combine certain parts, or arrange different parts.

[0139] The processor 401 is the control center of the electronic device 400. It connects various parts of the electronic device 400 through various interfaces and lines. By running or loading software programs and / or modules stored in the memory 402, and calling data stored in the memory 402, it performs various functions of the electronic device 400 and processes data, thereby monitoring the electronic device 400 as a whole.

[0140] In this embodiment, the processor 401 in the electronic device 400 loads the instructions corresponding to the processes of one or more applications into the memory 402 according to the following steps, and the processor 401 runs the applications stored in the memory 402 to achieve various functions: obtaining medical insurance review return tasks, parsing the return information in the medical insurance review return tasks, and generating a return element structure; determining the evidence requirement information adapted to the medical insurance review return tasks based on the return element structure, and generating an evidence list containing at least one evidence requirement item based on the evidence requirement information; retrieving the evidence data corresponding to the evidence requirement item from the medical data source according to the evidence requirement item in the evidence list and binding it to obtain an evidence binding record; generating an evidence completeness determination result of the evidence list based on the matching result of the evidence list and the evidence binding record, and outputting an appeal suggestion result based on the evidence completeness determination result, the appeal suggestion result including one of supplementary evidence, no appeal, and appealable.

[0141] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0142] Optional, such as Figure 7 As shown, the electronic device 400 may further include a display 403 and an input unit 404. The processor 401 is electrically connected to both the display 403 and the input unit 404. Those skilled in the art will understand that... Figure 7 The electronic device structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0143] Display 403 can be used to display a graphical user interface (GUI) and receive operation commands generated by the user interacting with the GUI. Display 403 may include a display panel and a touch panel. The display panel can be used to display information input by the user or information provided to the user, as well as various graphical user interfaces of the electronic device. These graphical user interfaces can be composed of graphics, guidance information, icons, video, and any combination thereof. Optionally, the display panel can be configured using a liquid crystal display (LCD), organic light-emitting diode (OLED), or other similar technologies. The touch panel can be used to collect touch operations performed by the user on or near it (such as operations performed by the user using a finger, stylus, or any suitable object or accessory on or near the touch panel), generate corresponding operation commands, and execute the corresponding program according to the operation commands. Optionally, the touch panel may include a touch detection device and a touch controller.

[0144] The touch detection device detects the user's touch location and the signal generated by the touch operation, transmitting the signal to the touch controller. The touch controller receives touch information from the touch detection device, converts it into touch point coordinates, and sends it to the processor 401. It can also receive and execute commands from the processor 401. The touch panel can cover the display panel. When the touch panel detects a touch operation on or near it, it transmits the information to the processor 401 to determine the type of touch event. Subsequently, the processor 401 provides corresponding visual output on the display panel based on the type of touch event. In this embodiment, the touch panel and display panel can be integrated into the display 403 to achieve input and output functions. However, in some embodiments, the touch panel and display panel can be implemented as two independent components to achieve input and output functions. That is, the display 403 can also be used as part of the input unit 404 to achieve input functions.

[0145] The input unit 404 can be used to receive input numbers, characters, or user characteristic information (such as fingerprints, iris, facial information, etc.), and to generate keyboard, mouse, joystick, optical, or trackball signal inputs related to user settings and function control.

[0146] In some embodiments, the electronic device may further include an audio circuit, which can provide an audio interface between the user and the electronic device via a speaker and a microphone. The audio circuit can convert received audio data into electrical signals and transmit them to the speaker, where the speaker converts them into sound signals for output. Conversely, the microphone converts collected sound signals into electrical signals, which are then received by the audio circuit, converted back into audio data, and output to processor 401 for processing. The audio data is then transmitted via radio frequency circuitry to, for example, another electronic device, or output to memory 402 for further processing. The audio circuit may also include an earphone jack to provide communication between peripheral headphones and the electronic device.

[0147] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0148] To this end, embodiments of this application provide a computer-readable storage medium storing multiple computer programs that can be loaded by a digital signal processor to execute the steps in the evidence matching and completeness assessment method for medical insurance review provided in embodiments of this application. Specific implementations of the above operations can be found in the preceding embodiments and will not be repeated here.

[0149] The computer-readable storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0150] Since the computer program stored in the computer-readable storage medium can execute the steps in the evidence matching and completeness assessment method for medical insurance review provided in the embodiments of this application, the beneficial effects that the evidence matching and completeness assessment method for medical insurance review provided in the embodiments of this application can achieve can be realized. For details, please refer to the previous embodiments, which will not be repeated here.

[0151] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A method for evidence matching and completeness assessment in medical insurance review, characterized in that, The method includes: Obtain medical insurance review rejection tasks, parse the rejection information in the medical insurance review rejection tasks, and generate a rejection element structure; Based on the return element structure, determine the evidence requirement information that is suitable for the medical insurance review return task, and generate an evidence list containing at least one evidence requirement item based on the evidence requirement information; Based on the evidence requirement items in the evidence list, the evidence data corresponding to the evidence requirement items is retrieved from the medical data source and bound to the data to obtain the evidence binding record; Based on the matching results between the evidence list and the evidence binding records, an evidence completeness determination result is generated for the evidence list, and an appeal suggestion result is output based on the evidence completeness determination result. The appeal suggestion result includes one of the following: evidence to be supplemented, no appeal allowed, and appealable. The evidence list includes a mandatory evidence subset and an optional evidence subset; the step of generating an evidence completeness determination result for the evidence list based on the matching results between the evidence list and the evidence binding records includes: For each evidence requirement item in the evidence list, retrieve the evidence binding record that matches the evidence requirement item and obtain the binding confidence level; if a matching evidence binding record exists and the corresponding binding confidence level reaches a preset confidence threshold, then assign a first value to the individual satisfaction level of the evidence requirement item; if a matching evidence binding record exists but the corresponding binding confidence level does not reach the preset confidence threshold, then assign the individual satisfaction level of the evidence requirement item to the ratio of the binding confidence level to the preset confidence threshold; if no evidence binding record matches the evidence requirement item, then assign a second value to the individual satisfaction level of the evidence requirement item. The completeness of the mandatory layer is calculated based on the individual satisfaction level and preset priority weight of each evidence requirement item in the mandatory evidence subset; the completeness of the optional layer is calculated based on the individual satisfaction level and preset priority weight of each evidence requirement item in the optional evidence subset; and the comprehensive completeness of the evidence list is calculated based on the completeness of the mandatory layer, the completeness of the optional layer, the first weight coefficient corresponding to the mandatory evidence subset, and the second weight coefficient corresponding to the optional evidence subset. Based on the comprehensive completeness, the evidence completeness judgment result of the evidence list is determined.

2. The method according to claim 1, characterized in that, The step of outputting appeal suggestions based on the evidence completeness determination result includes: Obtain the rule-layer judgment result corresponding to the medical insurance review rejection task; If the evidence completeness determination result indicates that the preset completeness condition is not met, the evidence to be supplemented is output; If the evidence completeness determination result indicates that the preset completeness condition is met, and the rule layer determination result indicates that appeal is not supported, then output "no appeal allowed"; If the evidence completeness determination result indicates that the preset completeness condition is met, and the rule layer determination result supports the appeal, then the appeal is allowed.

3. The method according to claim 1, characterized in that, The process of determining the evidence requirement information suitable for the medical insurance review and return task based on the return element structure includes: Based on the returned item identifier in the returned element structure, the associated mapping record is matched from the preset multi-level mapping library, which includes at least a rule layer, a policy layer, and an evidence type layer. The rule layer is used to match the returned item identifier with the corresponding return rule entry; the policy layer is used to associate the policy fragment identifier corresponding to the return rule entry; and the evidence type layer is used to define the evidence type set corresponding to the return rule entry. The evidence requirement information is determined based on the set of evidence types in the mapping record; The step of generating an evidence list containing at least one evidence requirement item based on the evidence requirement information includes: For each evidence type in the evidence type set, a corresponding evidence requirement item is generated, and constraints are configured for each evidence requirement item. The constraints include at least one of the following: mandatory / optional identifier, time limit constraint, and cross-visit constraint. The evidence list is generated by combining each of the aforementioned evidence requirements.

4. The method according to claim 1, characterized in that, The process involves retrieving the evidence data corresponding to each evidence requirement item from a medical data source based on the evidence requirement items in the evidence list, binding the data, and obtaining an evidence binding record, including: For each evidence requirement item in the evidence list, determine the evidence type corresponding to that evidence requirement item; Determine the corresponding retrieval strategy based on the evidence type; According to the retrieval strategy, evidence data matching the evidence requirement item is retrieved from at least one medical data source, and the retrieved evidence data is bound to the corresponding evidence requirement item to generate the evidence binding record.

5. The method according to claim 1, characterized in that, The step of parsing the return information in the medical insurance review and return task to generate a return element structure includes: Obtain the return information from the medical insurance review return task, wherein the return information contains multiple fields; According to the preset element categories, each field in the return information is classified into the corresponding element category to generate the return element structure; The return element structure is configured with at least one of the following element categories: diagnosis-related elements, treatment behavior elements, drug or consumable elements, laboratory test elements, visit type identifier, and cost time point elements.

6. A system for evidence matching and completeness assessment in medical insurance review, characterized in that, The system includes: The task access module is used to obtain medical insurance review rejection tasks; The element parsing module is used to parse the return information in the medical insurance review return task and generate a return element structure. The mapping library management module is used to determine the evidence requirement information that is compatible with the medical insurance review return task based on the return element structure. The list generation module is used to generate an evidence list containing at least one evidence requirement item based on the evidence requirement information. The multi-source retrieval and binding module is used to retrieve the evidence data corresponding to the evidence requirement item from the medical data source based on the evidence requirement item in the evidence list and bind it to obtain the evidence binding record; The completeness calculation module is used to generate an evidence completeness determination result for the evidence list based on the matching result between the evidence list and the evidence binding record; The suggestion output module is used to output the appeal suggestion results; The evidence list includes a mandatory evidence subset and an optional evidence subset; the completeness calculation module is specifically used for: For each evidence requirement item in the evidence list, retrieve the evidence binding record that matches the evidence requirement item and obtain the binding confidence level; if a matching evidence binding record exists and the corresponding binding confidence level reaches a preset confidence threshold, then assign a first value to the individual satisfaction level of the evidence requirement item; if a matching evidence binding record exists but the corresponding binding confidence level does not reach the preset confidence threshold, then assign the individual satisfaction level of the evidence requirement item to the ratio of the binding confidence level to the preset confidence threshold; if no evidence binding record matches the evidence requirement item, then assign a second value to the individual satisfaction level of the evidence requirement item. The completeness of the mandatory layer is calculated based on the individual satisfaction level and preset priority weight of each evidence requirement item in the mandatory evidence subset; the completeness of the optional layer is calculated based on the individual satisfaction level and preset priority weight of each evidence requirement item in the optional evidence subset; and the comprehensive completeness of the evidence list is calculated based on the completeness of the mandatory layer, the completeness of the optional layer, the first weight coefficient corresponding to the mandatory evidence subset, and the second weight coefficient corresponding to the optional evidence subset. Based on the comprehensive completeness, the evidence completeness judgment result of the evidence list is determined.

7. An electronic device, characterized in that, The electronic device includes a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the program to implement the evidence matching and completeness assessment method for medical insurance review as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a plurality of instructions adapted for loading by a processor to execute the evidence matching and completeness assessment method for medical insurance review as described in any one of claims 1 to 5.

Images