An intelligent agent comprehensive management system for medical insurance

Abstract

This invention relates to the field of intelligent agent management technology, specifically to a comprehensive intelligent agent management system for medical insurance, comprising: a scenario solidification module: receiving medical insurance consultation requests and binding the consultation requests with the current business context to generate scenario-constrained question-and-answer units corresponding to the consultation requests; a ruling locking module: generating a compliance ruling locking unit uniquely corresponding to the current business scenario; and a feedback linkage module: generating a corresponding execution feedback unit, triggering risk warnings and recording when subsequent actions are inconsistent with the compliance ruling locking unit. This invention eliminates generalized response questions detached from the actual business environment at the source, thereby improving the relevance and executability of medical insurance consultation results and reducing compliance risks caused by scenario misuse.

Description

Technical Field

[0001] This invention relates to the field of intelligent agent management technology, and in particular to a comprehensive intelligent agent management system for medical insurance. Background Technology

[0002] With the continuous reform of medical insurance payment methods and the strengthening of fund supervision, hospitals are increasingly demanding compliance with medical insurance regulations in their daily diagnosis and treatment, examination and testing, prescription issuance, and billing processes. Clinical departments, medical technology departments, and pharmacy departments frequently need to check medical insurance catalog information, verify the scope of payment, determine applicable conditions, and confirm the reasonableness of charges in their actual work.

[0003] In existing technologies, medical insurance information systems primarily provide services through catalog retrieval or rule matching. Some systems further incorporate natural language processing technology to automatically parse colloquial questions and provide policy explanations. While these technologies improve query efficiency to some extent, their core remains at the level of information retrieval or text-level responses, lacking the ability to constrain the actual business execution process. In practical applications, the aforementioned existing technologies exhibit several technical problems that are difficult to detect directly but have a significant impact. The scenario drift problem is particularly prominent. The medical insurance payment rules for the same treatment item or drug may differ significantly in different business scenarios, such as the applicable conditions differing between outpatient and inpatient care, different departments, or different job positions. However, existing systems typically return uniform results based solely on names or keywords, failing to incorporate the business context at the time of the inquiry into the judgment process. This leads to a mismatch between the responses obtained by medical staff and the actual execution scenario, resulting in situations where "the response is correct but the execution is illegal." Secondly, catalog mapping misalignment is widespread. In actual hospital operations, there are often complex relationships between hospital item names, local medical insurance catalog names, and national medical insurance codes, such as homonyms with different codes, homonyms with different codes, and combined charges. Summary of the Invention

[0004] This invention provides a comprehensive management system for medical insurance intelligent agents, which is a technical solution that can unify the management of medical insurance consultation, rule judgment and actual execution process. It enables medical insurance Q&A results to be deeply bound to specific business scenarios, and on this basis, completes the unique anchoring of the judgment object, joint verification of multi-dimensional rules and real-time linkage of execution behavior.

[0005] A comprehensive medical insurance intelligent management system includes: Scene solidification module: Receives medical insurance consultation requests and binds the medical insurance consultation requests with the current business context. The current business context corresponds to at least one or more of the following: consultation department, job identity, type of visit, status of associated medical orders or status of associated prescriptions, so as to generate a scene constraint question and answer unit corresponding to the medical insurance consultation request. The adjudication locking module takes the scenario constraint question and answer unit as input, performs catalog anchoring on the diagnosis and treatment items, drugs, examination and testing items or medical consumables involved, and performs mutual exclusion verification in combination with the limited payment scope, indication restrictions, disease restrictions, frequency restrictions and outpatient and inpatient application boundaries to generate a compliance adjudication locking unit that uniquely corresponds to the current business scenario. The verification and confirmation module takes the compliance ruling lock unit as input and outputs the medical insurance response result, policy basis, violation risk points and standardized operation suggestions. It also links and verifies the compliance ruling lock unit with subsequent medical order execution, prescription issuance, examination application or billing actions to generate corresponding execution verification units. When the subsequent actions are inconsistent with the compliance ruling lock unit, risk warnings and record keeping are triggered.

[0006] Optionally, the scene solidification module specifically includes: Request receiving submodule: Receives medical insurance consultation requests from user terminals, parses the medical insurance consultation requests, extracts the target object identifier and consultation intent expression from the medical insurance consultation requests, encapsulates the target object identifier and consultation intent expression in a structured manner, and generates the corresponding initial question and answer request unit; Semantic normalization submodule: Performs standardization processing on the target object identifier in the initial question-answering request unit to generate a standard question-answering expression unit; Context binding submodule: Obtains the business context information corresponding to the current medical insurance consultation request, binds the business context information to the standard question and answer expression unit, and generates a scenario binding unit with a context identifier; The scenario constraint generation submodule performs consistency verification and constraint completion on the scenario binding unit. When a missing or conflicting business context information is detected, it triggers a supplementary query or constraint correction, and converts the completed scenario binding unit into a scenario constraint question-and-answer unit that uniquely corresponds to the medical insurance consultation request.

[0007] Optionally, the standardization process includes mapping colloquial expressions, project aliases, pinyin abbreviations, and internal abbreviations to unified standard expressions, and semantically normalizing the expressions of consultation intent.

[0008] Optionally, the business context information includes at least one or more of the following: consultation department, job title, type of visit, status of associated medical orders, or status of associated prescriptions.

[0009] Optionally, the ruling locking module specifically includes: Directory recognition submodule: Taking the scenario constraint question-and-answer unit as input, it parses the target object information involved therein, identifies the diagnosis and treatment items, drugs, examination and testing items or medical consumables categories corresponding to the target object information, extracts the standard name, candidate code and object category identifier corresponding to the target object information, and generates a directory recognition unit; Directory anchoring submodule: Performs directory matching and object anchoring processing on the directory identification unit to generate a directory anchoring unit that uniquely corresponds to the target object information; Restriction Extraction Submodule: Based on the directory anchoring unit, retrieve the medical insurance restriction rules corresponding to the target object information, extract the limited payment scope, indication restrictions, disease restrictions, frequency restrictions, and outpatient and inpatient application boundaries, and generate the corresponding rule constraint unit.

[0010] Optionally, the ruling locking module further includes: Mutual Exclusion Verification Submodule: The current business scenario in the rule constraint unit is compared item by item with the current business scenario in the scenario constraint question and answer unit to identify whether the target object information has rule conflict, application conflict or payment conflict in the current business scenario, and to make mutual exclusion judgments on the risk of duplicate charging, project decomposition risk, project swapping risk and scenario mismatch risk, and generate a verification decision unit. The adjudication locking submodule merges the results of the verification adjudication unit and encapsulates the adjudication, associating and solidifying the compliance conclusion, the basis for restriction, the risk label and the corresponding business scenario identifier, and generating the compliance adjudication locking unit that uniquely corresponds to the current business scenario.

[0011] Optionally, the directory matching and object anchoring process includes matching the target object information in the directory identification unit with the medical insurance catalog, the hospital's local project database, and the billing code database, and distinguishing and correcting objects with the same name but different codes, objects with different names but the same code, and combined billing objects.

[0012] Optionally, the certificate return linkage module specifically includes: The response generation submodule takes the compliance ruling locking unit as input, parses and reconstructs the compliance conclusion, restriction basis and risk label in it, and generates a structured medical insurance response result. The medical insurance response result includes at least the compliance conclusion, policy basis, violation risk points and standard operation suggestions, and establishes a correspondence between the medical insurance response result and the compliance ruling locking unit. Execution mapping submodule: Based on the target object identifier and business scenario identifier in the compliance ruling locking unit, establish a mapping relationship between it and subsequent business actions, and generate corresponding execution association units; Linkage verification submodule: When the subsequent business action occurs, the execution association unit is compared with the actual business action in real time to determine whether the subsequent business action is consistent with the compliance ruling and locking unit, and a corresponding consistency judgment result is generated to form an execution comparison unit; Execution verification generation submodule: Based on the execution comparison unit, the medical insurance response result, the compliance ruling locking unit, and the subsequent business actions are associated and encapsulated to generate the execution verification unit; Risk Trigger Submodule: When the execution comparison unit indicates that the subsequent business action is inconsistent with the compliance ruling and locking unit, a risk warning and a record are triggered.

[0013] Optionally, the execution verification unit is used to record the correspondence between the medical insurance consultation results and the actual execution behavior; the risk prompt is used to output violation warning information; and the trace record is used to record the deviation type, trigger time, associated department and corresponding business action information.

[0014] Optionally, the subsequent business actions include at least one or more of the following: execution of medical orders, prescription issuance, examination application, or payment.

[0015] The beneficial effects of this invention are: This invention, through a scenario solidification module, binds the consultation content with the consulting department, job title, type of visit, and status of related medical orders or prescriptions after receiving a medical insurance consultation request. This generates scenario-constrained question-and-answer units with clear business context, ensuring that all subsequent judgments are made under the constraints of this scenario. This eliminates generalized answers that are detached from the actual business environment from the source, thereby improving the relevance and enforceability of medical insurance consultation results and reducing compliance risks caused by misuse of scenarios.

[0016] This invention, by introducing a directory anchoring mechanism and a discrimination calculation for homonymous / heterogeneous / homogeneous codes, transforms the determination of medical insurance targets from name matching to unique anchoring, effectively solving the problems of directory mapping misalignment and hidden violation identification. In actual medical operations, complex mapping relationships such as homonymous / heterogeneous codes, heteronymous / homogeneous codes, and combined charges are common among hospital project names, medical insurance catalog names, and charging codes. Traditional systems often rely on single name matching, which can easily lead to deviations in the determination of targets, resulting in incorrect medical insurance conclusions. In the adjudication locking module, this invention uses directory recognition and directory anchoring processing to perform multi-source matching between the target object and the medical insurance catalog database, the hospital's local project database, and the charging code database. Furthermore, it combines name matching degree, business scenario matching degree, and historical usage consistency to construct a comprehensive discrimination calculation model. This model selects the optimal code for homonymous / heterogeneous codes and performs consistency discrimination for heteronymous / homogeneous codes, thereby achieving unique determination of the medical insurance determination target. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in this invention 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 for this invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Fig. 1 This is a schematic diagram of the system functional modules according to an embodiment of the present invention; Fig. 2 This is a schematic diagram of the certificate linkage module in an embodiment of the present invention. Detailed Implementation

[0019] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments. For some well-known technologies, those skilled in the art may also use other alternative methods to implement the invention. Moreover, the accompanying drawings are only for more specific description of the embodiments and are not intended to specifically limit the present invention.

[0020] like Figs. 1-2 As shown, a comprehensive medical insurance intelligent management system includes: Scene solidification module: Receives medical insurance consultation requests and binds the medical insurance consultation requests with the current business context. The current business context corresponds to at least one or more of the following: consultation department, job identity, type of visit, status of associated medical orders or status of associated prescriptions, so as to generate a scene-constrained question and answer unit corresponding to the medical insurance consultation request.

[0021] In one embodiment of the present invention, the scenario solidification module is used to transform medical insurance consultation requests from natural language expressions into structured judgment inputs with clear business constraints. It includes a request receiving submodule, a semantic normalization submodule, a context binding submodule, and a scenario constraint generation submodule. Each submodule works in sequence to generate a scenario constraint question and answer unit.

[0022] 1. Request Receiving Submodule: The request receiving submodule receives medical insurance consultation requests from user terminals and performs input parsing processing on the medical insurance consultation requests.

[0023] Specifically, the request receiving submodule can obtain the medical insurance consultation request input by the user through the hospital information system interface or the mobile terminal interface. The medical insurance consultation request can be in the form of text input or in the form of text after voice input is recognized and converted. Then, the medical insurance consultation request is parsed and entity recognition is performed to extract the target object identifier and consultation intent expression involved.

[0024] The target object identifier is used to indicate the diagnosis and treatment items, drug names, examination and testing items, or medical consumables involved in the consultation; the consultation intent expression is used to characterize the core purpose of the user's consultation, including whether it is reimbursable, whether there are payment restrictions, scope of application, and frequency restrictions. After extraction, the target object identifier and consultation intent expression are structurally encapsulated to form a unified data structure expression, and a corresponding initial question-and-answer request unit is generated. The initial question-and-answer request unit serves as the input carrier for subsequent semantic normalization processing, ensuring that all subsequent processing revolves around the unified structure.

[0025] II. Semantic Normalization Submodule: The semantic normalization submodule standardizes the target object identification and consultation intent expression in the initial question and answer request unit.

[0026] In its implementation, the semantic normalization submodule, targeting the object identifier, first calls a pre-defined terminology mapping rule library to uniformly convert colloquial expressions, project aliases, pinyin abbreviations, and hospital abbreviations in the initial question-and-answer request unit. This includes mapping different expressions such as enhanced CT, CT enhanced scan, and enhanced scan to standard treatment project names; mapping drug brand names to generic names; and restoring pinyin abbreviations to complete project names. Simultaneously, semantic normalization is performed on the expression of consultation intent, unifying different expressions into standard intent types. For example, "Can it be reimbursed?", "Can it be reimbursed by medical insurance?", and "Can I use medical insurance?" are unified into "Reimbursement feasibility determination"; and "Are there any restrictions?" and "Under what circumstances can it be used?" are unified into "Limited payment scope determination".

[0027] After completing the above processing, a standard question-and-answer expression unit with a unified format is generated. The standard question-and-answer expression unit eliminates name ambiguity and semantic differences at the expression level, providing stable input for subsequent context binding.

[0028] 3. Context Binding Submodule: The context binding submodule obtains the business context information corresponding to the current medical insurance consultation request and binds the business context information to the standard question and answer expression unit.

[0029] In practice, the context binding submodule can obtain the current user's business environment information in real time through the hospital information system interface. The business context information includes at least one or more of the following: Consultation department information is used to indicate whether the current business belongs to a clinical department, medical technology department, or pharmacy department; Job identity information is used to distinguish different roles such as physician, technician, or pharmacist; Medical visit type information is used to distinguish between outpatient, inpatient, or chronic disease management scenarios; The associated medical order status is used to indicate whether there are currently any medical orders that have been issued or are pending execution; The associated prescription status is used to indicate whether a prescription has been issued.

[0030] After obtaining the above business context information, it is integrated and bound with the standard question and answer expression unit to form a unified data object in structure. A context identifier field is added to this data object to represent the specific business environment of the current consultation.

[0031] Ultimately, scenario binding units with context identifiers are generated. These scenario binding units give the originally independent question-and-answer expressions a clear business context, providing necessary constraints for compliance rulings.

[0032] IV. Scene Constraint Generation Submodule: The scene constraint generation submodule performs consistency verification and constraint completion processing on the scene binding unit, and generates the final scene constraint question and answer unit.

[0033] In the specific implementation, consistency checks are performed on the scenario-bound units to detect whether the business context information is complete and logically consistent, including checking for situations such as missing consultation types, mismatch between department types and job identities, or inconsistencies between medical order status and consultation content.

[0034] When missing or conflicting business context information is detected, the scenario constraint generation submodule triggers a supplementary query mechanism or a constraint correction mechanism. The supplementary query mechanism sends a request for supplementary information to the user to obtain the necessary judgment conditions; the constraint correction mechanism automatically completes reasonable context constraints under inferable conditions. After completing consistency verification and constraint completion, the scenario binding unit is finally structured to ensure its uniqueness and completeness in terms of semantics, objects, and context.

[0035] Finally, a scenario-constrained question-and-answer unit that uniquely corresponds to the medical insurance consultation request is generated and output to the subsequent adjudication and locking module as the sole input.

[0036] The adjudication locking module takes the scenario constraint question and answer unit as input, performs catalog anchoring on the diagnosis and treatment items, drugs, examination and testing items or medical consumables involved, and performs mutual exclusion verification in combination with the limited payment scope, indication restrictions, disease restrictions, frequency restrictions and outpatient and inpatient application boundaries to generate a compliance adjudication locking unit that uniquely corresponds to the current business scenario.

[0037] In one embodiment of the present invention, the adjudication locking module is used to receive the scenario constraint question and answer unit output by the scenario solidification module, and complete object identification, directory anchoring, restriction extraction, conflict verification and result locking around the target object pointed to in the scenario constraint question and answer unit, thereby transforming the consultation request that was originally at the question and answer semantic level into a compliance adjudication locking unit that uniquely corresponds to the current business scenario.

[0038] The adjudication and locking module includes a directory identification submodule, a directory anchoring submodule, a restriction extraction submodule, a mutual exclusion verification submodule, and an adjudication and locking submodule. These submodules are executed in a sequential manner.

[0039] I. Directory Recognition Submodule: The directory recognition submodule takes the scenario-constrained question-and-answer unit as input, parses the target object information involved, and identifies the corresponding diagnosis and treatment items, drugs, examination and testing items or medical consumables categories. It extracts the standard name, candidate code and object category identifier corresponding to the target object information and generates a directory recognition unit.

[0040] In its implementation, the directory recognition submodule first reads the target object information, consultation intent information, and business scenario identifier from the scenario constraint question and answer unit. The target object information includes the project name, drug name, examination name, test name, or consumable name explicitly stated by the user during the consultation. It can also be a standardized expression formed after the previous semantic normalization processing. The directory recognition submodule does not directly make a final decision on the original natural language, but first performs category recognition on the target object information to determine which directory rule system should be entered next.

[0041] Specifically, if the target object information corresponds to treatment, examination, operation, or billing behavior, it is identified as a treatment item category; if the target object information corresponds to a drug entity, it is identified as a drug category; if the target object information corresponds to imaging examinations, functional examinations, or laboratory tests, it is identified as an examination or testing item category; and if the target object information corresponds to implants, disposable medical devices, treatment materials, or auxiliary consumables, it is identified as a medical consumables category. By first classifying the object categories, it is possible to avoid mixing different rule systems during subsequent catalog matching.

[0042] After completing category identification, the catalog identification submodule further extracts the standard name, candidate code, and object category identifier corresponding to the target object information. The standard name is used as the main retrieval basis for subsequent catalog matching; the candidate code is used to retain multiple catalog items or charging items that may correspond to the target object information; and the object category identifier is used to indicate the type of medical insurance rule that should apply to the target object.

[0043] Finally, the directory recognition submodule encapsulates the recognition results in a structured manner, generates a directory recognition unit, and passes the directory recognition unit to the directory anchoring submodule.

[0044] II. Directory Anchoring Submodule: The directory anchoring submodule performs directory matching and object anchoring processing on the directory identification unit. It matches the target object information in the directory identification unit with the medical insurance catalog, the hospital's local project database, and the billing code database. It also distinguishes and corrects objects with the same name but different codes, objects with different names but the same code, and combined billing objects, generating a directory anchoring unit that uniquely corresponds to the target object information.

[0045] In its implementation, after receiving the directory identification unit, the directory anchoring submodule first calls the corresponding directory source according to the object category identifier. For the medical treatment item category, it prioritizes calling the medical insurance medical treatment item directory and the hospital's local billing item directory; for the drug category, it calls the medical insurance drug directory and the hospital's drug dictionary; for the examination and testing item category, it calls the examination and testing directory, the imaging directory, and the local billing details directory; for the medical consumables category, it calls the medical insurance consumables directory and the hospital's material coding database. Through multi-source directory joint matching, the identification error caused by matching a single directory can be avoided.

[0046] During the directory matching process, the directory anchoring submodule does not simply perform a unique match based on the name. Instead, it performs a joint comparison of the standard name, candidate code, and object category identifier in the directory identification unit. If a standard name corresponds to multiple candidate codes, it is considered an object with the same name but different codes. If multiple standard names ultimately correspond to the same billing code or the same medical insurance code, they are considered objects with different names but the same code. If a user consultation object corresponds to an in-hospital billing method composed of multiple basic billing sub-items, it is considered a combined billing object. For the above situations, the directory anchoring submodule further distinguishes and corrects based on the current business scenario, in-hospital project configuration relationships, and billing execution habits.

[0047] Specifically, for objects with the same name but different codes, the directory anchoring submodule determines the actual directory item to which the current consultation points based on the visit type, consulting department, job title, and the status of associated medical orders or prescriptions. For objects with different names but the same code, the directory anchoring submodule eliminates expression differences through standard name priority and local mapping rules. For combined billing objects, the combined object is split into a set of basic billing objects, and it is determined whether the combined object is allowed to be billed as a whole or must be judged separately according to the basic objects at the medical insurance rule level. This avoids the problem of the system anchoring to a different billing object when the user asks about one type of object.

[0048] In this invention, a joint discrimination model is constructed by building a name consistency metric, encoding aggregation relationship and scenario constraint weight to distinguish between objects with the same name but different codes and objects with different names but the same code, and output a unique directory anchoring result.

[0049] 1. Differentiating between names with different characters: A standard name Corresponding to multiple encoding sets The goal is to select the unique code that best fits the current business scenario from multiple candidate codes. The calculation is as follows: Construct a comprehensive matching scoring function: ;in, Indicates the first The overall matching score of each candidate code. This indicates name matching degree, i.e., text similarity. This indicates the scenario matching degree, namely, department / patient type / job position. This indicates historical consistency, including frequency of use within the hospital or path matching. These are the weighting coefficients.

[0050] Name matching degree: Based on the longest common subsequence.

[0051] Scene matching degree: ;in, Indicates whether the department matches (match = 1, otherwise 0). Indicates outpatient / inpatient matching. This indicates a good match for the job.

[0052] Consistency in use: This indicates the percentage of times that code has been used in this scenario throughout history.

[0053] Final judgment: That is, the code with the highest score is used as the unique anchor code.

[0054] 2. Differentiating between different names with the same code: Multiple names Corresponding to the same code The goal is to determine whether these names belong to the same semantic object, avoiding misclassification. The calculation is as follows: Construct a name consistency check function: ;in, Indicates name and Consistency score, Text similarity is expressed using edit distance. For semantic similarity, This represents the weighting coefficient, which ranges from 0.6 to 0.8.

[0055] Judgment rule: If The same object; among which, This represents the consistency threshold, with a value of 0.7.

[0056] After completing directory matching and object anchoring, the directory anchoring submodule encapsulates the anchoring results as unique objects to form directory anchoring units. The directory anchoring unit records at least the final anchoring name, anchoring code, object category, and anchoring basis of the target object, which is used to restrict the extraction submodule from directly calling the corresponding medical insurance restriction rules.

[0057] III. Restriction Extraction Submodule: The restriction extraction submodule retrieves the medical insurance restriction rules corresponding to the target object information based on the directory anchor unit, extracts the limited payment scope, indication restrictions, disease restrictions, frequency restrictions, and outpatient and inpatient application boundaries, and generates the corresponding rule constraint unit.

[0058] In the specific implementation, after obtaining the directory anchor unit, the restriction extraction submodule first locates the corresponding medical insurance rule entry based on the anchor code and object category recorded therein. The medical insurance rule entry comes from the medical insurance catalog rules, provincial and municipal medical insurance implementation rules, local medical insurance implementation guidelines of the hospital, or supplementary rule sets confirmed by the hospital's medical insurance management department. The restriction extraction submodule performs structured decomposition on the located rule entry, so that the medical insurance requirements originally expressed in the form of text, entries, or descriptions are transformed into verifiable rule constraints.

[0059] Among them, the scope of payment is used to characterize the conditions under which the target object can be included in medical insurance payment; the indication restriction is used to characterize the medical condition boundary for which the drug or project is applicable; the disease restriction is used to characterize whether the target object is only applicable to a specific disease, chronic and special disease, or a specific diagnostic scenario; the frequency restriction is used to characterize the number of times it can be executed, billed, or reimbursed within a given period; the outpatient and inpatient application boundary is used to characterize the application differences of the target object in outpatient scenarios, inpatient scenarios, or specific management scenarios; in order to facilitate subsequent item-by-item comparison, the restriction extraction submodule extracts the above-mentioned restriction contents into standard constraint items, and records the constraint type, constraint content, applicable conditions, and rule source in each constraint item.

[0060] The restriction extraction submodule encapsulates the extracted rules and constraints into a unified unit, generates a rule constraint unit, and sends the rule constraint unit to the mutual exclusion verification submodule.

[0061] IV. Mutual Exclusion Verification Submodule: The mutual exclusion verification submodule compares the current business scenario in the rule constraint unit with the scenario constraint question and answer unit item by item, identifies whether the target object information has rule conflicts, application conflicts or payment conflicts in the current business scenario, and performs mutual exclusion judgment on the risks of duplicate charges, project decomposition, project swapping and scenario mismatch, and generates a verification adjudication unit.

[0062] In its implementation, the mutual exclusion verification submodule, after receiving the rule constraint unit, does not directly output a simple conclusion of reimbursement eligibility or non-reimbursement eligibility. Instead, it re-verifies the rule constraint unit against the business scenario information in the scenario constraint question-and-answer unit. The business scenario information includes at least one or more of the following: consultation department, job title, type of visit, and status of associated medical orders or prescriptions. Through this rule-based scenario matching method, it determines whether the extracted medical insurance rules are truly valid in the current scenario.

[0063] During the item-by-item comparison process, if the applicable conditions in the rule constraint unit are consistent with the current business scenario, it is determined to be conflict-free; if the applicable conditions cannot be met, it is further classified into rule conflict, application conflict, or payment conflict. Among them, rule conflict mainly refers to different rule entries giving inconsistent constraints on the same target object in the current scenario, or there are conflicts between the preceding and following conditions within the same rule entry; application conflict mainly refers to the inconsistency between the current business scenario and the target object's limited scenario, such as a project limited to inpatient use being placed in an outpatient scenario for consultation or execution; payment conflict mainly refers to the object itself being executable, but not being included in medical insurance payment under the current payment boundary, or requiring additional restrictive conditions to be met before payment can be made.

[0064] In addition to the general conflicts mentioned above, the mutual exclusion verification submodule also performs mutual exclusion judgments for more hidden violations in medical insurance management. For the risk of double billing, it searches whether there are identical objects, similar objects, or billing items already covered by the same medical order path in the current business scenario; for the risk of item decomposition, it determines whether the current anchor object belongs to the whole item that should not be split for billing, but the current billing method uses basic sub-item split billing; for the risk of item substitution, it determines whether there is a correspondence between the current anchor object and the actual object to be executed, with an payable object replacing an inpayable object.

[0065] After completing all item-by-item comparisons and mutual exclusion checks, the mutual exclusion verification submodule merges and organizes the conflict types, risk types, conflict bases, and scenario correspondences obtained from the verification to form a verification decision unit. The verification decision unit provides complete decision-making basis for the decision locking submodule.

[0066] V. Adjudication Locking Submodule: The adjudication locking submodule merges the results of the verification adjudication unit and encapsulates the adjudication, associating and solidifying the compliance conclusion, the basis for restriction, the risk label and the corresponding business scenario identifier, and generating a compliance adjudication locking unit that uniquely corresponds to the current business scenario.

[0067] In its implementation, the adjudication locking submodule receives the verification adjudication unit and then systematically organizes the recorded rule conflicts, application conflicts, payment conflicts, and various risk assessment results. For cases without conflicts and without identified risk tags, a pass-through compliance conclusion is generated. For cases with restrictions but which can be executed under the conditions after verification in the current business scenario, a restrictive compliance conclusion is generated. For cases where the current business scenario clearly does not meet payment requirements or has high-risk conflicts, a prohibition or warning compliance conclusion is generated. Simultaneously, the adjudication locking submodule associates and solidifies the compliance conclusion with its corresponding restrictive basis, risk tag, and business scenario identifier. This association solidification means binding the adjudication result to the specific scenario that triggered it, preventing the same conclusion from being misused for the same target object in other scenarios.

[0068] Finally, the ruling locking submodule outputs a compliance ruling locking unit, which serves as the final output of the ruling locking module and is used by the subsequent certificate return linkage module.

[0069] The verification and confirmation module takes the compliance ruling lock unit as input and outputs the medical insurance response result, policy basis, violation risk points and standardized operation suggestions. It also links and verifies the compliance ruling lock unit with subsequent medical order execution, prescription issuance, examination application or billing actions to generate corresponding execution verification units. When the subsequent actions are inconsistent with the compliance ruling lock unit, risk warnings and record keeping are triggered.

[0070] In one embodiment of the present invention, the verification and confirmation linkage module receives the compliance ruling and locking unit output by the ruling and locking module, transforms the unit from a "judgment result" into "executable constraints and traceable evidence," and forms a complete execution closed loop through linkage and verification with subsequent business actions. The verification and confirmation linkage module includes a response generation submodule, an execution mapping submodule, a linkage verification submodule, a verification and confirmation generation submodule, and a risk triggering submodule. Each submodule works in sequence and collaboratively to ultimately generate an execution verification and confirmation unit.

[0071] I. Response Generation Submodule: The response generation submodule takes the compliance ruling locking unit as input, parses and reconstructs the compliance conclusion, restriction basis and risk label in it, generates a structured medical insurance response result, and establishes a correspondence between the medical insurance response result and the compliance ruling locking unit.

[0072] In its implementation, the response generation submodule first reads the compliance conclusion type, set of limiting conditions, and set of risk labels recorded in the compliance ruling locking unit, and then performs semantic reconstruction processing on them, transforming the structured results originally used for internal judgment into a response expression that can be understood by medical staff. This process is not a simple text splicing, but rather a hierarchical organization of the response structure according to the conclusion type.

[0073] Among them, the compliance conclusion is used to directly indicate the medical insurance executable status of the target object in the current business scenario; the policy basis is used to indicate the medical insurance catalog entries or rule sources on which the compliance conclusion is based; the violation risk point is used to indicate the type of violation that may be triggered if the ruling is deviated from in the current scenario; and the standardized operation suggestion is used to provide a recommended execution method or alternative path that complies with medical insurance rules.

[0074] After completing the above information reconstruction, the response generation submodule establishes an association index relationship between the generated structured medical insurance response results and the corresponding compliance ruling locking unit, so that each response can be traced back to its corresponding ruling source. The association relationship provides basic support for subsequent execution verification and return certificate generation.

[0075] 2. Execution Mapping Submodule: Based on the target object identifier and business scenario identifier in the compliance ruling locking unit, the execution mapping submodule establishes a mapping relationship between the target object identifier and subsequent business actions, and generates the corresponding execution association unit.

[0076] In its implementation, the execution mapping submodule first parses the target object identifier and the current business scenario identifier in the compliance ruling locking unit to determine the role of the ruling result in the actual business process. For example, for medical treatment items, it mainly maps to the execution of medical orders and billing actions; for pharmaceutical items, it mainly maps to prescription issuance and drug billing; for examination and testing items, it maps to examination application and test execution; and for medical consumables, it maps to consumables usage registration and billing actions.

[0077] After determining the mapping type, the execution mapping submodule further establishes the correspondence rules between the target object and the specific business action, so that the system can identify whether the action belongs to the execution behavior within the scope of the adjudication when the subsequent business action occurs. The correspondence includes not only object name or code matching, but also scenario consistency matching, that is, ensuring that the consultation type, department attribute and execution path of the subsequent business action are consistent with the business scenario identifier in the compliance adjudication locking unit.

[0078] Finally, the execution mapping submodule encapsulates the above mapping relationship in a structured way to generate execution association units, which are used for real-time comparison by the subsequent linkage verification submodule.

[0079] 3. Linkage Verification Submodule: When subsequent business actions occur, the linkage verification submodule will compare the execution related unit with the actual business action in real time, determine whether the subsequent business action is consistent with the compliance ruling and locking unit, and generate the corresponding consistency judgment result, forming an execution comparison unit.

[0080] In its implementation, the linkage verification submodule interfaces with the hospital information system to monitor or receive real-time actions such as medical order execution, prescription issuance, examination requests, and billing. When a relevant business action is detected, key fields such as the object information, executing department, visit type, and time stamp are automatically extracted. The actual business action information is then compared item by item with the execution-related unit. The comparison includes at least consistency in the target object, coding, business scenario, and execution path. If all of the above conditions are met, the execution is considered consistent; if any mismatch exists, the deviation type is further identified, such as object deviation, scenario deviation, or rule deviation.

[0081] After the comparison is completed, the linkage verification submodule encapsulates the comparison results and deviation information to generate an execution comparison unit. The execution comparison unit is not only used to describe whether there is consistency, but also to provide a basis for subsequent certificate generation and risk triggering.

[0082] IV. Execution Certificate Generation Submodule: Based on the execution comparison unit, the execution certificate generation submodule associates and encapsulates the medical insurance response result, the compliance ruling locking unit, and subsequent business actions to generate the execution execution certificate unit.

[0083] In its implementation, the certificate generation submodule integrates three types of core information: first, the medical insurance response results from the response generation submodule; second, the compliance ruling locking unit from the ruling locking module; and third, the actual business actions and execution comparison results from the linkage verification submodule. By unifying and associating the above information, a complete consultation, ruling, and execution chain can be constructed.

[0084] The execution verification unit must record at least the following: the original medical insurance response result, the corresponding compliance ruling lock unit identifier, the actual business action information, and the execution comparison results. This structured record allows for a complete reconstruction of the execution of a medical insurance consultation result in actual business operations during subsequent inquiries, audits, or training. This execution verification unit not only records historical behavior but also serves as the data foundation for subsequent statistical analysis and compliance assessment, elevating medical insurance management from a single response to full-process traceability management.

[0085] V. Risk Trigger Submodule: When the subsequent business actions represented by the execution comparison unit are inconsistent with the compliance ruling locking unit, the risk trigger submodule will trigger risk warnings and record the data.

[0086] In its implementation, when the comparison unit determines an inconsistency, the risk triggering submodule first generates corresponding risk warning information based on the deviation type. This risk warning information can be categorized into different levels, such as general warnings, key alerts, or mandatory reminders, and can be displayed in real-time on the user terminal interface to alert medical staff to potential medical insurance violation risks associated with the current operation. Simultaneously, the risk triggering submodule records this inconsistency. The record includes at least the deviation type, trigger time, associated department, information on involved parties, and corresponding business action information. In further implementation, the risk triggering submodule can also synchronize the record to the log management module to support statistical analysis by department, time, or risk type, providing data support for hospital medical insurance management personnel.

[0087] This invention encompasses any substitutions, modifications, equivalent methods, and solutions made within the spirit and scope of this invention. To provide the public with a thorough understanding of this invention, specific details are described in detail in the following preferred embodiments; however, those skilled in the art will fully understand the invention even without these details. Furthermore, to avoid unnecessary misunderstanding of the essence of this invention, well-known methods, processes, procedures, components, and circuits are not described in detail.

[0088] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A comprehensive intelligent management system for medical insurance, characterized in that, include: Scene solidification module: Receives medical insurance consultation requests and binds the medical insurance consultation requests with the current business context. The current business context corresponds to at least one or more of the following: consultation department, job identity, type of visit, status of associated medical orders or status of associated prescriptions, so as to generate a scene constraint question and answer unit corresponding to the medical insurance consultation request. The adjudication locking module takes the scenario constraint question and answer unit as input, performs catalog anchoring on the diagnosis and treatment items, drugs, examination and testing items or medical consumables involved, and performs mutual exclusion verification in combination with the limited payment scope, indication restrictions, disease restrictions, frequency restrictions and outpatient and inpatient application boundaries to generate a compliance adjudication locking unit that uniquely corresponds to the current business scenario. The verification and confirmation module takes the compliance ruling lock unit as input and outputs the medical insurance response result, policy basis, violation risk points and standardized operation suggestions. It also links and verifies the compliance ruling lock unit with subsequent medical order execution, prescription issuance, examination application or billing actions to generate corresponding execution verification units. When the subsequent actions are inconsistent with the compliance ruling lock unit, risk warnings and record keeping are triggered.

2. The medical insurance intelligent body integrated management system according to claim 1, characterized in that, The scene solidification module specifically includes: Request receiving submodule: Receives medical insurance consultation requests from user terminals, parses the medical insurance consultation requests, extracts the target object identifier and consultation intent expression from the medical insurance consultation requests, encapsulates the target object identifier and consultation intent expression in a structured manner, and generates the corresponding initial question and answer request unit; Semantic normalization submodule: Performs standardization processing on the target object identifier in the initial question-answering request unit to generate a standard question-answering expression unit; Context binding submodule: Obtains the business context information corresponding to the current medical insurance consultation request, binds the business context information to the standard question and answer expression unit, and generates a scenario binding unit with a context identifier; The scenario constraint generation submodule performs consistency verification and constraint completion on the scenario binding unit. When a missing or conflicting business context information is detected, it triggers a supplementary query or constraint correction, and converts the completed scenario binding unit into a scenario constraint question-and-answer unit that uniquely corresponds to the medical insurance consultation request.

3. The medical insurance intelligent body integrated management system according to claim 2, characterized in that, The standardization process includes mapping colloquial expressions, project aliases, pinyin abbreviations, and internal abbreviations into unified standard expressions, and semantically normalizing the expressions of consultation intent.

4. The medical insurance intelligent body integrated management system according to claim 2, characterized in that, The business context information includes at least one or more of the following: consultation department, job title, type of visit, status of associated medical orders, or status of associated prescriptions.

5. The medical insurance intelligent body integrated management system according to claim 1, characterized in that, The ruling and locking module specifically includes: Directory recognition submodule: Taking the scenario constraint question-and-answer unit as input, it parses the target object information involved therein, identifies the diagnosis and treatment items, drugs, examination and testing items or medical consumables categories corresponding to the target object information, extracts the standard name, candidate code and object category identifier corresponding to the target object information, and generates a directory recognition unit; Directory anchoring submodule: Performs directory matching and object anchoring processing on the directory identification unit to generate a directory anchoring unit that uniquely corresponds to the target object information; Restriction Extraction Submodule: Based on the directory anchoring unit, retrieve the medical insurance restriction rules corresponding to the target object information, extract the limited payment scope, indication restrictions, disease restrictions, frequency restrictions, and outpatient and inpatient application boundaries, and generate the corresponding rule constraint unit.

6. The medical insurance intelligent body integrated management system according to claim 5, characterized in that, The ruling locking module also includes: Mutual Exclusion Verification Submodule: The current business scenario in the rule constraint unit is compared item by item with the current business scenario in the scenario constraint question and answer unit to identify whether the target object information has rule conflict, application conflict or payment conflict in the current business scenario, and to make mutual exclusion judgments on the risk of duplicate charging, project decomposition risk, project swapping risk and scenario mismatch risk, and generate a verification decision unit. The adjudication locking submodule merges the results of the verification adjudication unit and encapsulates the adjudication, associating and solidifying the compliance conclusion, the basis for restriction, the risk label and the corresponding business scenario identifier, and generating the compliance adjudication locking unit that uniquely corresponds to the current business scenario.

7. The medical insurance intelligent body integrated management system according to claim 5, characterized in that, The directory matching and object anchoring process includes matching the target object information in the directory identification unit with the medical insurance catalog, the hospital's local project database, and the billing code database, and distinguishing and correcting objects with the same name but different codes, objects with different names but the same code, and combined billing objects.

8. The medical insurance intelligent body integrated management system according to claim 1, characterized in that, The certificate verification linkage module specifically includes: The response generation submodule takes the compliance ruling locking unit as input, parses and reconstructs the compliance conclusion, restriction basis and risk label in it, and generates a structured medical insurance response result. The medical insurance response result includes at least the compliance conclusion, policy basis, violation risk points and standard operation suggestions, and establishes a correspondence between the medical insurance response result and the compliance ruling locking unit. Execution mapping submodule: Based on the target object identifier and business scenario identifier in the compliance ruling locking unit, establish a mapping relationship between it and subsequent business actions, and generate corresponding execution association units; Linkage verification submodule: When the subsequent business action occurs, the execution association unit is compared with the actual business action in real time to determine whether the subsequent business action is consistent with the compliance ruling and locking unit, and a corresponding consistency judgment result is generated to form an execution comparison unit; Execution verification generation submodule: Based on the execution comparison unit, the medical insurance response result, the compliance ruling locking unit, and the subsequent business actions are associated and encapsulated to generate the execution verification unit; Risk Trigger Submodule: When the execution comparison unit indicates that the subsequent business action is inconsistent with the compliance ruling and locking unit, a risk warning and a record are triggered.

9. A comprehensive medical insurance intelligent management system according to claim 8, characterized in that, The execution verification unit is used to record the correspondence between medical insurance consultation results and actual execution behavior; the risk prompt is used to output violation warning information; and the traceability record is used to record deviation type, trigger time, associated department and corresponding business action information.

10. A comprehensive medical insurance intelligent management system according to claim 9, characterized in that, The subsequent business actions include at least one or more of the following: execution of medical orders, prescription issuance, examination application, or payment.

Images