A method, device and storage medium for constructing a medical knowledge graph

Abstract

The embodiments of the present application provide a method, device and storage medium for constructing a medical knowledge graph. Diagnostic entities, medical project entities and the accompanying relationships between diagnostic entities and medical project entities can be extracted from real medical data; based on the accompanying relationships, the affinity of each diagnostic entity to each medical project entity and the affinity of each medical project entity to each diagnostic entity are calculated respectively; according to the affinity, mutual selection operations are performed between the diagnostic entity and the medical project entity to obtain entity pairs that have been successfully selected, thereby constructing a medical knowledge graph. In this way, a dynamic medical knowledge graph can be automatically constructed based on big data, thereby improving the efficiency of constructing the medical knowledge graph; and through the mutual selection between the diagnostic entity and the medical project entity, more representative medical project entities can be accurately and comprehensively selected for the diagnostic entity without any human intervention, so as to ensure the quality of the medical knowledge graph.

Description

Technical Field

[0001] The present application relates to the field of medical technology, and in particular to a method, device and storage medium for constructing a medical knowledge graph. Background Art

[0002] Healthcare is an industry that places a high premium on knowledge and experience, and is highly specialized. Currently, most medical knowledge graphs rely on manual compilation by medical experts. This results in a heavily reliant construction process for medical knowledge graphs, resulting in inefficient construction and insufficient comprehensiveness. Summary of the Invention

[0003] Multiple aspects of the present application provide a method, device, and storage medium for constructing a medical knowledge graph to improve the efficiency and / or quality of constructing the medical knowledge graph.

[0004] This embodiment of the present application provides a method for constructing a medical knowledge graph, including:

[0005] Extracting diagnosis entities, medical item entities, and accompanying relationships between diagnosis entities and medical item entities from a specified range of medical data, wherein the diagnosis entities and medical item entities that appear in the same medical data have accompanying relationships;

[0006] Based on the accompanying relationship, respectively calculating the affinity of each diagnosis entity to each medical project entity and the affinity of each medical project entity to each diagnosis entity;

[0007] Based on the affinity, a mutual selection operation is performed between the diagnosis entity and the medical project entity to obtain a mutually selected entity pair;

[0008] Construct a medical knowledge graph based on the entity pairs that are successfully selected.

[0009] An embodiment of the present application further provides a computing device, including a memory, a processor, and a communication component;

[0010] The memory is used to store one or more computer instructions;

[0011] The processor is coupled to the memory and the communication component and is configured to execute the one or more computer instructions for:

[0012] Extracting diagnosis entities, medical item entities, and accompanying relationships between diagnosis entities and medical item entities from a specified range of medical data, wherein the diagnosis entities and medical item entities that appear in the same medical data have accompanying relationships;

[0013] Based on the accompanying relationship, respectively calculating the affinity of each diagnosis entity to each medical project entity and the affinity of each medical project entity to each diagnosis entity;

[0014] Based on the affinity, a mutual selection operation is performed between the diagnosis entity and the medical project entity to obtain a mutually selected entity pair;

[0015] Construct a medical knowledge graph based on the entity pairs that are successfully selected.

[0016] An embodiment of the present application also provides a computer-readable storage medium storing computer instructions. When the computer instructions are executed by one or more processors, the one or more processors are caused to execute the aforementioned medical knowledge graph construction method.

[0017] In the embodiment of the present application, based on real medical data, diagnosis entities, medical project entities and the accompanying relationship between diagnosis entities and medical project entities are extracted; on this basis, the affinity of each diagnosis entity to each medical project entity and the affinity of each medical project entity to each diagnosis entity can be calculated based on the accompanying relationship; according to the affinity, mutual selection operations are performed between the diagnosis entity and the medical project entity to obtain entity pairs that have been successfully selected; according to the entity pairs that have been successfully selected, a medical knowledge graph is constructed. In this way, a dynamic medical knowledge graph can be automatically constructed based on big data, thereby improving the efficiency of constructing the medical knowledge graph; and through the mutual selection between the diagnosis entity and the medical project entity, more representative medical project entities can be accurately and comprehensively selected for the diagnosis entity without any human intervention, so as to ensure the quality of the medical knowledge graph. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0019] Figure 1 A flowchart of a method for constructing a medical knowledge graph provided as an exemplary embodiment of the present application;

[0020] Figure 2 A logical diagram of a method for constructing a medical knowledge graph provided as an exemplary embodiment of the present application;

[0021] Figure 3 A schematic diagram of a diagnostic association diagram provided by an exemplary embodiment of the present application;

[0022] Figure 4 A schematic diagram of a constructed medical knowledge graph provided by an exemplary embodiment of the present application;

[0023] Figure 5 A schematic structural diagram of a computing device provided as another exemplary embodiment of the present application. DETAILED DESCRIPTION

[0024] To make the purpose, technical solutions, and advantages of this application more clear, the technical solutions of this application will be clearly and completely described below in conjunction with the specific embodiments of this application and the corresponding drawings. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0025] At present, it is usually necessary to rely on medical experts to manually organize and construct medical knowledge graphs, which is not efficient and comprehensive enough. To this end, in some embodiments of the present application: based on real medical data, diagnosis entities, medical project entities and the accompanying relationships between diagnosis entities and medical project entities are extracted; on this basis, the affinity of each diagnosis entity to each medical project entity and the affinity of each medical project entity to each diagnosis entity can be calculated based on the accompanying relationships; according to the affinity, mutual selection operations are performed between the diagnosis entity and the medical project entity to obtain entity pairs that have been successfully selected; and according to the entity pairs that have been successfully selected, a medical knowledge graph is constructed. In this way, a dynamic medical knowledge graph can be automatically constructed based on big data, thereby improving the efficiency of medical knowledge graph construction; and through the mutual selection between diagnosis entities and medical project entities, more representative medical project entities can be accurately and comprehensively selected for the diagnosis entity without any human intervention, so as to ensure the quality of the medical knowledge graph.

[0026] The following describes in detail the technical solutions provided by various embodiments of the present application in conjunction with the accompanying drawings.

[0027] Figure 1 A flowchart of a method for constructing a medical knowledge graph provided in an exemplary embodiment of this application is provided. Figure 2 A logical diagram of a method for constructing a medical knowledge graph provided by an exemplary embodiment of the present application. The method can be executed by a data processing device, which can be implemented as a combination of software and / or hardware, and the data processing device can be integrated into a computing device. Figure 1 , the method may include:

[0028] Step 100: Extract diagnosis entities, medical item entities, and accompanying relationships between diagnosis entities and medical item entities from a specified range of medical data, wherein diagnosis entities and medical item entities that appear in the same medical data have accompanying relationships;

[0029] Step 101: Based on the adjoint relationship, the affinity of each diagnosis entity to each medical project entity and the affinity of each medical project entity to each diagnosis entity are calculated respectively;

[0030] Step 102: Perform a mutual selection operation between the diagnosis entity and the medical item entity based on affinity to obtain a mutually selected entity pair;

[0031] Step 103: Construct a medical knowledge graph based on the entity pairs that are successfully selected.

[0032] The method for constructing the medical knowledge graph provided in this embodiment can be applied in the medical field, mainly for medical institutions or health management and services, providing dynamic medical knowledge graphs for these scenarios as the service basis in these scenarios.

[0033] In this embodiment, each visit by a patient generates medical data, which can record relevant information about the visit. In this embodiment, common medical records such as medical records can be used as medical data. These medical records typically record the patient's disease manifestations and the treatment status of the visit in accordance with regulations. This ensures that the medical data in this embodiment contains rich and comprehensive information related to the visit, providing a strong data foundation for the construction of the medical knowledge graph.

[0034] Based on this, reference Figure 1 and Figure 2 In step 100, diagnosis entities, medical item entities, and the accompanying relationships between diagnosis entities and medical item entities can be extracted from the medical data within a specified range. The medical data within the specified range can be medical data occurring within a specified time range, for example, medical data occurring within the past six months.

[0035] Ideally, all information in the medical data of a visit is recorded according to specifications and standards. In this case, diagnosis entities and medical item entities can be extracted quickly and easily from the medical data of a visit. The diagnosis entity is used to represent the diagnosis results that occur during the medical visit. There may be multiple diagnosis entities in the medical data generated by a single visit. In this embodiment, all diagnosis entities contained in the medical data of the visit can be extracted. The medical item entity is used to represent the medical means consumed during the medical visit, which can usually be reflected in the billing details. There may be multiple medical item entities in the medical data generated by a single visit. In this embodiment, all medical item entities contained in the medical data of the visit can be collected. In this way, in this embodiment, a collection of diagnosis entities and medical item entities can be obtained for each medical data of the visit. In this embodiment, it is considered that there is a companion relationship between the diagnosis entity and the medical item entity that appear in the medical data generated by the same visit.

[0036] However, in actual applications, the inventors found that the same diagnosis may be recorded using multiple different names in different regions, different medical institutions, or even the same medical institution at different times. For example, different diagnosis versions, such as different versions of ICD10, may be used in different regions or medical institutions, or non-standard diagnoses may be used when registering and entering diagnoses. The same medical project may also be recorded using multiple different names. For example, different regions or medical institutions may have different medical project libraries, or different names may be used for the same project. This leads to the problem of naming diversity in diagnosis entities and medical project entities in medical data, which will affect the effectiveness of entity extraction and, in turn, the accuracy of the data and the knowledge graph.

[0037] To this end, this embodiment proposes that diagnosis names and medical project names can be extracted from medical data; the diagnosis names and medical project names are normalized separately to obtain diagnosis entities and medical project entities. That is, different diagnosis names corresponding to the same diagnosis entity (written differently or using different diagnosis versions) can be normalized to a unified diagnosis entity name, and different medical project names corresponding to the same medical project entity can be normalized to a unified medical project entity name. In this way, different diagnosis names that appear for the same diagnosis in the medical data can be extracted as the same diagnosis entity, and different medical project names that appear for the same medical project in the medical data can be extracted as the same medical project entity. For example, the diagnosis name "Hypertension Grade I" in the medical data will be normalized to the diagnosis entity "Hypertension", and the diagnosis name "Hypertension Grade I" will also be normalized to the diagnosis entity "Hypertension".

[0038] Here, there may be two situations:

[0039] In one case, if there is a standard name directory in the scenario, then in this embodiment, the diagnosis name and medical project name extracted from the medical treatment data can be normalized to the standard name. For a certain extracted diagnosis name, an exemplary solution may be: in the standard name directory, find a standard name that is completely consistent with the diagnosis name. If it exists, the diagnosis name can be normalized to the standard name; if it does not exist, the longest common subsequence method can be used to calculate the similarity between the diagnosis name and each standard name in the standard name directory, and the diagnosis name can be normalized to the standard name with the highest similarity to the diagnosis name. Among them, the longest common subsequence method can refer to using the length of the longest character sequence commonly contained between the two character strings to measure the similarity between the two character strings. In the same way, the extracted medical project names can be normalized. For the extracted medical project names, the same solution as the diagnosis name can be used to achieve normalization, which will not be repeated here.

[0040] In another scenario, if a standard name directory does not exist in the scenario, this embodiment proposes an exemplary implementation method for self-clustering to achieve normalization of diagnosis names and medical project names. In this implementation method: for diagnosis names, the similarity between each other can be calculated; the diagnosis names are clustered based on the similarity to obtain multiple independent diagnosis name sets; and each diagnosis name in the same diagnosis name set is normalized to a unified diagnosis entity. The similarity measurement performed here can cover all diagnosis names extracted from the medical treatment data. The similarity measurement method can use the longest common subsequence method mentioned above. For example, the length of the longest common subsequence between two diagnosis names can be calculated, and the ratio between the calculated length and the average string length of the two diagnosis names can be used as the similarity, or the ratio between the calculated length and the length of the longest string in the two diagnosis names can be used as the similarity. An exemplary clustering scheme can be: if the similarity between two diagnosis names exceeds a given threshold, an associated edge can be created between the two diagnosis names, thereby linking similar diagnosis names and constructing a diagnosis association graph. Figure 3 A schematic diagram of a diagnostic correlation diagram provided by an exemplary embodiment of the present application, with reference to Figure 3 In the diagnosis association graph, there are associated edges between similar diagnosis names; the diagnosis association graph will contain multiple non-connected subgraphs (such as Figure 3 There are 2 subgraphs in it), each subgraph corresponds to a set of diagnosis names mentioned above.

[0041] In this implementation, the clustering results based on similarity can be further optimized during the clustering process. One exemplary optimization dimension can be determining whether two diagnostic names whose similarity meets the clustering requirements correspond to the same body part / organ / tissue / structure, etc. If not, the clustering relationship between the two diagnostic names is broken. Here, the body part can refer to a body part. For example, although the similarity between the two diagnostic names "kidney cancer" and "lung cancer" meets the clustering requirements, the two diagnostic names correspond to different body parts (one is the kidney and the other is the lung). Therefore, the two diagnostic names are not clustered. Another exemplary optimization dimension can be removing non-discriminative characters from each diagnostic name to obtain a simplified name; and calculating the similarity between the diagnostic names based on the simplified names corresponding to each diagnostic name. A word segmentation tool can be used to segment each diagnostic name, and the frequency of occurrence of each segmentation is calculated. The k most frequent segmentations are considered non-discriminative characters. Of course, for accuracy, manual verification can be introduced to ensure the rationality of the selected non-discriminative characters. For example, the character "chronic" in "chronic kidney disease" and the character "disease" in "hypertension" are non-distinctive characters. By removing these non-distinctive characters before measuring similarity, we can avoid the problem of increased similarity due to an excessive number of non-distinctive characters in the diagnosis name, effectively improving the accuracy and rationality of the similarity measurement. By optimizing the similarity-based clustering results, we can effectively improve the accuracy of the diagnosis name set, and thus the accuracy of the normalized results.

[0042] In this implementation, the number of visits to the clinic corresponding to each diagnosis name in the same diagnosis name set can be counted; the diagnosis name with the largest number of visits is used as the normalized diagnosis entity name of the diagnosis name set. Figure 3 Based on the numbers under each diagnosis name in the diagnostic association graph and the corresponding number of visits, the left subgraph can be normalized to "hypertension" and the right subgraph to "diabetes." Of course, the normalization result can also be the diagnosis name with the shortest string length; the diagnosis name corresponding to the median number of visits can also be used as the normalization result, and so on. The extracted medical item names can be normalized using the same method as the diagnosis names, so I will not repeat it here.

[0043] In this way, regardless of the above situation, this embodiment can use an appropriate normalization scheme to accurately extract diagnosis entities, medical item entities, and the accompanying relationship between diagnosis entities and medical item entities from the medical data. In subsequent steps, the relevant processing logic will also be executed according to the normalized diagnosis entities and medical item entities.

[0044] Furthermore, as mentioned above, a single medical visit may contain multiple diagnosis entities and multiple medical item entities within the medical data. Therefore, extracting the accompanying relationships between diagnosis entities and medical item entities from the medical data does not distinguish which medical item entities are consumed by each diagnosis entity. Instead, it simply records which diagnosis entities and which diagnosis item entities appear in the same medical visit. In subsequent steps of this embodiment, based on the accompanying relationships, the medical item entities that should be associated with each diagnosis entity are precisely determined.

[0045] refer to Figure 1 and Figure 2 In step 101, based on the adjoint relationships, the affinity of each diagnosis entity to each medical project entity and the affinity of each medical project entity to each diagnosis entity can be calculated. It should be emphasized that for a diagnosis entity and a medical project entity, the affinity of the diagnosis entity to the medical project entity and the affinity of the medical project entity to the diagnosis entity are different. Affinity can be understood as support.

[0046] An exemplary affinity calculation method may be: based on the accompanying relationship, calculating the proportion of the number of visits in which the target medical project entity was used and diagnosed as the target diagnosis entity in the total number of visits corresponding to the target diagnosis entity, as the affinity of the target medical project entity to the target diagnosis entity; based on the accompanying relationship, calculating the proportion of the number of visits in which the target medical project entity was used and diagnosed as the target diagnosis entity in the total number of visits in which the target medical project entity was used, as the affinity of the target diagnosis entity to the target medical project entity. The target diagnosis entity may be any extracted diagnosis entity, and the target medical project entity may be any extracted medical project entity. In this exemplary calculation method, the affinity is calculated using a conditional probability method. In this exemplary calculation method, the affinity of the target medical project entity x to the target diagnosis entity d can be represented as P(x|d) = the number of visits where the medical project entity x was used and the diagnosis was the target diagnosis entity d / the number of visits where the diagnosis was the target diagnosis entity d; and the affinity of the target diagnosis entity d to the target medical project entity x can be represented as P(d|x) = the number of visits where the medical project entity x was used and the diagnosis was the target diagnosis entity d / the number of visits where the medical project entity x was used. Of course, in this embodiment, other implementation methods can also be used to calculate the affinity, and this embodiment is not limited thereto.

[0047] On this basis, reference Figure 1 and Figure 2In step 102, a mutual selection operation can be performed between the diagnosis entity and the medical project entity based on the affinity to obtain an entity pair that has successfully been mutually selected. In this step, if the target diagnosis entity and the target medical entity meet the preset affinity mutual selection criteria, it can be determined that the mutual selection between the target diagnosis entity and the target medical project entity is successful. The affinity mutual selection criteria can be, for example, that the two affinities are respectively higher than the specified criteria, the sum of the two affinities is higher than the specified criteria, etc. In this way, optionally, if the affinity of the target diagnosis entity to the target medical project entity and the affinity of the target medical project entity to the target diagnosis entity meet the preset affinity mutual selection criteria, it is determined that the target diagnosis entity and the target medical project have successfully been mutually selected.

[0048] However, the inventors found in the course of their research that, during the mutual selection process, some medical project entities that appear less frequently but are very discriminatory for diagnostic entities may fail to be mutually selected due to low affinity, resulting in unreasonable results after the mutual selection. For this reason, the further optimization scheme provided in this embodiment proposes to introduce project classification to improve this problem. In the optimization scheme: the target project type to which the target medical project entity belongs can be determined among multiple specified project types; if the affinity of the target diagnostic entity to the target medical project entity and the affinity of the target medical project entity to the target diagnostic entity meet the affinity mutual selection criteria of the target diagnostic entity under the target project type, it is determined that the target diagnostic entity and the target medical project have successfully mutually selected. The project types specified in this embodiment may include but are not limited to drugs, surgical operations, inspections, tests, consumables, treatments and nursing, etc. It should be understood that these project types are exemplary, and in this embodiment, project types can be added, deleted, or modified as needed.

[0049] Although the expense details included in medical treatment data may contain a medical item expense type field, there are two problems: the first is that the value of this field in the actual data has a low accuracy rate and a high error rate, which seriously affects the accuracy of the calculation. For example, there are multiple items of different categories with the expense type of "other fees"; the second is that the classification system of this field is inconsistent with the classification system of the knowledge graph. At the same time, the classification systems of different cities and medical institutions are inconsistent. Therefore, it is necessary to establish a unified scenario for the knowledge graph. For example, "drugs" are divided into "reimbursable", "partially reimbursable" and "non-reimbursable". This method is suitable for reimbursement scenarios but not for unified knowledge graph scenarios. For example, different regions have different subdivisions under the "laboratory test" category. This leads to insufficient accuracy when determining the item type based on the medical item expense category field.

[0050] To ensure the correct identification of the project type for each medical project entity, the optimization solution also proposes extracting descriptive text related to the target medical project entity from the medical data; inputting this descriptive text into a pre-set classification model; and outputting the target project type to which the target medical project entity belongs based on the mapping relationship between the descriptive text and the project type. This classification model effectively ensures the accuracy of the classification of medical project entities. In this optimization solution, the classification model can be pre-trained. During the training process, descriptive text samples of several medical project entities are collected and labeled to indicate their corresponding project type. The labeled descriptive text samples are then fed into the classification model, allowing it to learn the mapping relationship between the descriptive text and the project type. The descriptive text may include, but is not limited to, information describing the medical project entity, such as name, price, specifications, and model number. It is worth noting that the present embodiment does not limit the timing of determining the project type of a medical project entity. The process may be to classify the medical project name into the project type after extracting the medical project name from the medical data, and to pass the classification result to the medical project entity obtained after normalization; or, after normalization is completed, to determine the project type of the medical project entity based on the descriptive text corresponding to each medical project name under the medical project entity obtained after normalization.

[0051] Based on this, in the optimization scheme, affinity mutual selection criteria can be configured separately under each project type, wherein the affinity mutual selection criteria under different project types may not be exactly the same, and different diagnostic entities may adopt different affinity mutual selection criteria under the same project type. In this way, for a single diagnostic entity, the affinity mutual selection criteria adapted to the project type to which the medical project entity belongs can be selected to perform mutual selection operations between the diagnostic entity and the medical project entity. This can ensure that paired medical project entities are selected for the diagnostic entity in a balanced manner under each project type, thereby improving the comprehensiveness and representativeness of the medical project entities selected for a single diagnostic entity.

[0052] For example, the number of visits corresponding to diagnosis entity A is 100, of which drug entity 1 appeared in 90 visits, drug entity 2 appeared in 50 visits, drug entity 3 appeared in 20 visits, and surgical operation entity 1 was performed in 15 visits. The number of visits corresponding to drug entity 1 is 150, of which diagnosis entity A appeared in 90 visits; the number of visits corresponding to drug entity 2 is 200, of which diagnosis entity A appeared in 50 visits; the number of visits corresponding to drug entity 3 is 200, of which diagnosis entity A appeared in 20 visits; the number of visits corresponding to surgical operation entity 1 is 30, of which diagnosis entity A appeared in 15 visits. Then, P(Drug 1|A) = 90 / 100, P(A|Drug 1) = 90 / 150, P(Drug 2|A) = 50 / 100, P(A|Drug 2) = 50 / 200, P(Drug 3|A) = 20 / 100, P(A|Drug 3) = 20 / 200, P(Surgical Procedure 1|A) = 15 / 100, and P(A|Surgical Procedure 1) = 15 / 30. We found that while Diagnosis Entity A is not always accompanied by Surgical Procedure Entity 1, Surgical Procedure Entity 1 is often associated with Diagnosis Entity A. Because P(A|Surgical Procedure 1) is as high as 15 / 30, Surgical Procedure Entity 1 is a relatively representative medical item entity within Diagnosis Entity A. However, its affinity is significantly lower than that of the individual drug entities. Without the introduction of item types, Surgical Procedure Entity 1 would be discarded due to its weak affinity, resulting in Diagnosis Entity A missing out on a very representative medical item entity. By introducing project classification, the surgical operation entity 1 under the surgical operation type will successfully select the diagnosis entity A, so that matching medical project entities can be selected for the diagnosis entity A in a balanced manner under each project type.

[0053] In this embodiment, various implementations may be used to determine whether the affinity of the target diagnosis entity to the target medical project entity and the affinity of the target medical project entity to the target diagnosis entity meet the affinity mutual selection criteria required under the target project type.

[0054] In an optional implementation:

[0055] According to the affinity of each diagnostic entity to the target medical project entity, m diagnostic entities with the largest affinity are selected to form a diagnostic entity set corresponding to the target medical project entity;

[0056] From the various medical project entities included in the target project type, n medical project entities with the greatest affinity to the target diagnosis entity are selected to form a medical project entity set corresponding to the target diagnosis entity under the target project type;

[0057] If the target diagnosis entity is in the diagnosis entity set and the target medical project entity is in the medical project entity set, then determine whether the affinity of the target diagnosis entity to the target medical project entity and the affinity of the target medical project entity to the target diagnosis entity meet the affinity mutual selection criteria required under the target project type.

[0058] In this optional implementation, the target diagnostic entity d i Under each project type, select the specified number of medical project entities with the largest affinity to form the target diagnosis entity d i The total set of corresponding medical project entities: The total set contains medical project entities selected under each project type, where [x il1 ,x il2 ,…,x iln ] is the target diagnostic entity d i The corresponding medical project entity set under the target project type l, X ix Then it is the target diagnosis entity d i The corresponding medical project entity collection under other project types. It can also be the target medical project entity x j Select the m diagnostic entities with the largest affinity to form the target medical project entity x j Corresponding diagnostic entity set: Thus, if the target diagnostic entity d i Appears in Target medical project entity x j Also appears in The target diagnostic entity d can be determined i and target medical project entity x j Mutual selection successful.

[0059] Of course, in this embodiment, in addition to the above-mentioned set mutual selection method, other implementation methods can also be used to determine whether the affinity of the target diagnosis entity to the target medical project entity and the affinity of the target medical project entity to the target diagnosis entity meet the affinity mutual selection criteria required under the target project type. For example, the affinity of the target diagnosis entity to the target medical project entity and the affinity of the target medical project entity to the target diagnosis entity can be summed. If the calculated sum exceeds the affinity mutual selection criteria specified under the target project type (for example, being in the top k% of the sums calculated for the target diagnosis entity under the target project type; or being greater than the sum threshold of 80 / 100 specified for the target diagnosis entity under the target project type), it can be determined whether the affinity of the target diagnosis entity to the target medical project entity and the affinity of the target medical project entity to the target diagnosis entity meet the affinity mutual selection criteria required under the target project type.

[0060] In addition, based on the introduced project types, in the normalization link mentioned above, the names of medical projects under different project types can be normalized independently, which can further improve the accuracy and rationality of the normalized output medical project entities.

[0061] Based on this, in the optimization plan, by introducing project classification, refined processing can be carried out according to project type, and each project type is calculated independently, so that matching medical project entities can be selected for diagnostic entities in a balanced manner under each project type, making the medical project entities selected for diagnostic entities more comprehensive and representative.

[0062] refer to Figure 1 and Figure 2 In step 103, a medical knowledge graph can be constructed according to the entity pairs that have been successfully selected. It should be understood that this embodiment does not limit the presentation form of the entity pairs in the medical knowledge graph. Optionally, in this embodiment, the medical project entity paired with the target diagnosis entity can be determined based on the entity pairs that have been successfully selected; based on the medical project entity paired with the target diagnosis entity, a medical knowledge graph centered on the target diagnosis entity is constructed. That is, in this embodiment, a medical knowledge graph centered on the diagnosis entity can be constructed. Of course, based on the same principle, the embodiment can also support the construction of a medical knowledge graph centered on the medical project entity, and this embodiment is not limited to this.

[0063] In addition, following the project types introduced in the optimization plan in the previous article, in this embodiment, the project type of each medical project entity can also be marked in the medical knowledge graph, which can make the medical knowledge graph clearer, more scientific, more layered, and more refined.

[0064] In this embodiment, attribute information corresponding to diagnosis entities and medical item entities can also be extracted from the medical data and annotated in the medical knowledge graph. Attribute information may include, but is not limited to, drug category, medical insurance reimbursement level, price, etc. These are merely examples, and in this embodiment, more attribute information can be annotated as needed.

[0065] In this embodiment, various diagnosis names corresponding to the diagnosis entities may also be marked in the medical knowledge graph to record various aliases of the diagnosis entities.

[0066] Figure 4 A schematic diagram of a constructed medical knowledge graph provided by an exemplary embodiment of the present application. Figure 4In this medical knowledge graph, diagnosis entities and medical project entities constitute points, and the mutual selection success relationship between them constitutes edges, thereby constructing the medical knowledge graph corresponding to the diagnosis entity; and multiple medical project entities associated with the diagnosis entity "cerebral infarction" are presented hierarchically according to the project category, and various aliases of the diagnosis entity "cerebral infarction" are recorded. It should be understood that Figure 4 The medical knowledge graph shown is only exemplary, and this embodiment is not limited thereto. Instead of presenting the project type, medical project entities under different project categories may be distinguished by color, etc.

[0067] Furthermore, in this embodiment, it is also possible to support updating of the medical knowledge graph based on newly added medical data. An exemplary update scheme may be: expanding the specified range in step 100 to cover the newly added medical data, and rebuilding the medical knowledge graph according to the aforementioned scheme process to achieve the update. Another exemplary update scheme may be: by introducing the newly added medical data, only executing the aforementioned method process for the specified diagnostic entity to update the medical project entity associated with the specified diagnostic entity in the medical knowledge graph. Among them, the specified diagnostic entity can be a common diagnostic entity. Of course, these are only exemplary. Based on the technical solution for automatically constructing the medical knowledge graph provided by this embodiment, in this embodiment, other update schemes can also be used to achieve dynamic updating of the medical knowledge graph, and this embodiment is not limited to this.

[0068] The medical knowledge graph constructed in this embodiment can be used to provide medical services in a variety of scenarios. For example, in this embodiment, a query request can be received, and the query request can carry the name of the required target diagnosis entity; based on the medical knowledge graph constructed in this embodiment, common medicines, common examinations, common nursing and other information associated with the target diagnosis entity can be queried to respond to the query request. In particular, in primary medical institutions and nursing homes, medical staff need to face general diseases, but their professional level may not be enough. The medical services provided by this embodiment based on the medical knowledge graph can provide great help to medical staff.

[0069] In summary, this embodiment uses real medical data as a basis to extract diagnosis entities, medical project entities, and the accompanying relationships between diagnosis entities and medical project entities. Based on this, the affinity of each diagnosis entity to each medical project entity and the affinity of each medical project entity to each diagnosis entity can be calculated based on the accompanying relationships. Based on the affinity, a mutual selection operation is performed between the diagnosis entity and the medical project entity to obtain mutually selected entity pairs. A medical knowledge graph is constructed based on the mutually selected entity pairs. This allows for the automated construction of a dynamic medical knowledge graph based on big data, thereby improving the efficiency of medical knowledge graph construction. Furthermore, through the mutual selection between diagnosis entities and medical project entities, more representative medical project entities can be accurately and comprehensively selected for diagnosis entities without any human intervention. The medical knowledge graph can also be dynamically updated, effectively ensuring the quality of the medical knowledge graph. Furthermore, the above-mentioned normalization scheme and the optimization scheme after introducing project types can play a significant role in the case of poor quality medical data, effectively improving the accuracy of the medical knowledge graph.

[0070] It should be noted that the execution subjects of each step of the method provided in the above embodiment can be the same device, or the method can also be executed by different devices. In addition, in some processes described in the above embodiments and the accompanying drawings, multiple operations that appear in a specific order are included, but it should be clearly understood that these operations may not be executed in the order in which they appear in this article or executed in parallel. The sequence numbers of the operations, such as 101, 102, etc., are only used to distinguish between different operations, and the sequence numbers themselves do not represent any execution order. In addition, these processes may include more or fewer operations, and these operations may be executed in sequence or in parallel.

[0071] Figure 5 This is a schematic diagram of a computing device provided by another exemplary embodiment of the present application. Figure 5 As shown, the computing device includes: a memory 50 and a processor 51.

[0072] The processor 51 is coupled to the memory 50 and is configured to execute the computer program in the memory 50 to:

[0073] Extracting diagnosis entities, medical item entities, and accompanying relationships between diagnosis entities and medical item entities from a specified range of medical data, wherein the diagnosis entities and medical item entities that appear in the same medical data have accompanying relationships;

[0074] Based on the adjoint relationship, the affinity of each diagnosis entity to each medical project entity and the affinity of each medical project entity to each diagnosis entity are calculated respectively;

[0075] Based on the affinity, a mutual selection operation is performed between the diagnosis entity and the medical project entity to obtain a mutually selected entity pair;

[0076] Construct a medical knowledge graph based on the entity pairs that are successfully selected.

[0077] In an optional embodiment, when constructing a medical knowledge graph based on mutually selected entity pairs, the processor 51 may be configured to:

[0078] Based on the mutually selected entity pairs, determine the medical project entity that is paired with the target diagnosis entity;

[0079] Based on the medical item entities paired with the target diagnosis entity, a medical knowledge graph centered on the target diagnosis entity is constructed.

[0080] In an optional embodiment, in the process of respectively calculating the affinity of each diagnosis entity to each medical project entity and the affinity of each medical project entity to each diagnosis entity based on the adjoint relationship, the processor 51 may be configured to:

[0081] Based on the accompanying relationship, the proportion of visits with the target medical project and the target diagnosis in the total number of visits corresponding to the target diagnosis is calculated as the affinity of the target medical project entity to the target diagnosis entity;

[0082] Based on the accompanying relationship, the proportion of the number of visits using the target medical item and diagnosed with the target diagnosis in the total number of visits using the target medical item is calculated as the affinity of the target diagnosis entity to the target medical item entity.

[0083] In an optional embodiment, when performing a mutual selection operation between a diagnosis entity and a medical item entity based on affinity to obtain a mutually selected entity pair, the processor 51 may be configured to:

[0084] Determine the target project type to which the target medical project entity belongs among multiple specified project types;

[0085] If the affinity of the target diagnosis entity to the target medical project entity and the affinity of the target medical project entity to the target diagnosis entity meet the affinity mutual selection criteria required under the target project type, it is determined that the target diagnosis entity and the target medical project have successfully been mutually selected.

[0086] In an optional embodiment, the processor 51 may also be configured to:

[0087] According to the affinity of each diagnosis entity to the target medical project entity, m diagnosis entities with the largest affinity are selected to form the diagnosis entity set corresponding to the target medical project entity;

[0088] From the various medical project entities included in the target project type, n medical project entities with the greatest affinity to the target diagnosis entity are selected to form a medical project entity set corresponding to the target diagnosis entity under the target project type;

[0089] If the target diagnosis entity is in the diagnosis entity set and the target medical project entity is in the medical project entity set, then determine whether the affinity of the target diagnosis entity to the target medical project entity and the affinity of the target medical project entity to the target diagnosis entity meet the affinity mutual selection criteria required under the target project type.

[0090] In an optional embodiment, the processor 51 may be configured to:

[0091] Extracting description text related to the target medical project entity from the medical data;

[0092] Input the description text into the preset classification model;

[0093] In the classification model, based on the mapping relationship between the description text and the project type, the target project type to which the target medical project entity belongs is output.

[0094] In an optional embodiment, the processor 51 may also be configured to:

[0095] Mark the project type of each medical project entity in the medical knowledge graph.

[0096] In an optional embodiment, when extracting diagnosis entities and medical item entities from a specified range of medical data, the processor 51 may be configured to:

[0097] Extract diagnosis names and medical item names from medical data;

[0098] The diagnosis names and medical item names are normalized respectively to obtain diagnosis entities and medical item entities.

[0099] In an optional embodiment, the processor 51 may be configured to:

[0100] Calculate the similarity between diagnosis names pairwise;

[0101] Clustering the diagnosis names based on similarity to obtain multiple independent diagnosis name sets;

[0102] Normalize each diagnosis name in the same diagnosis name set to a unified diagnosis entity.

[0103] In an optional embodiment, the processor 51 may be configured to:

[0104] Count the number of visits corresponding to each diagnosis name in the same diagnosis name set;

[0105] The diagnosis name with the most visits is used as the normalized diagnosis entity of the diagnosis name set.

[0106] In an optional embodiment, the processor 51 may also be configured to:

[0107] Extract attribute information corresponding to diagnosis entities and medical project entities from medical data;

[0108] Label the attribute information corresponding to the diagnosis entity and the medical project entity in the medical knowledge graph.

[0109] In an optional embodiment, the processor 51 may also be configured to:

[0110] The medical knowledge graph is updated based on the newly added medical data.

[0111] Further, if Figure 5 As shown, the computing device also includes: a communication component 52, a power supply component 53 and other components. Figure 5 Only some components are shown schematically, and it does not mean that the computing device only includes Figure 5 Components shown.

[0112] It is worth noting that the technical details in the above-mentioned embodiments of the computing device can be referred to the relevant description in the aforementioned method embodiment. In order to save space, they will not be repeated here, but this should not cause any loss of the scope of protection of this application.

[0113] Accordingly, an embodiment of the present application further provides a computer-readable storage medium storing a computer program, which, when executed, can implement the steps that can be executed by a computing device in the above method embodiment.

[0114] above Figure 5The memory in the computing platform is used to store computer programs and can be configured to store various other data to support operations on the computing platform. Examples of such data include instructions for any application or method operating on the computing platform, contact data, phone book data, messages, pictures, videos, etc. The memory can be implemented by any type of volatile or non-volatile storage device or a combination of them, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk.

[0115] above Figure 5 The communication component in is configured to facilitate wired or wireless communication between the device where the communication component is located and other devices. The device where the communication component is located can access a wireless network based on a communication standard, such as WiFi, 2G, 3G, 4G / LTE, 5G and other mobile communication networks, or a combination thereof. In an exemplary embodiment, the communication component receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component also includes a near field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology and other technologies.

[0116] above Figure 5 The power supply component in a device provides power to various components of the device in which the power supply component is located. The power supply component may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device in which the power supply component is located.

[0117] Those skilled in the art will appreciate that the embodiments of the present application can be provided as methods, systems, or computer program products. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0118] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the steps in the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0119] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0120] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0121] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0122] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0123] Computer-readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. The information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory media such as modulated data signals and carrier waves.

[0124] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0125] The foregoing is merely an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various modifications and variations. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should all be included in the protection scope of the present application.

Claims

1. A method for constructing a medical knowledge graph, comprising: Extracting diagnosis entities, medical item entities, and accompanying relationships between diagnosis entities and medical item entities from a specified range of medical data, wherein the diagnosis entities and medical item entities that appear in the same medical data have accompanying relationships; Based on the accompanying relationship, the affinity of each diagnostic entity to each medical project entity and the affinity of each medical project entity to each diagnostic entity are calculated respectively; wherein, the affinity of a diagnostic entity to a medical project entity refers to the proportion of the number of visits using the medical project entity and diagnosed as the diagnostic entity in the total number of visits using the medical project entity; the affinity of a medical project entity to a diagnostic entity refers to the proportion of the number of visits using the medical project entity and diagnosed as the diagnostic entity in the total number of visits corresponding to the diagnostic entity; Based on the affinity, a mutual selection operation is performed between the diagnosis entity and the medical project entity to obtain a mutually selected entity pair; Construct a medical knowledge graph based on the entity pairs that are successfully selected. Among them, based on the affinity, a mutual selection operation is performed between the diagnosis entity and the medical project entity to obtain an entity pair that has successfully selected each other, including: determining the target project type to which the target medical project entity belongs among multiple specified project types; if the affinity of the target diagnosis entity to the target medical project entity and the affinity of the target medical project entity to the target diagnosis entity meet the affinity mutual selection criteria required under the target project type, then it is determined that the target diagnosis entity and the target medical project entity have successfully selected each other; the project types include drugs, surgical operations, examinations, tests, consumables, treatments and nursing.

2. The method according to claim 1, wherein constructing a medical knowledge graph based on mutually selected entity pairs comprises: Based on the mutually selected entity pairs, determine the medical project entity that is paired with the target diagnosis entity; Based on the medical project entities paired with the target diagnosis entity, a medical knowledge graph centered on the target diagnosis entity is constructed.

3. The method according to claim 1, wherein the step of calculating the affinity of each diagnosis entity to each medical item entity and the affinity of each medical item entity to each diagnosis entity based on the accompanying relationship comprises: Based on the accompanying relationship, calculating the proportion of the number of visits in which the target medical project entity was used and the target diagnosis entity was diagnosed in the total number of visits corresponding to the target diagnosis entity as the affinity of the target medical project entity to the target diagnosis entity; Based on the accompanying relationship, the proportion of the number of visits using the target medical project entity and diagnosed with the target diagnosis entity in the total number of visits using the target medical project entity is calculated as the affinity of the target diagnosis entity to the target medical project entity.

4. The method according to claim 1, further comprising: According to the affinity of each diagnostic entity to the target medical project entity, m diagnostic entities with the largest affinity are selected to form a diagnostic entity set corresponding to the target medical project entity; Selecting n medical project entities with the greatest affinity to the target diagnosis entity from among the medical project entities included in the target project type to form a medical project entity set corresponding to the target diagnosis entity under the target project type; If the target diagnostic entity is within the diagnostic entity set and the target medical project entity is within the medical project entity set, determining whether the affinity of the target diagnostic entity to the target medical project entity and the affinity of the target medical project entity to the target diagnostic entity meet the affinity mutual selection criteria required under the target project type.

5. The method according to claim 1, wherein determining the target project type to which the target medical project entity belongs among a plurality of specified project types comprises: Extracting description text related to the target medical project entity from the medical treatment data; Inputting the description text into a preset classification model; In the classification model, based on the mapping relationship between the description text and the project type, the target project type to which the target medical project entity belongs is output.

6. The method according to claim 1, further comprising: The project type to which each medical project entity belongs is marked in the medical knowledge graph.

7. The method according to claim 1, wherein extracting diagnosis entities and medical item entities from the medical data within a specified range comprises: Extracting diagnosis names and medical item names from the medical treatment data; The diagnosis names and medical item names are normalized respectively to obtain diagnosis entities and medical item entities.

8. The method according to claim 7, normalizing the diagnosis name, comprising: Calculate the similarity between diagnosis names pairwise; Clustering the diagnosis names based on similarity to obtain multiple independent diagnosis name sets; Normalize each diagnosis name in the same diagnosis name set to a unified diagnosis entity.

9. The method according to claim 8, wherein normalizing each diagnosis name in the same diagnosis name set to a unified diagnosis entity comprises: Count the number of visits corresponding to each diagnosis name in the same diagnosis name set; The diagnosis name with the most visits is used as the diagnosis entity for normalized output of the diagnosis name set.

10. The method according to claim 1, further comprising: Extracting attribute information corresponding to diagnosis entities and medical project entities from the medical data; The attribute information corresponding to the diagnosis entity and the medical project entity is marked in the medical knowledge graph.

11. The method according to claim 1 , further comprising: Based on the newly added medical treatment data, the medical knowledge graph is updated.

12. A computing device comprising a memory, a processor, and a communication component; The memory is used to store one or more computer instructions; The processor is coupled to the memory and the communication component and is configured to execute the one or more computer instructions for: Extract diagnosis entities, medical item entities, and the accompanying relationship between diagnosis entities and medical item entities from the medical data of a specified range, where: There is a concomitant relationship between the diagnosis entity and the medical item entity that appear in the same medical data; Based on the accompanying relationship, the affinity of each diagnostic entity to each medical project entity and the affinity of each medical project entity to each diagnostic entity are calculated respectively; wherein, the affinity of a diagnostic entity to a medical project entity refers to the proportion of the number of visits using the medical project entity and diagnosed as the diagnostic entity in the total number of visits using the medical project entity; the affinity of a medical project entity to a diagnostic entity refers to the proportion of the number of visits using the medical project entity and diagnosed as the diagnostic entity in the total number of visits corresponding to the diagnostic entity; Based on the affinity, a mutual selection operation is performed between the diagnosis entity and the medical project entity to obtain a mutually selected entity pair; Construct a medical knowledge graph based on the entity pairs that are successfully selected. Among them, based on the affinity, a mutual selection operation is performed between the diagnosis entity and the medical project entity to obtain an entity pair that has successfully selected each other, including: determining the target project type to which the target medical project entity belongs among multiple specified project types; if the affinity of the target diagnosis entity to the target medical project entity and the affinity of the target medical project entity to the target diagnosis entity meet the affinity mutual selection criteria required under the target project type, then it is determined that the target diagnosis entity and the target medical project entity have successfully selected each other; the project types include drugs, surgical operations, examinations, tests, consumables, treatments and nursing.

13. A computer-readable storage medium storing computer instructions, which, when executed by one or more processors, causes the one or more processors to execute the method for constructing a medical knowledge graph according to any one of claims 1 to 11.

Images