A medical bill information management method and system based on rule and vector cooperation

Abstract

The application relates to a medical bill information management method and system based on rule and vector cooperation, and belongs to the technical field of medical data processing. The method comprises the following steps: constructing a standard knowledge base containing a plurality of medical entities; obtaining medical bill data to be managed and performing pretreatment; performing normalization management on the pretreated data based on the standard knowledge base; different normalization sub-processes are adopted for information at different semantic levels, and each sub-process is sequentially matched in the following order: first level, accurate matching based on string equivalence comparison; second level, fault-tolerant rule matching based on edit distance or word segmentation; third level, vector matching based on semantic vector similarity; fourth level, calling a large language model to output a standard name and a confidence degree; and outputting the standardized field and a standard code thereof. Through the progressive strategy of rule priority, vector intermediate and large model backup, the management efficiency and accuracy are considered, and efficient and accurate normalization of medical bill information is realized.

Description

Technical Field

[0001] This application relates to the field of medical data processing technology, and more specifically, to a method and system for medical invoice information governance based on rule-based and vector collaboration. Background Technology

[0002] With the advancement of medical informatization, the volume of medical invoice data has exploded. However, due to inconsistent data entry standards among different medical institutions and at different times, the same medical entity often appears in various non-standard forms on invoices, which seriously restricts the development of applications such as data statistical analysis, medical insurance settlement, and regional health information sharing.

[0003] Existing methods for managing medical invoice information mainly fall into two categories: one is the pure rule-matching method, which normalizes information by writing a large number of regular expressions or string comparison rules. This method has high accuracy on known patterns, but its rule coverage is limited when faced with massive heterogeneous data, its maintenance cost is high, and it is difficult to handle variations such as spelling errors, abbreviations, and aliases; the other is the method based on large language models, which uses deep learning models to directly perform semantic understanding and standardization. Although it has strong generalization ability, it suffers from problems such as high inference cost, slow response speed, and instability in handling long-tail low-frequency entities, making it difficult to meet the needs of large-scale real-time governance.

[0004] Therefore, there is an urgent need for an intelligent management solution for medical invoice information that can guarantee high accuracy, take into account processing efficiency, and have good scalability. Summary of the Invention

[0005] To address the aforementioned technical problems, this invention proposes a method and system for medical invoice information governance based on rule-based and vector-based collaboration.

[0006] The technical solution of this invention is as follows: This invention proposes a medical invoice information governance method based on rule-based and vector collaboration, comprising the following steps: Construct a standard knowledge base containing multiple medical entities, each of which includes a standard name, multidimensional structured attributes, and corresponding semantic vector embeddings; Acquire the medical invoice data to be processed and perform preprocessing; The preprocessed invoice data is normalized based on a standard knowledge base. Different normalization sub-processes are used for information at different semantic levels, and each sub-process is executed in the following order for hierarchical matching: The first level performs an exact match based on string equality comparison; The second level performs matching based on edit distance or word segmentation inclusion tolerance rules for fields that fail to match precisely; The third level involves performing semantic vector matching on fields where the fault tolerance rule fails to match, by calculating the similarity between the semantic vector and the entity vector in the standard knowledge base. At the fourth level, for fields where semantic vector matching fails, the large language model is invoked to output the standard name and confidence score. Based on the results of normalization governance, the standardized fields of the medical invoice data to be governed and their corresponding standard codes are output.

[0007] Preferably, the preprocessing includes at least one of the following operations: Perform optical character recognition on the ticket image to extract text information; Standardize the format of the extracted text information, and unify the writing format of dates, amounts, and numbers; The text information is segmented into fields, dividing unstructured text into multiple fields to be managed; Perform spell correction or simplified / traditional conversion on the partitioned fields.

[0008] Preferably, the construction of the standard knowledge base includes: Horizontal dimension construction: Associate multi-dimensional structured attributes with each medical entity, including at least one of the following: code, alias, classification information, geographic location, and specification parameters; Vertical dimension construction: Through network information collection and cleaning services, new entities are extracted from unstructured text and multi-source data alignment is completed to continuously expand the scale of entity coverage; Vectorization enhancement: Semantic encoding is performed on the text description of each medical entity to generate high-dimensional vector embeddings that are stored in a standard knowledge base.

[0009] Preferably, the normalization sub-process includes the following steps for normalizing department names: Determine whether the input field belongs to department information based on a preset keyword table; Entries from non-clinical departments are filtered based on an exclusion thesaurus. Noise cleaning is performed on the retained fields, irrelevant characters are removed, and delimiters are processed; The cleaned fields are compared with the department's standard database for string equality. For fields that fail the equivalent comparison, perform Chinese word segmentation, and perform fragment inclusion matching based on the word segmentation results and the standard knowledge base; For fields containing failed matches, calculate the edit distance with the entity's standard name in the standard knowledge base. A match is determined when the edit distance is 1 and the difference is caused by only one character deletion operation. For fields where the edit distance match fails, the large language model is invoked to output the standard department name and confidence score; Fields with confidence levels below the threshold are sent to the manual review queue, and the review results are fed back to the standard knowledge base.

[0010] Preferably, the normalization sub-process includes the following steps for normalizing drug names: Perform name standardization preprocessing on the original drug text; String equality comparison based on drug standard library; For fields that fail to match, extract at least one attribute from the original drug text: product name, specifications, dosage form, manufacturer, and drug identification code. The extracted attributes are combined with multiple attributes in the standard knowledge base for joint disambiguation. The joint disambiguation includes: if multiple candidate entities share a certain attribute, then the attribute is determined as a governed attribute; if multiple candidates still exist, they are weighted and sorted according to preset attribute priorities, and the optimal candidate is selected. If no single candidate is found after joint disambiguation, the large language model is invoked to output the standard drug name and confidence level. Fields with confidence levels below the threshold are sent to the manual review queue, and the review results are fed back to the standard knowledge base.

[0011] Preferably, in the joint disambiguation, when multiple candidate entities share the same attribute, the attribute is deemed to have been successfully managed and recorded as the standardized value of the attribute, thus achieving partial normalization.

[0012] Preferably, automated batch processing procedures are also included: The data access layer writes the data of the invoices to be processed into the task table; The governance execution layer adopts a distributed timed task framework to execute normalized governance in parallel; The results distribution layer distributes the governance results to the success table or the pending manual review table according to confidence level and matching path, and updates the task status.

[0013] On the other hand, the present invention also provides a medical invoice information governance system based on rule-based and vector collaboration, comprising: The knowledge base construction module builds a standard knowledge base containing multiple medical entities. Each medical entity includes a standard name, multi-dimensional structured attributes, and corresponding semantic vector embeddings. The data acquisition and preprocessing module acquires the medical invoice data to be processed and performs preprocessing. The normalization governance module performs normalization governance on the preprocessed invoice data based on a standard knowledge base. This normalization governance employs different normalization sub-processes for information at different semantic levels, and each normalization sub-process is executed in the following order for hierarchical matching: The first level performs an exact match based on string equality comparison; The second level performs matching based on edit distance or word segmentation inclusion tolerance rules for fields that fail to match precisely; The third level involves performing semantic vector matching on fields where the fault tolerance rule fails to match, by calculating the similarity between the semantic vector and the entity vector in the standard knowledge base. At the fourth level, for fields where semantic vector matching fails, the large language model is invoked to output the standard name and confidence score. The results output module, based on the results of normalization governance, outputs the standardized fields of the medical invoice data to be governed and their corresponding standard codes.

[0014] In another aspect, the present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement a rule-based and vector-based collaborative method for medical invoice information management as described in any embodiment of the present invention.

[0015] In another aspect, the present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements a rule-based and vector-based collaborative method for managing medical invoice information as described in any embodiment of the present invention.

[0016] The present invention has the following beneficial effects: 1. Through a four-level progressive matching strategy, high-precision rule matching is used first to process most of the regular data, then semantic vector matching is used to cover synonymous and heterogeneous expressions, and finally a large language model is used to handle difficult samples. The actual matching success rate is significantly better than that of single rule or single model solutions.

[0017] 2. Both rule matching and vector matching are lightweight operations. Only a small number of difficult samples need to call the large language model, which greatly reduces the consumption of computing resources and reasoning costs, and supports the batch management of millions of invoice data per day.

[0018] 3. Differentiated normalized sub-processes are designed for information at different semantic levels, such as departments and medicines, which can flexibly adapt to the governance needs of various medical entities; the standard knowledge base supports horizontal dimension expansion and vertical dimension incremental updates to achieve sustainable evolution.

[0019] 4. Through a closed-loop manual review mechanism, the review conclusions of low-confidence results are fed back to the standard knowledge base, continuously enriching entity aliases and attribute information, forming a positive cycle of "governance-feedback-optimization".

[0020] 5. Provides a complete batch processing pipeline, supports distributed parallel processing and automatic result distribution, greatly reduces manual intervention and lowers operation and maintenance costs. Attached Figure Description

[0021] Figure 1 This is a flowchart of the method of the present invention. Detailed Implementation

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

[0023] It should be understood that the step numbers used in the text are for ease of description only and are not intended to limit the order in which the steps are performed.

[0024] It should be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0025] The terms “comprising” and “including” indicate the presence of the described feature, whole, step, operation, element and / or component, but do not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components and / or collections thereof.

[0026] The term “and / or” refers to any combination of one or more of the associated listed items, as well as all possible combinations, and includes these combinations.

[0027] Example 1: To make the objectives, technical solutions, and advantages of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below in conjunction with specific embodiments of the present application and with reference to the accompanying drawings.

[0028] To address the problems in existing technologies, this embodiment provides a method for medical invoice information governance based on rule-based and vector collaboration, comprising the following steps: Construct a standard knowledge base containing multiple medical entities, each of which includes a standard name, multidimensional structured attributes, and corresponding semantic vector embeddings; In this embodiment, taking the "Hospital Standard Library" as an example, each hospital entity not only includes the full standard name (such as "XX Provincial Hospital"), but also is associated with multi-dimensional structured attribute fields, including: the National Unified Medical Institution Code (based on the "Medical Institution Practice License"), administrative affiliation information (province, city, district / county), geographical coordinates (longitude, latitude, supporting GIS location verification), official registered address and a list of commonly used abbreviations (such as "Provincial" or "Provincial Hospital"), medical insurance designation type (such as "Grade III Class A"), number of departments, and number of physicians. These attributes together constitute the multi-dimensional feature anchor points of the entity, significantly improving matching robustness.

[0029] As a preferred embodiment of this invention, the standard knowledge base construction process is divided into three dimensions: Horizontal dimension construction: Multi-dimensional structured attributes are associated with each medical entity. For example, for a drug entity, associated attributes include national drug code, generic name, brand name, specifications (e.g., 0.25g × 12 tablets), dosage form (tablets, capsules), manufacturer, and approval number; for a department entity, associated attributes include department code, standard name, list of aliases, affiliated hospital level, and geographical location. Attributes can be flexibly expanded according to actual business needs.

[0030] Vertical dimension construction: Through network information collection and cleaning services, new entities are extracted from unstructured text (such as hospital websites, drug instructions, and public databases), and multi-source data alignment is completed. For example, different descriptions of the same drug are collected from different sources, cleaned, deduplicated, and merged before being added to a standard knowledge base, continuously expanding the scale of entity coverage.

[0031] Vectorization enhancement: Semantic encoding is performed on the text description of each medical entity (such as text composed of standard name, alias, and key attributes). A pre-trained medical BERT model is used to generate high-dimensional vector embeddings, such as 768-dimensional vectors. These high-dimensional vector embeddings are stored as part of the standard knowledge base for subsequent semantic similarity retrieval.

[0032] Based on the above construction method, the following eight core standard libraries have been built and are continuously maintained: Traditional Chinese Medicine Standards Database: Includes generic name, trade name, dosage form, and specifications; Chemical Drug (Western Medicine) Standard Library: Includes generic name, trade name, dosage form, specifications, and ATC classification; Chinese Herbal Medicine Standards Database: Includes official names and alternative names of medicinal materials; Medical Consumables Standard Library: Includes medical insurance consumable codes, category names, and specifications; Standardized Medical Service Item Library: Includes codes and operational definitions for related medical service price items; ICD-10 Disease Diagnostic Criteria Library: Includes full codes and standard names; Medical Institution Standards Database: Includes hospitals, community centers, and clinics at all levels, covering more than 98% of designated institutions nationwide; Departmental Standards Library: Establishes a hierarchical relationship between hospitals and departments, supporting the unification of departments across hospitals, such as "Cardiology". "Cardiovascular Medicine"; The drug standard library is composed of the standard library of traditional Chinese medicine preparations, the standard library of chemical drugs (Western medicines), and the standard library of Chinese herbal medicines.

[0033] Extract code tables from the standard library to assist the subsequent normalization process, for example, specification code table, dosage form code table, manufacturer code table, generic name code table of drugs, non-deletable parenthesis library, and non-deletable bracket library. There is also a non-item detail library extracted from bill information, and an artificially maintained item major category mapping table.

[0034] Obtain medical bill data to be processed and perform preprocessing; As a preferred embodiment of this example, the preprocessing includes at least one of the following operations: Perform Optical Character Recognition (OCR) on the bill image to extract the text information therein; Perform format standardization on the extracted text information, unify the date format (for example, unify to YYYY-MM-DD), the amount format (retain two decimal places), and the number format (convert full-width characters to half-width characters); Perform field segmentation on the text information, and divide the unstructured text into a plurality of fields to be processed according to preset separators or layout analysis, such as department name, drug name, diagnosis and treatment item, diagnosis name, etc.; Perform spelling correction or simplified-traditional character conversion on the divided fields to improve the accuracy of subsequent matching.

[0035] Perform normalization processing on the preprocessed bill data based on the standard knowledge base. The normalization processing adopts different normalization sub-processes for information of different semantic levels. The different semantic levels include multiple semantic levels such as department, drug, diagnosis and treatment item, disease diagnosis, etc., and each normalization sub-process performs step-by-step matching in the following order: At the first level, perform exact matching based on string equivalence comparison; specifically: perform completely consistent string comparison between the field to be processed and the standard name of the corresponding entity in the standard knowledge base. For example, if the field "Respiratory Medicine Department" is completely consistent with "Respiratory Medicine Department" in the standard library, the matching is directly successful, and the standard code is returned.

[0036] At the second level, perform fault-tolerant rule matching based on edit distance or word segmentation inclusion on fields that fail exact matching; specifically: edit distance matching is applicable to cases with a small number of character differences, for example, the edit distance between "Respiratory Medicine Department" (with a typo) and the standard "Respiratory Medicine Department" is 1, which can be determined as a match. Word segmentation inclusion matching is applicable to cases where the field contains a substring of the standard name or vice versa, for example, "Respiratory Medicine Department of Peking University Third Hospital" contains "Respiratory Medicine Department" after word segmentation, so it can be matched.

[0037] The third level involves semantic vector matching for fields where the fault-tolerance rule fails to match. This is achieved by calculating the similarity between the semantic vector and the entity vectors in the standard knowledge base. Specifically, the field to be addressed is input into the same semantic encoding model to obtain a query vector. Then, an approximate nearest neighbor search is performed on the vectorized data in the standard knowledge base to find the top K candidate entities with the highest similarity. If the highest similarity exceeds a preset threshold (0.85 in this embodiment), the candidate is adopted.

[0038] At the fourth level, for fields where semantic vector matching fails, the large language model is invoked to output the standard name and confidence score. Specifically, the field to be addressed and contextual information are assembled into a prompt word, and the large language model is requested to provide a standardized name and its confidence score. For example, for rare aliases or abbreviations, inference is performed using the extensive medical knowledge of the large language model.

[0039] Furthermore, regarding the normalization of department names, the following refinements are made within the hierarchical matching framework: The system uses a pre-defined keyword list to determine whether an input field belongs to a department. For example, if the keyword list contains words such as "department," "room," or "center," then the field is initially identified as a department.

[0040] This avoids mismatches by filtering out non-clinical department entries, such as "cashier office," "registration office," and "pharmacy," from the exclusion thesaurus.

[0041] Noise cleaning is performed on the retained fields, removing irrelevant characters (such as spaces and special symbols) and delimiters (such as splitting "Respiratory Medicine / Outpatient" into "Respiratory Medicine" and "Outpatient").

[0042] The cleaned fields are compared with the department's standard library for string equality.

[0043] For fields that fail the equivalence comparison, perform Chinese word segmentation, and perform fragment inclusion matching based on the word segmentation results and the entity standard names in the standard knowledge base.

[0044] For fields containing failed matches, calculate the edit distance with the standard entity name in the standard knowledge base. When the edit distance is 1 and the difference is caused by only one character deletion operation, such as the difference between "Respiratory Medicine" and "Respiratory Medicine Department" being the deletion of the character "department", it is determined to be a match.

[0045] For fields where the edit distance match fails, the large language model is invoked to output the standard department name and confidence level.

[0046] Fields with confidence levels below a threshold are sent to a manual review queue, and the review results are fed back to the standard knowledge base, enabling the knowledge base to evolve on its own.

[0047] Furthermore, regarding the normalization of drug names, the following refinements are made within the hierarchical matching framework: The original drug names are preprocessed to standardize their names, such as removing extra spaces, unifying capitalization, and converting to traditional Chinese characters.

[0048] String equality comparison is performed based on a drug standard library. Each entity in the drug standard library contains a standard name and multiple aliases. A match is successful if a field is exactly the same as any standard name or alias.

[0049] For fields that fail to match the equivalent value, at least one attribute from the original drug text is extracted in a structured manner, including the brand name, specifications, dosage form, manufacturer, and drug identification code. For example, for the text "Amoxicillin Capsules 0.5g 24 capsules (Federal Pharmaceuticals)," the brand name "Amoxicillin," the dosage form "capsules," the specifications "0.5g 24 capsules," and the manufacturer "Federal Pharmaceuticals" can be extracted.

[0050] Joint disambiguation is performed using extracted attributes and multiple attributes from a standard knowledge base. Joint disambiguation includes: if multiple candidate entities share a certain attribute (e.g., they all come from the same manufacturer), then that attribute is identified as a managed attribute; if multiple candidates still exist, they are weighted and sorted according to a preset attribute priority, such as drug identification code > manufacturer > specification > dosage form, and the optimal candidate is selected.

[0051] Furthermore, the joint disambiguation step also includes a partial normalization step. When multiple candidate entities share the same attribute, the attribute is considered successfully treated and recorded as its standardized value. For example, for the drugs "Cefixime Dispersible Tablets 50mg (Guangzhou Baiyunshan)" and "Cefixime Tablets 50mg (Guangzhou Baiyunshan)," if it cannot be determined whether it is a "dispersible tablet" or a "tablet," but both originate from "Guangzhou Baiyunshan," then the manufacturer "Guangzhou Baiyunshan" can be identified as a treated attribute, achieving partial normalization. Further disambiguation can then be achieved by combining other information.

[0052] If no single candidate is found after joint disambiguation, the large language model is invoked to output the standard drug name and its confidence level. For example, for drugs with the same ingredients but different brand names, the large language model can determine the most likely standard name based on the context.

[0053] Fields with confidence levels below the threshold are sent to the manual review queue, and the review results are fed back to the standard knowledge base.

[0054] For other semantic levels such as treatment items and disease diagnosis, the above approach can be used as a reference to design corresponding normalization sub-processes based on the attribute characteristics of their respective entities, which will not be elaborated here.

[0055] Based on the results of normalization governance, the standardized fields of the medical invoice data to be governed and their corresponding standard codes are output.

[0056] As a preferred embodiment of this invention, to achieve automated processing of large-scale invoice data, this method further includes the following batch processing steps: The data access layer writes the data of the invoices to be processed into the task table, and each record carries a unique task ID, original fields, source and other information.

[0057] The governance execution layer employs a distributed timed task framework to execute the aforementioned normalized governance in parallel. Each task runs independently without interfering with others.

[0058] The results distribution layer distributes governance results to either the success table or the pending manual review table based on confidence level and matching path. For example, first-level exact match results are directly written to the success table; low-confidence results from the fourth-level large language model are written to the pending manual review table. Simultaneously, the task status is updated for easy tracking and monitoring.

[0059] Example 2: This embodiment provides a medical invoice information governance system based on rule-based and vector collaboration, including: The knowledge base construction module builds a standard knowledge base containing multiple medical entities. Each medical entity includes a standard name, multi-dimensional structured attributes, and corresponding semantic vector embeddings. The data acquisition and preprocessing module acquires the medical invoice data to be processed and performs preprocessing. The normalization governance module performs normalization governance on the preprocessed invoice data based on a standard knowledge base. This normalization governance employs different normalization sub-processes for information at different semantic levels, and each normalization sub-process is executed in the following order for hierarchical matching: The first level performs an exact match based on string equality comparison; The second level performs matching based on edit distance or word segmentation inclusion tolerance rules for fields that fail to match precisely; The third level involves performing semantic vector matching on fields where the fault tolerance rule fails to match, by calculating the similarity between the semantic vector and the entity vector in the standard knowledge base. At the fourth level, for fields where semantic vector matching fails, the large language model is invoked to output the standard name and confidence score. The results output module, based on the results of normalization governance, outputs the standardized fields of the medical invoice data to be governed and their corresponding standard codes.

[0060] Example 3: This embodiment proposes an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements a medical invoice information governance method based on rule and vector collaboration as described in any embodiment of the present invention.

[0061] Example 4: This embodiment proposes a computer-readable storage medium storing a computer program that, when executed by a processor, implements a rule-based and vector-based collaborative method for managing medical invoice information as described in any embodiment of the present invention.

[0062] In this application embodiment, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent the existence of A alone, A and B simultaneously, or B alone. A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" and similar expressions refer to any combination of these items, including any combination of singular or plural items. For example, at least one of a, b, and c can represent: a, b, c, a and b, a and c, b and c, or a and b and c, where a, b, and c can be single or multiple.

[0063] Those skilled in the art will recognize that the units and algorithm steps described in the embodiments disclosed herein can be implemented using electronic hardware, computer software, or a combination of electronic hardware and software. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0064] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0065] In the several embodiments provided in this application, any function, if implemented as a software functional unit and sold or used as an independent product, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0066] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent structural or procedural transformations made based on the content of the present invention's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for medical invoice information governance based on rule-based and vector collaboration, characterized in that, Includes the following steps: Construct a standard knowledge base containing multiple medical entities, each of which includes a standard name, multidimensional structured attributes, and corresponding semantic vector embeddings; Acquire the medical invoice data to be processed and perform preprocessing; The preprocessed invoice data is normalized based on a standard knowledge base. Different normalization sub-processes are used for information at different semantic levels, and each sub-process is executed in the following order for hierarchical matching: The first level performs an exact match based on string equality comparison; The second level performs matching based on edit distance or word segmentation inclusion tolerance rules for fields that fail to match precisely; The third level involves performing semantic vector matching on fields where the fault tolerance rule fails to match, by calculating the similarity between the semantic vector and the entity vector in the standard knowledge base. At the fourth level, for fields where semantic vector matching fails, the large language model is invoked to output the standard name and confidence score. Based on the results of normalization governance, the standardized fields of the medical invoice data to be governed and their corresponding standard codes are output.

2. The medical invoice information governance method based on rule-based and vector collaboration according to claim 1, characterized in that: The preprocessing includes at least one of the following operations: Perform optical character recognition on the ticket image to extract text information; Standardize the format of the extracted text information, and unify the writing format of dates, amounts, and numbers; The text information is segmented into fields, dividing unstructured text into multiple fields to be managed; Perform spell correction or simplified / traditional conversion on the partitioned fields.

3. The medical invoice information governance method based on rule-based and vector collaboration according to claim 1, characterized in that: The construction of the standard knowledge base includes: Horizontal dimension construction: Associate multi-dimensional structured attributes with each medical entity, including at least one of the following: code, alias, classification information, geographic location, and specification parameters; Vertical dimension construction: Through network information collection and cleaning services, new entities are extracted from unstructured text and multi-source data alignment is completed to continuously expand the scale of entity coverage; Vectorization enhancement: Semantic encoding is performed on the text description of each medical entity to generate high-dimensional vector embeddings that are stored in a standard knowledge base.

4. The medical invoice information governance method based on rule-based and vector collaboration according to claim 1, characterized in that: The normalization sub-process includes the following steps for normalizing department names: Determine whether the input field belongs to department information based on a preset keyword table; Entries from non-clinical departments are filtered based on an exclusion thesaurus. Noise cleaning is performed on the retained fields, irrelevant characters are removed, and delimiters are processed; The cleaned fields are compared with the department's standard database for string equality. For fields that fail the equivalent comparison, perform Chinese word segmentation, and perform fragment inclusion matching based on the word segmentation results and the standard knowledge base; For fields containing failed matches, calculate the edit distance with the entity's standard name in the standard knowledge base. A match is determined when the edit distance is 1 and the difference is caused by only one character deletion operation. For fields where the edit distance match fails, the large language model is invoked to output the standard department name and confidence score; Fields with confidence levels below the threshold are sent to the manual review queue, and the review results are fed back to the standard knowledge base.

5. The medical invoice information governance method based on rule-based and vector collaboration according to claim 1, characterized in that: The normalization sub-process includes the following steps for normalizing drug names: Perform name standardization preprocessing on the original drug text; String equality comparison based on drug standard library; For fields that fail to match, extract at least one attribute from the original drug text: product name, specifications, dosage form, manufacturer, and drug identification code. The extracted attributes are combined with multiple attributes in the standard knowledge base for joint disambiguation. The joint disambiguation includes: if multiple candidate entities share a certain attribute, then the attribute is determined as a governed attribute; if multiple candidates still exist, they are weighted and sorted according to preset attribute priorities, and the optimal candidate is selected. If no single candidate is found after joint disambiguation, the large language model is invoked to output the standard drug name and confidence level. Fields with confidence levels below the threshold are sent to the manual review queue, and the review results are fed back to the standard knowledge base.

6. The medical invoice information governance method based on rule-based and vector collaboration according to claim 5, characterized in that: In the joint disambiguation process, when multiple candidate entities share the same attribute, the attribute is deemed to have been successfully managed and recorded as the standardized value of the attribute, thus achieving partial normalization.

7. The medical invoice information governance method based on rule-based and vector collaboration according to claim 1, characterized in that: It also includes automated batch processing: The data access layer writes the data of the invoices to be processed into the task table; The governance execution layer adopts a distributed timed task framework to execute normalized governance in parallel; The results distribution layer distributes the governance results to the success table or the pending manual review table according to confidence level and matching path, and updates the task status.

8. A medical invoice information governance system based on rule-based and vector collaboration, characterized in that, include: The knowledge base construction module builds a standard knowledge base containing multiple medical entities. Each medical entity includes a standard name, multi-dimensional structured attributes, and corresponding semantic vector embeddings. The data acquisition and preprocessing module acquires the medical invoice data to be processed and performs preprocessing. The normalization governance module performs normalization governance on the preprocessed invoice data based on a standard knowledge base. This normalization governance employs different normalization sub-processes for information at different semantic levels, and each normalization sub-process is executed in the following order for hierarchical matching: The first level performs an exact match based on string equality comparison; The second level performs matching based on edit distance or word segmentation inclusion tolerance rules for fields that fail to match precisely; The third level involves performing semantic vector matching on fields where the fault tolerance rule fails to match, by calculating the similarity between the semantic vector and the entity vector in the standard knowledge base. At the fourth level, for fields where semantic vector matching fails, the large language model is invoked to output the standard name and confidence score. The results output module, based on the results of normalization governance, outputs the standardized fields of the medical invoice data to be governed and their corresponding standard codes.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements a medical invoice information governance method based on rule and vector collaboration as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements a medical invoice information governance method based on rule and vector collaboration as described in any one of claims 1 to 7.

Images