KR102652935B1 - Method of providing consolidated knowledge base for supporting clinical decision and device thereof - Google Patents

Abstract

According to an embodiment of the present disclosure, a method of providing an integrated knowledge base integrating a plurality of types of knowledge to support clinical decision-making includes legacy knowledge, data-driven knowledge, and expert-driven knowledge related to clinical decision-making for a disease. Obtaining knowledge information including; generating a virtual example for the knowledge information based on the acquired knowledge information; Based on the virtual case, identifying a rule corresponding to the acquired knowledge information among rules included in an RDR-based knowledge model for supporting the clinical decision-making; evaluating the clinical decision-making recommendations contained in the identified rules, based on predetermined criteria; Based on the results of the evaluation, integrating the knowledge information into the RDR-based knowledge model; and providing the integrated knowledge base including the integrated RDR-based knowledge model.

Description

Method and device for providing an integrated knowledge base to support clinical decision making {METHOD OF PROVIDING CONSOLIDATED KNOWLEDGE BASE FOR SUPPORTING CLINICAL DECISION AND DEVICE THEREOF}

This disclosure relates to methods and devices that provide an integrated knowledge base to support clinical decision making.

Information technology and artificial intelligence (AI) have brought about developments in various fields. In particular, knowledge-based systems (KBS) based on these can effectively support complex decision-making, and the intelligence of knowledge-based systems relies on the basic knowledge model. Structured data such as EHR (electronic health records), EMR (electronic medical record), unstructured data such as clinical (treatment) records, clinical guidelines, and image data such as MRI and X-ray are basic knowledge for clinical decision-making. These are various data sources from which models can be constructed. Expert knowledge and legacy knowledge from existing systems can also be considered important data sources for constructing a knowledge-based system. These data sources can present different perspectives and provide different insights. Therefore, comprehensive knowledge modeling that integrates knowledge from various data sources is required to build a single holistic model that can more effectively support complex clinical decision-making. Meanwhile, the technology behind the present invention is described in ‘Japanese Patent Publication No. 2011-511337 (2011. 04. 07.)’.

In order to solve the above-described problems, the embodiment of the present disclosure is compatible with the RDR-based knowledge model, which is a format of an integrated knowledge model stored in an integrated knowledge base by acquiring knowledge information including legacy knowledge, data-driven knowledge, and expert-driven knowledge. A method for generating a virtual case, evaluating rules identified in an RDR-based knowledge model based on the virtual case, and providing an integrated knowledge base including an RDR-based knowledge model in which knowledge information is integrated based on the evaluation result; and The purpose is to provide electronic devices.

Embodiments of the present disclosure provide various types of knowledge information, including legacy knowledge, data-driven knowledge, and expert-driven knowledge, to an RDR-based knowledge model that follows a case-based reasoning method, through the creation of virtual cases for each knowledge information. The task is to integrate effectively.

The technical problems to be achieved by the embodiments of the present disclosure are not limited to the technical problems described above, and other technical problems can be inferred from the following embodiments.

According to one embodiment, a method of providing an integrated knowledge base that integrates multiple types of knowledge to support clinical decision-making includes legacy knowledge and data-driven knowledge related to clinical decision-making for diseases. acquiring knowledge information including -driven knowledge and expert-driven knowledge; generating a virtual case for the knowledge information based on the acquired knowledge information; Based on the virtual case, identifying a rule corresponding to the acquired knowledge information among rules included in a ripple down rules (RDR)-based knowledge model for supporting the clinical decision-making; evaluating the clinical decision-making recommendations contained in the identified rules, based on predetermined criteria; Based on the results of the evaluation, integrating the knowledge information into the RDR-based knowledge model; and providing the integrated knowledge base including the integrated RDR-based knowledge model.

According to one embodiment, the step of generating the virtual example for the knowledge information based on the acquired knowledge information includes generating a generation rule corresponding to the knowledge information - the generation rule is one related to the disease. Includes the above conditions, and each condition includes a key, an operator, and a value of the key associated with the disease -; based on the type of the operator, determining whether to change the operator within each condition; based on the type of the operator, determining whether to change the value within each condition; and generating the hypothetical example corresponding to the generation rule based on the decision whether to change the operator and the decision whether to change the value.

According to one embodiment, identifying a rule corresponding to the acquired knowledge information includes performing inference on the RDR-based knowledge model based on the hypothetical example, and The step of performing inference includes: identifying whether one or more nodes corresponding to a rule containing a condition matching the hypothetical case exist among nodes in the RDR-based knowledge model; If the one or more nodes do not exist, determining a rule of a root node in the RDR-based knowledge model as a rule corresponding to the knowledge information; And when the one or more nodes exist, it may include determining a rule of a final node selected among the one or more nodes as a rule corresponding to the knowledge information.

According to one embodiment, the method of providing the integrated knowledge base may further include generating information representing the recommendation of the clinical decision-making included in a rule corresponding to the knowledge information determined by performing the inference. You can.

According to one embodiment, the step of determining a rule corresponding to a final node selected among the one or more nodes as a rule corresponding to the knowledge information includes selecting a node that does not have a child node among the one or more nodes to the final node. It may include the step of selecting a node.

According to one embodiment, evaluating the clinical decision-making recommendation included in the identified rule may include determining whether the recommendation results in clinical decision-making for the hypothetical case based on criteria preset by an expert. A step of evaluating whether it is suitable as; and generating a result of the evaluation indicating whether the recommendation is appropriate.

According to one embodiment, based on the results of the evaluation, integrating the knowledge information into the RDR-based knowledge model includes, if the results of the evaluation indicate that the recommendation is not appropriate, the step of integrating the knowledge information into the RDR-based knowledge model. It may include performing knowledge evolution to integrate the knowledge information.

According to one embodiment, the step of performing the knowledge evolution may include converting the acquired knowledge information into a rule in the form of the RDR-based knowledge model and adding it as a sub-rule of the rule corresponding to the knowledge information. You can.

According to one embodiment, the legacy knowledge includes standardized knowledge of clinical concepts and terms used in a health management information system (HMIS), and the data-driven knowledge includes X-ray image data and magnetic resonance (MRI) Image-based knowledge based on image data including at least one of imaging (imaging) image data and computed tomography (CT) image data; Structured knowledge based on structured data including at least one of electronic medical record (EMR) data and electronic health record (EHR) data; and at least one of unstructured knowledge based on unstructured data including at least one of clinical guidelines and clinical notes, wherein the expert-led knowledge is clinical knowledge of an expert input based on a knowledge authoring tool. It may include knowledge based on data related to .

According to one embodiment, when the knowledge information is the unstructured knowledge, the step of acquiring the knowledge information includes generating the text included in the unstructured data based on BERT (bidirectional encoder representation of transformer)-based causal relationship mining technology. It may include the step of converting to a rule.

According to one embodiment, when the knowledge information is the image-based knowledge, the step of acquiring the knowledge information includes adding a final label indicating a classification result of the image generated based on processing of the image data as a new feature to the structured data. It may include an insertion step.

According to one embodiment, generating the generation rule corresponding to the knowledge information includes converting the data-driven knowledge into the generation rule based on a white box artificial intelligence (AI) algorithm; and converting the format of an iterative decision tree (IDT) of the expert-led knowledge into the generation rule.

According to one embodiment, an electronic device that provides an integrated knowledge base integrating a plurality of types of knowledge to support clinical decision-making includes: a processor; and a memory storing at least one program, wherein the processor executes the at least one program to acquire knowledge information including legacy knowledge, data-driven knowledge, and expert-driven knowledge related to clinical decision-making for a disease. , Generating a virtual case for the knowledge information based on the acquired knowledge information, and based on the virtual case, the acquired knowledge information among the rules included in the RDR-based knowledge model to support the clinical decision-making. Identify rules corresponding to, evaluate, based on predetermined criteria, the clinical decision-making recommendations included in the identified rules, and based on the results of the evaluation, convert the knowledge information into the RDR-based knowledge model. and may be configured to provide the integrated knowledge base including the integrated RDR-based knowledge model.

According to one embodiment, a non-transitory computer-readable storage medium includes a medium configured to store computer-readable instructions, wherein the computer-readable instructions, when executed by a processor, cause the processor to: Acquiring knowledge information including legacy knowledge, data-driven knowledge, and expert-driven knowledge relevant to decision making; generating a virtual example for the knowledge information based on the acquired knowledge information; Based on the virtual case, identifying a rule corresponding to the acquired knowledge information among rules included in an RDR-based knowledge model for supporting the clinical decision-making; evaluating the clinical decision-making recommendations contained in the identified rules, based on predetermined criteria; Based on the results of the evaluation, integrating the knowledge information into the RDR-based knowledge model; and providing an integrated knowledge base including the integrated RDR-based knowledge model.

Details of other embodiments are included in the detailed description and drawings.

According to the present disclosure, by effectively integrating various perspectives of various types of knowledge information, including legacy knowledge, data-driven knowledge, and expert-driven knowledge, into an RDR-based knowledge model, more accurate and reliable recommendations in complex clinical decision-making are achieved. can be provided. Additionally, the present disclosure can provide up-to-date recommendations for complex clinical decision-making through an RDR-based knowledge model that facilitates validation and maintenance of the knowledge model.

The effect of the invention is not limited to the effects mentioned above, and other effects not mentioned can be clearly understood by those skilled in the art from the claims.

Figure 1 shows a system configuration diagram for providing an integrated knowledge base according to an embodiment of the present disclosure.
Figure 2 shows a process for acquiring image-based knowledge according to an embodiment of the present disclosure.
Figure 3 shows a process for acquiring formal knowledge according to an embodiment of the present disclosure.
Figure 4 shows a process for acquiring unstructured knowledge according to an embodiment of the present disclosure.
Figure 5 shows a specific process for integrating multiple types of knowledge according to an embodiment of the present disclosure.
Figure 6 shows a process for performing knowledge evolution according to an embodiment of the present disclosure.
Figure 7 shows an example of provision of an integrated knowledge base according to an embodiment of the present disclosure.
Figure 8 shows another example of provision of an integrated knowledge base according to an embodiment of the present disclosure.
Figure 9 shows a flowchart of a method for providing an integrated knowledge base according to an embodiment of the present disclosure.
Figure 10 shows a schematic block diagram of the internal configuration of an electronic device according to an embodiment of the present disclosure.

The terms used in the embodiments are general terms that are currently widely used as much as possible while considering the functions in the present disclosure, but this may vary depending on the intention or precedent of a person working in the art, the emergence of new technology, etc. In addition, in certain cases, there are terms arbitrarily selected by the applicant, and in this case, the meaning will be described in detail in the relevant description. Therefore, the terms used in this disclosure should be defined based on the meaning of the term and the overall content of this disclosure, rather than simply the name of the term.

When it is said that a part "includes" a certain element throughout the specification, this means that, unless specifically stated to the contrary, it does not exclude other elements but may further include other elements. In addition, terms such as “..unit” and “..module” used in the specification refer to a unit that processes at least one function or operation, which may be implemented as hardware or software, or as a combination of hardware and software. there is.

The expression “at least one of a, b, and c” used throughout the specification means ‘a alone’, ‘b alone’, ‘c alone’, ‘a and b’, ‘a and c’, ‘b and c ', or 'all a, b, c'.

The “device” mentioned below may be implemented as a computer or portable terminal that can connect to a server or other terminal through a network. Here, the computer includes, for example, a laptop, desktop, laptop, etc. equipped with a web browser, and the portable terminal is, for example, a wireless communication device that guarantees portability and mobility. , all types of communication-based terminals such as IMT (International Mobile Telecommunication), CDMA (Code Division Multiple Access), W-CDMA (W-Code Division Multiple Access), and LTE (Long Term Evolution), smartphones, tablet PCs, etc. It may include a handheld-based wireless communication device.

Below, with reference to the attached drawings, embodiments of the present disclosure will be described in detail so that those skilled in the art can easily practice them. However, the present disclosure may be implemented in many different forms and is not limited to the embodiments described herein.

Hereinafter, embodiments of the present invention will be described in detail with reference to the attached drawings.

In describing the embodiments, description of technical content that is well known in the technical field to which the present invention belongs and that is not directly related to the present invention will be omitted. This is to convey the gist of the present invention more clearly without obscuring it by omitting unnecessary explanation.

For the same reason, some components are exaggerated, omitted, or schematically shown in the accompanying drawings. Additionally, the size of each component does not entirely reflect its actual size. In each drawing, identical or corresponding components are assigned the same reference numbers.

The advantages and features of the present invention and methods for achieving them will become clear by referring to the embodiments described in detail below along with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below and may be implemented in various different forms. The present embodiments are merely provided to ensure that the disclosure of the present invention is complete and to provide common knowledge in the technical field to which the present invention pertains. It is provided to fully inform those who have the scope of the invention, and the present invention is only defined by the scope of the claims. Like reference numerals refer to like elements throughout the specification.

At this time, it will be understood that each block of the processing flow diagrams and combinations of the flow diagram diagrams can be performed by computer program instructions. These computer program instructions can be mounted on a processor of a general-purpose computer, special-purpose computer, or other programmable data processing equipment, so that the instructions performed through the processor of the computer or other programmable data processing equipment are described in the flowchart block(s). It creates the means to perform functions. These computer program instructions may also be stored in computer-usable or computer-readable memory that can be directed to a computer or other programmable data processing equipment to implement a function in a particular manner, so that the computer-usable or computer-readable memory It is also possible to produce manufactured items containing instruction means to perform the functions described in the flowchart block(s). Computer program instructions can also be mounted on a computer or other programmable data processing equipment, so that a series of operational steps are performed on the computer or other programmable data processing equipment to generate a process that is executed by the computer and then processed by the computer or other programmable data processing equipment. Instructions for performing processing equipment may also provide steps for executing the functions described in the flowchart block(s).

Additionally, each block may represent a module, segment, or portion of code containing one or more executable instructions for executing specified logical function(s).

Additionally, there is no need to be construed as being limited to implementing the functions of the blocks according to the order of the blocks shown with respect to several alternative implementation examples. For example, it is possible for two blocks shown in succession to be performed substantially at the same time, or it is possible for the blocks to be performed in reverse order depending on the corresponding function.

This disclosure describes the integration of knowledge to support clinical decision making. Specifically, image data, structured data, and unstructured data for different types of knowledge acquisition can be integrated together with expert knowledge and legacy knowledge from existing systems into a single RDR-based knowledge model, which is an easily validated and evolvable knowledge model. . The increase in the amount of available medical data and advances in computing technology have enhanced the capabilities and applications of AI-based systems in all areas. The clinical decision support system (CDSS), a clinical knowledge-based system, utilizes available data and AI technology for knowledge extraction along with expert knowledge. However, since the intelligence of CDSS relies heavily on the accuracy, up-to-dateness, and reliability of basic knowledge, up-to-date and accurate knowledge can lead to more appropriate and accurate clinical decision-making.

Knowledge in CDSS can be obtained directly from experts and existing systems, or extracted from medical data using AI technologies. Since each clinical data source provides a different perspective on patients or clinical procedures in different clinical settings, knowledge obtained from a single type of data source (e.g., structured data such as EMR and HER) provides limited perspective and quality. can do. Considering the importance of decision-making in the clinical domain, different types of knowledge may be needed to obtain a holistic view of the patient. In this disclosure, a single knowledge model will be described that can integrate data-driven knowledge, legacy knowledge, and expert knowledge to provide a holistic view for clinical decision-making.

Figure 1 shows a configuration diagram of a system 100 for providing an integrated knowledge base according to an embodiment of the present disclosure.

Referring to FIG. 1, the knowledge acquisition unit 101 may acquire a plurality of types of knowledge (which may also be referred to as knowledge information in this disclosure) from various types of clinical data sources. Clinical data sources may include data about medical records or test results, specialists, and other existing systems. According to one embodiment, the plurality of types of knowledge include data-driven knowledge about medical records or test results, legacy knowledge, which is knowledge used in other existing systems, and expert knowledge, such as the experiences, findings, and practices of experts (e.g., doctors, etc.). It can include expert-led knowledge, which is clinical knowledge. According to one embodiment, data-driven knowledge includes image data 102 (e.g., X-ray image data, magnetic resonance imaging (MRI) image data, and computed tomography (CT) image data, etc.), structured data 104 ( For example, electronic medical record (EMR) data and electronic health record (EHR) data, etc.) and unstructured data 106 (for example, clinical guidelines and clinical notes, etc.). According to one embodiment, legacy knowledge 108 may be acquired based on data entered into a health management information system (HMIS). According to one embodiment, expert-led knowledge may be acquired based on expert knowledge 110 in the form of data input based on a knowledge authoring tool.

According to one embodiment, the knowledge acquisition unit 101 processes, extracts, structures, and organizes knowledge from individual data sources using existing knowledge extraction tools and techniques to acquire knowledge from a specific type of clinical data source. The action can be performed. Since these various clinical data each require different knowledge extraction methods, knowledge can be obtained from specific types of clinical data through individual data processing according to the characteristics of the clinical data. Specifically, the image-based knowledge acquisition unit 103 processes image data 102 to acquire image-based knowledge, and the structured knowledge acquisition unit 105 processes structured data 104 to acquire structured knowledge and unstructured knowledge. The knowledge acquisition unit 107 processes unstructured data 106 to acquire unstructured knowledge, the legacy knowledge control unit 109 processes legacy knowledge 108, and the expert knowledge control unit 111 acquires expert knowledge 110. It can be handled. The various types of knowledge acquired in this way can be transferred to the knowledge format conversion unit 112 and converted into the format of a production rule (PR).

According to one embodiment, the knowledge format conversion unit 112 performs a data-driven generation rule (PR) conversion and integration unit 115 or an expert-driven generation rule (PR) conversion unit 114 based on the type of input knowledge. Through this, processing can be performed to convert the relevant knowledge into the form of a production rule. For example, structured and unstructured knowledge obtained from image data 102, structured data 104, and unstructured data 106 may be referred to as data-driven knowledge, and such data-driven knowledge may include decision trees, If- It can be obtained using various white box algorithms that generate final knowledge in various formats, such as then rules, etc. Knowledge in various formats needs to be converted into a single format to make it available to various components within the system. Accordingly, the various data-driven knowledge acquired is integrated by the data-driven PR transformation and integration unit 115 and converted into a generation rule, and the resulting knowledge output from the data-driven PR transformation and integration unit 115 is a data-driven generation rule. It may be referred to as (DD-PR). In this case, the method for converting into a production rule may be determined differently depending on the type of knowledge.

Additionally, expert-led knowledge acquired from clinical domain experts can be acquired in the form of an iterative decision tree (IDT). The expert-led knowledge acquired in the form of IDT can be converted into a generation rule by the expert-led PR conversion unit 114 and stored for further processing, and the resulting knowledge output from the expert-led PR conversion unit 114 is It may be referred to as driven generation rule (ED-PR). Additionally, legacy knowledge used in existing HMIS may include data-driven knowledge acquired from patient data and expert-driven knowledge acquired from experts. In the case of legacy knowledge, the knowledge format conversion unit 112 checks whether the type of the input legacy knowledge is data-driven knowledge or expert-led knowledge, and converts it to the expert-led PR conversion unit 114 or the data-driven PR conversion and integration unit ( 115), the legacy knowledge can be converted into generation rules.

According to one embodiment, the knowledge format conversion unit 112 may perform processing 116 to check whether DD-PR and ED-PR exist in the creation rule for which conversion has been completed. For example, if both types of DD-PR and ED-PR generation rules exist, the knowledge format conversion unit 112 may transmit the generation rules to the knowledge fusion unit 117. Meanwhile, when only DD-PR or ED-PR exists, the knowledge format conversion unit 112 may transmit the creation rule to the knowledge integration unit 121.

According to one embodiment, the knowledge fusion unit 117 may perform processing to fuse the DD-PR and ED-PR received from the knowledge format conversion unit 112. Due to the importance of the clinical field, data-driven knowledge is difficult to consider as complete and accurate rules without expert verification, and in expert-driven knowledge, some knowledge and data patterns that can be detected through data-driven approaches may be overlooked. The knowledge fusion unit 117 performs two types of evaluations, upward and downward evaluations, on data-driven knowledge and expert-led knowledge through the standard insertion unit 118, the standard evaluation unit 119, and the knowledge improvement unit 120. By fusing DD-PR and ED-PR, it is possible to alleviate the limitations of individual knowledge acquisition methods. According to one embodiment, the reference insertion unit 118 includes each generation rule of DD-PR and each of ED-PR. It is possible to create and store information for defining production rules, i.e. the specifics of the evaluation criteria that a knowledge path must meet. Evaluation criteria may include various rules and regulations that each knowledge path must meet. Evaluation criteria to be applied for each knowledge path may be determined in advance by experts such as medical experts and knowledge engineers. For example, the evaluation criteria include the accuracy of the extracted paths, whether a conflict exists between the knowledge paths in DD-PR and the knowledge paths in ED-PR, the inclusion relationship between the knowledge paths in DD-PR and the knowledge paths in ED-PR, and May contain at least one piece of evidence about the path.

According to one embodiment, the standard evaluation unit 119 checks whether each knowledge path of the DD-PR satisfies the evaluation criteria created and stored by the standard insertion unit 118, thereby determining whether each knowledge path of the DD-PR A downward evaluation can be performed to determine whether or not the evaluation criteria have been passed. Specifically, if it is determined that a specific knowledge path of the DD-PR passes the evaluation criteria, the standard evaluation unit 119 merges the knowledge path of the DD-PR with the knowledge path of the corresponding ED-PR to form convergence knowledge. You can. If it is determined that the specific knowledge path of the DD-PR does not pass the evaluation criteria, the standard evaluation unit 119 may decide not to merge the specific knowledge path of the DD-PR and the corresponding knowledge path of the ED-PR. In addition, the standard evaluation unit 119 may perform upward evaluation to determine whether or not the evaluation criteria are passed for the remaining knowledge paths of ED-PR that were not merged with the knowledge path of DD-PR as a result of downward evaluation. . The knowledge path of ED-PR that has passed the evaluation criteria in upward evaluation can be merged with the knowledge path of the corresponding DD-PR to form convergence knowledge. On the other hand, the knowledge paths of DD-PR and ED-PR that failed to merge with other knowledge paths by failing to pass both downward and upward evaluations may be determined not to be used to form fused knowledge.

According to one embodiment, the knowledge improvement unit 120 may check whether validity and conflict with the existing knowledge model exists for the convergence knowledge for which downward evaluation and upward evaluation have been completed (can be referred to as knowledge consistency evaluation) has exist). Convergence knowledge determined to be valid through this knowledge consistency evaluation may be transferred to the knowledge integration unit 121 for integration with other types of knowledge.

According to one embodiment, the knowledge integration unit 121 includes legacy knowledge acquired through the legacy knowledge control unit 109 of the knowledge acquisition unit 101, an image-based knowledge acquisition unit 103, and a structured knowledge acquisition unit 105. ) and the data-driven knowledge acquired through the unstructured knowledge acquisition unit 107 and the expert-led knowledge acquired through the expert knowledge control unit 111 can be performed. The knowledge integration unit 121 can create a single knowledge model that reflects all the functions and operations of each type of knowledge model by integrating multiple types of knowledge. That is, the knowledge integration unit 121 can directly receive the creation rules of various types of knowledge or receive knowledge fused by the knowledge fusion unit 117, and integrate this knowledge into a single RDR-based knowledge model. Meanwhile, the knowledge input to the knowledge integration unit 121 has the form of a generation rule, while the integrated knowledge base 125 based on ripple down rules (RDR) uses patient cases as input (i.e., key-value pairs (key Since it follows a case-based reasoning methodology that requires a set of -value pairs, conversion from production rules to cases may be required. The virtual case generator 122 may generate virtual cases corresponding to each of these generation rules. The virtual case generator 122 may generate a virtual case for each generation rule to ensure that the corresponding knowledge is compatible with the RDR-based knowledge model in the integrated knowledge base that follows the case-based reasoning methodology. Through this, knowledge acquired from different types of clinical data sources can be easily integrated into the RDR-based knowledge model.

According to one embodiment, each generation rule may include at least one of a key associated with a specific disease, one or more conditions consisting of an operator and a value of the key, and a clinical decision result. Here, the height may represent various types of patient information required to make clinical decisions, such as gender, age, symptoms, type of test, etc. For example, in the case of diabetes, height may include gender, age, and glycated hemoglobin (HbA1c) level. Additionally, the operators "=", ">", " ", "<" or " ". Additionally, the value may represent the observed state of the corresponding key and may be categorical or numeric. For example, if the patient's gender is male and the age The example production rule "IF Gender = Male && Age > 60 && HbA1c < 6.5 THEN No Diabetes" yields the result 'No Diabetes' for the three conditions where the male is older than 60 years and the HbAlc value is less than 6.5. It may be input into the knowledge integration unit 121.

According to one embodiment, the virtual case generator 122 determines whether to change the operator of each of the conditions divided by '&&' or 'AND' to generate a virtual case corresponding to the generation rule. It can be decided based on According to one embodiment, other operators (i.e. >", " ", "<" or " The process of converting ") to the operator "=" can have a different effect on the value of the key depending on the type of operator to be converted, while keeping the condition of the rule valid. That is, the operator in the condition of the production rule is ">". , " ", "<" or " If ", a change to the operator "=" can be performed, while if the operator is "=", the operator can be left unchanged.

Additionally, when operator conversion is performed, the virtual case generator 122 may determine whether to change the key value based on the type of operator. That is, if the operator is “>” or “<”, the key value can be changed. operator is " " or " In the case of ", the value of the key can be maintained without change. Through this conversion process, the virtual case generator 122 can generate virtual cases composed of conditions each processed to have the format <key value>. .

Additionally, when the value of a key changes based on the type of operator, the size of the change may be determined based on the attribute of the value. In one embodiment, when converting the operator ">" to "=" in the condition of the generation rule, the virtual case generator 122 determines the condition if the value attribute is a real number (expressed as a float). The value can be increased by 0.1, and if the value property is an integer (integration), the value of the condition can be increased by 1. For example, the condition “Age > 60” in the example creation rule above can be converted to “Age = 61”. Similarly, when converting the operator "<" to "=", the virtual case generator 122 decreases the value of the condition by 0.1 if the value attribute is a real number (expressed in floating point), and the value attribute If this is an integer, the value of the condition can be decreased by 1. For example, in the example generation rule above, the condition “HbA1c < 6.5” can be converted to “HbA1c = 6.4”. Additionally, when converting the operator "" to "=", the virtual case generator 122 can maintain the value of the corresponding condition without changing it. Likewise, the operator " When converting " to "=", the virtual case generator 122 can maintain the value of the corresponding condition without changing it. In the above example, as a result, the condition of the creation rule is generated by the virtual case generator 122. A valid hypothetical case matching "Gender = Male, Age = 61, HbA1c = 6.4" can be generated. On the other hand, if "Age" is converted to 59, it does not match "Age >60" in the creation rule. Therefore, a virtual case containing the corresponding conversion condition may be recognized as an invalid virtual case. However, when converting the conditions of the production rule, the increased or decreased value is not limited to 0.1 or 1 and can be set in various ways. , it will be understood that more than one valid hypothetical case is possible for the production rule.

The inference engine 123 may receive a virtual case from the virtual case generator 122 and perform inference based on the received virtual case. Inference can be referred to as the process of finding an appropriate decision for a given input instance (case) within basic knowledge. According to one embodiment, the inference engine 123 may perform inference on rules included in an RDR-based knowledge model using a virtual case as input. In one embodiment, the RDR-based knowledge model may be stored in the integrated knowledge base 125 and provided for clinical decision-making through reasoning and knowledge evolution to integrate multiple types of knowledge. Since the RDR-based knowledge model stores knowledge in n-array format, the inference engine 123 performs top-to-down and left-to-right inference. The mechanism can be followed. According to one embodiment, the inference engine 123 may initiate matching with virtual cases (which may also be referred to as instance matching or instance-rule mapping) at the root node of the RDR-based knowledge model. Since the root node, also referred to as the default node, satisfies all cases, the inference engine 123 then moves to the leftmost child node of the root node and evaluates the conditions of the rule at that node. , it can be determined whether a given hypothetical case matches the rule of the corresponding node.

According to one embodiment, the match between the virtual case and the rule in the RDR-based knowledge model may include at least one of the cases where the conditions of the corresponding rule are the same as the virtual case or the case where the condition is included in the virtual case. If the virtual case and the rule do not match, the inference engine 123 moves to the sibling node located to the right of the node. If the virtual case and the rule match, the inference engine 123 moves to the child node of the node. Instance matching can be performed on the moved node. The inference engine 123 may perform instance matching until it is determined that there is no rule matching the hypothetical case or until there is no child node in the node of the finally matched rule. The inference engine 123 may identify the conclusion part of the finally matched rule as the final recommendation of the rule matching the hypothetical case and return it. This inference process may be performed for each virtual case generated by the virtual case generator 122.

The knowledge evolution engine 124 generates RDR-based knowledge based on the final recommendations of the rules identified by the inference engine 123 to keep the knowledge of the RDR-based knowledge model stored in the integrated knowledge base 125 up-to-date. You can determine whether model evolution is necessary. According to one embodiment, whether the final recommendation returned for a given hypothetical case is an appropriate clinical decision may be evaluated according to criteria preset by the expert. If the final recommendation is evaluated as an appropriate clinical decision, knowledge evolution engine 124 may decide to keep the RDR-based knowledge model in integrated knowledge base 125 current. If the final recommendation is assessed as not being an appropriate clinical decision, the knowledge evolution engine 124 determines the subrules (i.e., child nodes, not branch nodes) of the rule identified by inference that were used in the generation of the hypothetical case. A knowledge evolution process can be performed to add rules corresponding to knowledge. Additionally, the knowledge evolution engine 124 may add knowledge corresponding to the virtual case as a sub-rule of the root node. In the existing RDR-based knowledge model, newly created rules can be added as sub-rules (excluding branches) of the last rule that occurred. Meanwhile, when integrating various types of knowledge, the breadth of knowledge may be increased by connecting the maximum number of rules to the root node. The knowledge evolution engine 124 disclosed herein can increase the breadth and depth of the RDR-based knowledge model by adding new rules as rules with similar conclusions and as sub-rules of the root node. Whether or not this knowledge evolution process is performed can be performed individually for all input virtual cases.

By the process described above, all rules extracted from various types of clinical data sources can be integrated into a single RDR-based knowledge model and stored in the integrated knowledge base 125. The output unit 126 may visually display a clinical decision support system using an integrated RDR-based knowledge model and provide it to the user.

Among the various types of data described above, image data plays an important role in the clinical area in that it can provide a better understanding of the patient and support accurate diagnosis, treatment, and follow-up by visually providing the state of the living body. Advances in artificial intelligence (AI) technology, especially deep learning, have greatly improved the performance of automatic image analysis and feature extraction. Therefore, image-based knowledge can be obtained using deep learning technology to diagnose various diseases such as heart failure, which cannot be diagnosed without analyzing image data such as electrocardiogram (ECG).

Below, in FIG. 2, a process for acquiring image-based knowledge from such image data is described. The steps illustrated in FIG. 2 may be performed by the image-based knowledge acquisition unit 103.

In step S201, the image-based knowledge acquisition unit 103 may load an image for processing from a clinical image data storage. In step S202, the loaded image may be divided into a plurality of segments. Multiple segments can be processed individually. In step S203, it can be confirmed whether a segment to be processed exists, that is, whether there are remaining segments. If the segment does not exist, the process may terminate. When diagnosing a disease, a doctor may be interested only in certain parts of the image that indicate an abnormal condition. Accordingly, if a segment exists, a region of interest (ROI) may be identified in each segment in step S204. If an ROI is detected at this stage, it may be decided to perform additional processing on the corresponding segment. In step S205, deep learning-based classification may be performed on the ROI. At this stage, the status of the ROI can be confirmed and segments can be classified based on the features and characteristics of the ROI. In step S206, the classification result for each segment may be stored. At this stage, a classification label indicating the classification result may be assigned and stored for each segment. After evaluation of all segments of the image is completed, the final classification result of the entire image may be calculated in step S207. The final classification result may be generated as a label indicating a state such as normal or abnormal. The generated labels can be added as features within structured data such as EMR to ensure that they are reflected in knowledge acquisition. In other words, analysis of image data may not generate opinions in the form of rules, but it can generate labels that help generate knowledge through distinction between normal or abnormal image data. Accordingly, the image-based knowledge acquisition results can be used as a new feature of formal knowledge acquisition.

Meanwhile, most patient data, such as hospital visit history, reported symptoms, test results, performed clinical procedures, diagnostic results, and follow-up plans, can be maintained as patient EMR data in each hospital information management system (HMIS). These EMR data can contain important details that can be a valuable data source for clinical knowledge. A variety of techniques can be used to obtain clinical knowledge from such structured data. However, while black box technologies such as deep learning produce reliable results, the logic of their decisions can be difficult to discern. One of the important requirements in the clinical domain and CDSS is that the logic by which the final recommendation is derived is disclosed transparently, so white-box techniques and algorithms such as decision trees can be used to obtain formal knowledge. In particular, an algorithm that can convert formal knowledge into the form of a production rule can be used.

In Figure 3, a process for obtaining structured knowledge from such structured data is explained. The steps illustrated in FIG. 3 may be performed by the formal knowledge acquisition unit 105.

In step S301, data may be loaded in attribute-value format from structured data (eg, patient's EMR data).

In step S302, data processing to improve the quality of data may be performed. Specifically, data preprocessing based on data discretization, outlier removal, missing value imputation, and application of feature correlation can be performed.

Since the structured data may include clinical images, images may be identified within the data in step S303.

As a result of the confirmation, it can be identified whether an image exists in the data in step S304. If the data includes an image, the process proceeds to step S305 and the image-based knowledge acquisition process described in FIG. 2 may be performed.

By an image-based knowledge acquisition process, a label representing the final classification result of the image is identified and extracted, and the extracted label may be included as a new feature of the data in step S306. If the data does not include images, the structured data may also include other features that are not important for knowledge extraction, so in step S306, features that are important for knowledge acquisition may be identified within the data. For example, important features can be selected by calculating and evaluating cost and feature scores. In this case, an automatic threshold may be selected to filter out irrelevant features.

In step S307, the white box AI algorithm stored in the electronic device is called and can be applied to the characteristics identified in step S306.

In step S308, generation rules may be extracted by a white box AI algorithm and stored for use in knowledge integration.

Additionally, natural language can be one of the reliable data sources for expressing patient details as well as details about clinical procedures. As a result, a large amount of clinical data consisting of natural language may be available in an unstructured format. The most widely used textual clinical data may include clinical records, discharge records, clinical practice guidelines, etc. Additionally, there are various technologies for processing text data, such as BERT (bidirectional encoder representation of transformer) or GPT3 (generative pre-trained transformer 3), and deep learning technology that can extract patterns and knowledge from text data. According to one embodiment, to understand BERT-based causal mining technology, Hussain, Musarrat, et al. Literature such as “A practical approach towards causality mining in clinical text using active transfer learning” Journal of Biomedical Informatics (2021) may be referenced. Therefore, these technologies can be utilized to acquire unstructured knowledge. For example, after organizing the text, the unstructured knowledge acquisition unit 107 performs clinical entity identification based on clinical dictionary and semantic-based technologies such as unified medical language system (UMLS) and entity relationship extraction, and identifies the identified You can classify entities into condition and conclusion terms, identify quantitative values for conditional attributes, and finally create production rules.

Below, in Figure 4, an unstructured knowledge acquisition process for converting a clinical text document, which is unstructured knowledge, into a generation rule is explained. The steps illustrated in FIG. 4 may be performed in the unstructured knowledge acquisition unit 107.

In step S401, file loading in which text data is loaded from local data stored for knowledge extraction may be performed.

In step S402, preprocessing may be performed on the file. For example, after a text document is divided into a plurality of sentences, sentence tokenization may be performed on each sentence. Each token in a sentence can be tagged with the most appropriate part of speech (POS). Stop words are filtered out and each token can be converted to its native format by applying lemmatization techniques.

In step S403, clinical terms, i.e. clinical tokens, may be identified and extracted by evaluating each token in the sentence. Each token can be searched in the UMLS dictionary to find medical associations with the term.

In step S404, the clinical term may be converted into a candidate triple of the form <subject, verb, object>. Here, the subject or object may be a clinical term, and the verb may indicate a connection between the subject and object.

In step S405 the existence of an embedding model to be applied for the triple may be identified. If the embedding model does not exist, the process may proceed to step S408. If an embedding model exists, the candidate triple may be converted to an embedding vector based on the latest embedding model in step S406.

In step S407, the similarity (similarity) of the embedded triples can be calculated using the trained embeddings, and the triples can be classified based on this. Specifically, if the similarity of a triple exceeds a threshold, the triple is positively tagged, otherwise, it can be determined that there is no causal relationship. Positively tagged triples can be stored.

In step S408, after all triples are classified, positively tagged triples may be converted into production rules and stored.

Additionally, legacy knowledge used in existing systems can also be used as knowledge to provide an integrated knowledge base. For example, much of HMIS contains knowledge that can be called up and integrated into other systems, so it can be one of the inputs for knowledge integration. However, terminology for concepts used in HMIS may be localized and not widely understood. Therefore, mapping between concepts and terms may be required to ensure that clinical concepts can be understood globally through standardized terminology. To understand this legacy knowledge, the legacy knowledge control unit 109 can convert localized terms into standardized terms using widely known term mapping technology, machine learning and AI technology, semantic web technology, etc. Legacy knowledge acquired in this way can be easily integrated into the RDR-based knowledge model of the integrated knowledge base. In this case, the legacy knowledge will be transferred to the expert-led PR conversion unit 114 or the data-driven PR conversion and integration unit 115 as described in Figure 1 based on its type and utilized to be integrated into the RDR-based knowledge model. You can.

Additionally, the role of experts in the medical field can be particularly important. Medical experts have a wealth of knowledge based on their experience with a variety of patients. This expert knowledge can reflect real clinical scenarios and, together with other types of knowledge, can greatly improve the decision-making ability of CDSS. Expert knowledge can be easily datamatized using previously developed user-friendly knowledge authoring tools that provide easy-to-use interfaces. For example, expert knowledge may be provided in the form of flow charts and graphics, such as IDT. The expert knowledge control unit 111 can perform processing to acquire expert knowledge by interacting with such knowledge authoring tools. This expert knowledge can be obtained in the form of production rules and stored for further processing for knowledge integration.

Figure 5 shows a specific process for integrating multiple types of knowledge according to an embodiment of the present disclosure. The process illustrated in FIG. 5 may be performed by the system 100 shown in FIG. 1, and each component of these systems 100 may be implemented in the electronic device 1000 of FIG. 10.

Referring to FIG. 5, in step S501, a plurality of types of knowledge information acquired by the knowledge acquisition unit 101 are loaded into memory, and in step S502, there are remaining rules among the generation rules to perform the knowledge integration process. It can be judged whether it is done or not.

If there are no remaining rules, the integration process can be terminated.

Since the process for integration is performed for each rule, if there are remaining rules, the rules can be called one by one from the knowledge information loaded in step S503. For example, the generation rule “IF Gender = Male && Age > 60 && HbA1c < 6.5 THEN No Diabetes” can be generated from specific knowledge information about diabetes.

In step S504, the virtual case generator 122 may generate a virtual case corresponding to the creation rule. For example, by performing the transformation of the conditions "Age > 60" and "HbA1c < 6.5" in the production rule "IF Gender = Male && Age > 60 && HbA1c < 6.5 THEN No Diabetes", the hypothetical case "Gender = Male, Age = 61, HbA1c = 6.4" can be generated. The method for creating a virtual example can be performed through various embodiments described in this disclosure.

In step S505, the inference engine 123 may perform inference on the RDR-based knowledge model of the integrated knowledge base 125 based on the generated virtual example.

In step S506, the recommendations output by inference may be evaluated. That is, in step S505, a recommendation of the rule identified based on the virtual case is output, and whether the recommendation is appropriate clinical decision-making can be evaluated based on a standard predetermined by an expert.

In step S507, if the recommendation is evaluated as appropriate, it is determined that the knowledge corresponding to the hypothetical case has already been integrated into the RDR-based knowledge model, and it can be returned to step S502 to perform integration for the next rule.

If in step S507 the recommendation is evaluated to be unsuitable, a knowledge evolution step may be executed in step S508 to newly integrate the acquired knowledge into the RDR-based knowledge model. At this stage, distinguishing features between hypothetical instances of acquired knowledge and identified rules can be identified. Additionally, based on the distinguishing features, an appropriate conclusion for the hypothetical case can be provided by the expert. For example, the conclusion of a rule that corresponds to the knowledge that was used by the expert to generate the hypothetical case may be evaluated as an appropriate conclusion. Accordingly, conditions and appropriate conclusions can be converted into rules and integrated into an RDR-based knowledge model as sub-rules of rules generating recommendations evaluated as unsuitable and rules with similar conclusions. The knowledge evolution method can be performed through various embodiments included in this disclosure.

Even after processing all hypothetical instances of acquired knowledge, the system continues to operate on RDR-based Knowledge evolution of the knowledge model can be performed. Therefore, an RDR-based knowledge model can reflect all individual types of knowledge about a specific disease and generate the most appropriate recommendations for clinical decision-making. Furthermore, through continuous knowledge evolution of the RDR-based knowledge model of the integrated knowledge base, the integrated knowledge can be maintained up-to-date.

Figure 6 shows a process for performing knowledge evolution according to an embodiment of the present disclosure. The process illustrated in FIG. 6 may be performed by the system 100 shown in FIG. 1, and each component of the system 100 of FIG. 1 may be implemented by the electronic device 1000 of FIG. 10.

Referring to FIG. 6, in step S601, the system 100 may first initialize a set of recommendations and include them in a recommendation map. In step S602, a rule to perform a knowledge integration process may be called from a plurality of types of knowledge information transmitted to the knowledge integration unit 121.

At step S603, it may be checked whether the conclusion in the called rule, i.e. the recommendation, exists in the recommendation map.

If it is determined that the conclusion in the called rule does not exist in the recommendation map, the conclusion in that rule may be added to the recommendation map in step S604. If the conclusion from the called rule exists in the recommendation map, the corresponding rule may be added to the recommendation map in step S605.

If it is confirmed that the rule called in step S602 does not exist in the knowledge base, that is, the RDR-based knowledge base, then in step S606, the RDR reference rule may be called for the conclusion in the recommendation map. According to one embodiment, the RDR reference rule called is a rule that has a similar conclusion to the rule called in step S602 and added to the recommendation map or generates an inappropriate recommendation, and may be identified through inference.

At step S607, the depth of knowledge may be increased as rules for conclusions within the recommendation map are added to the RDR-based knowledge model as child rules of RDR reference rules. Additionally, in step S608, the breadth of knowledge may be increased as the corresponding rules for the conclusions in the recommendation map are added to the RDR-based knowledge model as child rules of the root node. In one embodiment, when multiple RDR reference rules are identified, steps S607 and S608 may be performed repeatedly for each RDR reference rule.

As described above, in integrating various types of knowledge, if only data-driven knowledge or expert-driven knowledge is available, the process by the knowledge fusion unit 117 is bypassed, and both the data-driven knowledge and the expert-driven knowledge are bypassed. Processing by knowledge fusion unit 717 may be activated when available.

Figure 7 is an example of provision of an integrated knowledge base according to an embodiment of the present disclosure, showing integration of knowledge when only data-driven knowledge is available. In Figure 7, an RDR-based knowledge model of an integrated knowledge base that can be provided for a clinical decision support system is explained using the example of diabetes. However, it will be understood that the present disclosure is not limited to diabetes and is applicable to any clinical diagnostic area.

Referring to FIG. 7 , an integrated knowledge base 716 storing an RDR-based knowledge model containing only basic rules (rule 0) and an input data source 701 containing data related to diabetes diagnosis may be considered. Image data (fundus photo) is processed by the image-based knowledge acquisition unit 702 and the final classification result may be generated as “abnormal.” Labels representing this final classification result may be included in the structured data. Accordingly, from the structured data processed by the structured knowledge acquisition unit 703, the rule “IF Symptoms = Yes AND Fundus Photo = Abnormal AND FPG (Fasting Plasma Glucose) > 100 THEN Predabetes" can be obtained. Meanwhile, the rule “IF FPG 126 THEN Diabetes Mellitus” can be obtained by processing text data by the unstructured knowledge acquisition unit 704. Additionally, the rule “IF HbA1c 6.5% THEN Check HbA1c Again” and the rule “IF HbA1c 6.5% AND Previous HbA1c 6.5% THEN Diabetes Mellitus” may be obtained by the legacy knowledge control unit 705. . On the other hand, it can be assumed here that expert-driven knowledge is not available. Accordingly, the acquired knowledge can be converted into a generation rule by the knowledge format conversion unit 707 and then directly transmitted to the knowledge integration unit 712 rather than the knowledge fusion unit 711. Additionally, in this case, legacy knowledge can be assumed to have been obtained from data-driven sources (e.g. image data, structured data, or unstructured data). Legacy knowledge may be transmitted to the data-driven PR conversion and integration unit 709 after its type is confirmed in the knowledge format conversion unit 707 (708). Since the acquired legacy knowledge already has the form of a creation rule, the data-driven PR transformation and integration unit 709 combines all the acquired legacy knowledge into a single rule (DD-PR) and directly delivers it to the knowledge integration unit 712. You can.

After receiving all the above-mentioned rules, the knowledge integration unit 712 may process them to integrate them into an RDR-based knowledge model. While knowledge integration is performed based on an RDR-based knowledge model that operates based on cases, since the knowledge input to the knowledge integration unit 712 has the form of a production rule, this is done by creating a virtual case for each production rule. Formal gaps can be eliminated. Referring to FIG. 7, starting from rule R ₁ of DD-PR, valid virtual cases for each generation rule can be generated by the virtual case generator 713. The virtual case creation unit 713 may first generate a virtual case for the rule “IF Symptoms = Yes AND Fundus Photo = Abnormal AND FPG > 100 THEN Predabetes” acquired by the formal knowledge acquisition unit 703.

As described in detail in FIGS. 1 and 5, the virtual case generator 713 may generate “Symptoms = Yes AND Fundus Photo = Abnormal AND FPG = 101” as a virtual case. The generated hypothetical case is passed to the inference engine 714, and since the integrated knowledge base 716 contains only the default rule (rule 0), the inference engine 714 selects “No Disease” as a recommendation. can be created.

The recommendations generated by experts can be evaluated according to preset criteria, and whether they are inappropriate recommendations can be evaluated. Based on the evaluation results of the recommendations, a knowledge evolution step may be executed by the knowledge evolution engine 715. According to the criteria preset by the expert, the appropriate recommendation for that hypothetical case may be determined to be “Predabetes”. The knowledge evolution engine 715 performs knowledge evolution on the integrated knowledge base by adding the rule “IF Symptoms = Yes AND Fundus Photo = Abnormal AND FPG > 100 THEN Predabetes” as a child rule (rule 1) of rule 0, the root node. can do. The same for the first rule “IF FPG 126 THEN Diabetes Mellitus” acquired by the unstructured knowledge acquisition unit 704 above and the first rule “IF HbA1c 6.5% THEN Check HbA1c Again” among the rules acquired by the legacy knowledge control unit 705. The process can be repeated.

Following the inference process detailed in Figures 1 and 5, “No Disease” can be generated as a recommendation for these rules as well. If the generated recommendation is evaluated as appropriate, no changes are made to the model stored in the integrated knowledge base 716. However, since the above recommendations may be evaluated as inappropriate recommendations for the hypothetical case of the two rules, the above two rules may be added by the knowledge evolution engine 715 as rules 2 and 3, which are child rules of rule 0, respectively. . That is, the integrated knowledge base 612 may include rules 0 to 3 after integrating the first rule among structured knowledge, unstructured knowledge, and legacy knowledge.

Meanwhile, among the rules obtained by the legacy knowledge control unit 705, a hypothetical case "HbA1c = 6.5% AND Previous HbA1c = 6.5%" may be generated for the second rule "IF HbA1c 6.5% AND Previous HbA1c 6.5% THEN Diabetes Mellitus". there is. The inference engine 714 may confirm that the condition of rule 3 among rules 0 to 3 stored in the integrated knowledge base 716 matches the above hypothetical case, and may generate “Check HbA1c Again” as a recommendation. This recommendation may be evaluated as an inadequate recommendation based on the criteria set by the expert, and the knowledge evolution engine 715 will replace the rule “IF HbA1c 6.5% AND Previous HbA1c 6.5% THEN Diabetes Mellitus” as a child rule of rule 3. The RDR-based knowledge model can be developed by adding rule 4 and adding rule 5, which is a child rule of rule 0. In addition to the above input data, the same process can be continued to integrate knowledge in the form of production rules obtained from various data sources into a single RDR-based knowledge model. Therefore, the final knowledge model stored in the integrated knowledge base 716 may reflect knowledge for various types of clinical decision-making.

Figure 8 is another example of providing an integrated knowledge base according to an embodiment of the present disclosure, showing integration of knowledge when both data-driven knowledge and expert-driven knowledge are available. 8 illustrates an example of diagnosis of heart failure. However, it will be understood that the present disclosure is not limited to heart failure and is applicable to any clinical diagnostic area.

Referring to FIG. 8, rule RS ₁ “IF left ventricular ejection fraction (LVEF) 40 AND electrocardiogram (ECG) = Abnormal THEN HFmrEF (heart failure with mid-range ejection fraction)” is obtained by the formal knowledge acquisition unit 802. , rule RS ₂ “IF ECG = Normal AND Symptoms = No THEN No HF” is acquired by the unstructured knowledge acquisition unit 804, and rule RS is acquired by the legacy knowledge control unit 805. ₃ “IF LVEF 40 AND Symptoms = Yes THEN HFmrEF” can be obtained. The above rules RS ₁ to RS ₃ may be transmitted to the data-driven PR conversion and integration unit 808 and converted into DD-PR. Meanwhile, the rule RS ₄ “IF Symptoms = Yes AND ECG = Abnormal AND LVEF 50 AND left atrial volume index (LAVI) > 34 THEN HFpEF (HF with preserved ejection fraction) confirmation” acquired by the expert knowledge control unit 806 is led by the expert. It can be transmitted to the PR conversion unit 810 and converted into ED-PR. The knowledge format conversion unit 807 may confirm that DD-PR and ED-PR exist (811) and transmit the DD-PR and ED-PR to the knowledge fusion unit 812. The knowledge fusion unit 812 may generate a set RS of fusion knowledge in which data-driven knowledge and expert-led knowledge are fused. The generated convergence knowledge is transmitted to the knowledge integration unit 813 and processed for each rule through the virtual case generation unit 814, the inference engine 815, and the knowledge evolution engine 816 to be integrated into the integrated knowledge base 817. You can. Therefore, the RDR-based knowledge model of the integrated knowledge base 817 in FIG. 8 may include rule 0, rules 1 to 3 and rules 5 to 6, which are child rules of rule 0, and rule 4, which is a child rule of rule 1. .

Figure 9 shows a flowchart of a method for providing an integrated knowledge base according to an embodiment of the present disclosure. 9 may be performed by the electronic device 1000 illustrated in FIG. 10.

Referring to FIG. 9 , in step S901, the electronic device 1000 may acquire knowledge information including legacy knowledge, data-driven knowledge, and expert-driven knowledge related to clinical decision-making for a disease. In one embodiment, step S901 may be performed as described with respect to the knowledge acquisition unit 101 of FIG. 1 and FIGS. 2 to 4. In one embodiment, legacy knowledge corresponds to knowledge used in existing systems and may include standardized knowledge of clinical concepts and terminology used in HMIS. In one embodiment, data-driven knowledge includes: image-based knowledge based on image data including at least one of X-ray image data, MRI image data, and CT image data; Structured knowledge based on structured data including at least one of EMR data and EHR data; and unstructured knowledge based on unstructured data including at least one of clinical guidelines and clinical notes. In one embodiment, expert-driven knowledge may include knowledge based on data associated with the expert's clinical knowledge input based on a knowledge authoring tool.

In step S902, the electronic device 1000 may generate a virtual example for knowledge information based on the acquired knowledge information. In one embodiment, step S802 may be performed as described with respect to virtual case generator 122 of FIG. 1 and FIG. 5 . Specifically, the electronic device 1000 may generate a generation rule corresponding to the acquired knowledge information. Here, the creation rule may include one or more conditions associated with the disease, and each condition may include a key, an operator, and the value of the key associated with the disease. Additionally, the electronic device 1000 may determine whether to change the operator within each condition based on the type of operator. For example, if the type of the operator is "=", it may be determined that the operator will not be changed, and if the type of the operator is not "=", it may be determined that the operator will be changed to "=". Additionally, when a change in an operator is performed, the electronic device 1000 may determine whether to change the value in each condition based on the type of the operator before the change. For example, if the operator's type is ">" or "<", the value of the key changes, and the operator's type is " " or " If ", the value of the key may be determined not to change. In addition, the electronic device 1000 creates a virtual case corresponding to the generation rule based on the decision on whether to change the operator and the decision on whether to change the value. can be created.

In step S903, the electronic device 1000 may identify a rule corresponding to the acquired knowledge information among the rules included in the RDR-based knowledge model for supporting clinical decision-making, based on the virtual case. In one embodiment, step S903 may be performed as described for inference engine 123 of FIG. 1 and FIG. 5 . Specifically, the electronic device 1000 may perform inference on an RDR-based knowledge model based on a virtual example to identify rules corresponding to the acquired knowledge information. To this end, the electronic device 1000 may identify one or more nodes corresponding to rules including conditions matching virtual cases among nodes in the RDR-based knowledge model. According to one embodiment, the root node or at least one child node of the root node in the RDR-based knowledge model may be identified as one or more nodes. In one embodiment, at least one child node of the root node may be selected from among a plurality of child nodes of the root node that do not have child nodes. Additionally, the electronic device 1000 may generate information representing clinical decision-making recommendations included in the rules of one or more nodes, which are determined by performing reasoning.

In step S904, the electronic device 1000 may evaluate the clinical decision-making recommendations included in the identified rules, based on predetermined criteria. In one embodiment, step S904 may be performed as described with respect to knowledge integration unit 121 of FIG. 1 and FIG. 5 . Specifically, the electronic device 1000 evaluates whether the recommendation is appropriate as a result of clinical decision-making for the hypothetical case, based on criteria preset by the expert, and the result of the evaluation indicates whether the recommendation is appropriate. can be created.

In step S905, the electronic device 1000 may integrate knowledge information into the RDR-based knowledge model based on the results of the evaluation. In one embodiment, step S905 may be performed as described for knowledge evolution engine 124 of Figure 1 and Figures 5 and 6. Specifically, if the results of the evaluation indicate that the recommendation is not appropriate, the electronic device 1000 may perform knowledge evolution to integrate knowledge information into an RDR-based knowledge model. In one embodiment, the electronic device 1000 may perform knowledge evolution by adding acquired knowledge information as a sub-rule of one or more nodes. For example, when only the root node is identified as one or more nodes, the electronic device 1000 may add the acquired knowledge information as a sub-rule of the root node. For example, when at least one child node of the root node is identified as one or more nodes, the electronic device 1000 may add the acquired knowledge information as a sub-rule of the root node and the at least one child node, respectively. Meanwhile, if the result of the evaluation indicates that the recommendation is appropriate, the electronic device 1000 may determine that the knowledge information has already been integrated into the RDR-based knowledge model and maintain the RDR-based knowledge model in its current state.

In step S906, the electronic device 1000 may provide an integrated knowledge base including an integrated RDR-based knowledge model. By the above-mentioned steps S901 to S905, various types of knowledge providing different perspectives on clinical judgment of the disease can be easily integrated into a single RDR-based knowledge model, and maintenance of the knowledge model is facilitated by adopting the RDR format. It could become even easier.

FIG. 10 shows a schematic block diagram of the internal configuration of an electronic device 1000 according to an embodiment of the present disclosure. The electronic device 1000 of FIG. 10 may be implemented to execute the operations of each component shown in FIG. 1 .

Referring to FIG. 10 , the electronic device 800 may include a transceiver 1010, a processor 1020, and a memory 1030. Those skilled in the art can understand that other general-purpose components may be included in addition to the components shown in FIG. 10.

The transceiver 1010 is a device for performing wired/wireless communication. Communication technologies used by the transceiver 1010 include GSM (Global System for Mobile communication), CDMA (Code Division Multi Access), LTE (Long Term Evolution), 5G, WLAN (Wireless LAN), Wi-Fi (Wireless-Fidelity), There may be Bluetooth™, RFID (Radio Frequency Identification), Infrared Data Association (IrDA), ZigBee, NFC (Near Field Communication), etc.

The processor 1020 can control the overall operation of the electronic device 1000 and process data and signals. The processor 1020 may be comprised of at least one hardware unit. Additionally, the processor 1020 may operate by one or more software modules generated by executing program codes stored in the memory 1030. The processor 1020 may execute program codes stored in the memory 1030 to control the overall operation of the electronic device 1000 and process data and signals. The processor 1020 may be configured to perform at least one method among the various embodiments described in this disclosure in conjunction with the transceiver 1010 and the memory 1030.

Memory 1030 may store information for performing at least one method described in this disclosure. Memory 1030 may be volatile memory or non-volatile memory.

The electronic device according to the above-described embodiments includes a processor, a memory for storing and executing program data, a permanent storage such as a disk drive, a communication port for communicating with an external device, a touch panel, a key, It may include user interface devices such as buttons, etc. Methods implemented as software modules or algorithms may be stored on a computer-readable recording medium as computer-readable codes or program instructions executable on the processor. Here, computer-readable recording media include magnetic storage media (e.g., ROM (read-only memory), RAM (random-access memory), floppy disk, hard disk, etc.) and optical read media (e.g., CD-ROM). ), DVD (Digital Versatile Disc), etc. The computer-readable recording medium is distributed among computer systems connected to a network, so that computer-readable code can be stored and executed in a distributed manner. The media may be readable by a computer, stored in memory, and executed by a processor.

This embodiment can be represented by functional block configurations and various processing steps. These functional blocks may be implemented in various numbers of hardware or/and software configurations that execute specific functions. For example, embodiments include integrated circuit configurations such as memory, processing, logic, look-up tables, etc. that can execute various functions under the control of one or more microprocessors or other control devices. can be hired. Similar to how the components can be implemented as software programming or software elements, the present embodiments include various algorithms implemented as combinations of data structures, processes, routines or other programming constructs, such as C, C++, Java ( It can be implemented in a programming or scripting language such as Java), assembler, etc. Functional aspects may be implemented as algorithms running on one or more processors. Additionally, this embodiment may employ conventional technologies for electronic environment settings, signal processing, and/or data processing. Terms such as “mechanism,” “element,” “means,” and “composition” can be used broadly and are not limited to mechanical and physical components. The term may include the meaning of a series of software routines in connection with a processor, etc.

The above-described embodiments are merely examples and other embodiments may be implemented within the scope of the claims described below.

Claims (14)

A method of providing an integrated knowledge base incorporating a plurality of types of knowledge carried by an electronic device to support clinical decision-making, comprising:
Acquiring knowledge information including legacy knowledge, data-driven knowledge, and expert-driven knowledge related to clinical decision-making for a disease;
generating a virtual case for the knowledge information based on the acquired knowledge information;
Based on the virtual case, identifying a rule corresponding to the acquired knowledge information among rules included in a ripple down rules (RDR)-based knowledge model for supporting the clinical decision-making;
evaluating the clinical decision-making recommendations contained in the identified rules, based on predetermined criteria;
Based on the results of the evaluation, integrating the knowledge information into the RDR-based knowledge model; and
A method of providing an integrated knowledge base, comprising providing the integrated knowledge base including the integrated RDR-based knowledge model. According to paragraph 1,
The step of generating the virtual example for the knowledge information based on the acquired knowledge information,
Generating a generation rule corresponding to the knowledge information, wherein the generation rule includes one or more conditions associated with the disease, and each condition includes a key, an operator, and a value of the key associated with the disease. ;
based on the type of the operator, determining whether to change the operator within each condition;
based on the type of the operator, determining whether to change the value within each condition; and
generating the hypothetical instance corresponding to the generation rule based on the decision whether to change the operator and the decision whether to change the value. According to paragraph 1,
Identifying a rule corresponding to the acquired knowledge information includes performing inference on the RDR-based knowledge model based on the hypothetical example,
Performing inference on the RDR-based knowledge model includes identifying one or more nodes among nodes in the RDR-based knowledge model that correspond to a rule containing a condition matching the hypothetical example,
The method for providing an integrated knowledge base, wherein the one or more nodes include a root node or at least one child node of the root node. According to paragraph 3,
A method for providing an integrated knowledge base, further comprising generating information representative of recommendations for clinical decision making included in rules of the one or more nodes determined by performing the inference. According to paragraph 3,
The method of providing an integrated knowledge base, wherein the at least one child node is identified among a plurality of child nodes of the root node that do not have child nodes. According to clause 4,
Evaluating the clinical decision-making recommendations contained in the identified rules includes:
evaluating whether the recommendation is appropriate as a result of clinical decision making for the hypothetical case, based on criteria preset by an expert; and
A method of providing an integrated knowledge base, comprising generating results of an evaluation indicating whether the recommendations are appropriate. According to clause 6,
Based on the results of the evaluation, integrating the knowledge information into the RDR-based knowledge model includes:
If the results of the evaluation indicate that the recommendation is not appropriate, performing knowledge evolution to integrate the knowledge information into the RDR-based knowledge model. In clause 7,
The steps for performing the knowledge evolution are:
When only the root node is identified as the one or more nodes, adding the acquired knowledge information as a sub-rule of the root node; and
When at least one child node of the root node is identified as the one or more nodes, adding the obtained knowledge information as a sub-rule of the root node and the at least one child node, respectively, an integrated knowledge base. How to provide . According to paragraph 1,
The legacy knowledge includes standardized knowledge of clinical concepts and terms used in HMIS (health management information system),
The data-driven knowledge is,
Image-based knowledge based on image data including at least one of X-ray image data, magnetic resonance imaging (MRI) image data, and computed tomography (CT) image data;
Structured knowledge based on structured data including at least one of electronic medical record (EMR) data and electronic health record (EHR) data; and
Unstructured knowledge based on unstructured data, including at least one of clinical guidelines and clinical notes
Contains at least one of
The expert-driven knowledge includes knowledge based on data associated with the expert's clinical knowledge input based on a knowledge authoring tool. According to clause 9,
When the knowledge information is the unstructured knowledge, the step of acquiring the knowledge information includes converting text included in the unstructured data into a generation rule based on BERT (bidirectional encoder representation of transformer)-based causal relationship mining technology. How to provide an integrated knowledge base. According to clause 9,
When the knowledge information is the image-based knowledge, the step of acquiring the knowledge information includes inserting a final label indicating a classification result of the image generated based on processing of the image data into the structured data as a new feature. , a method of providing an integrated knowledge base. According to paragraph 2,
The step of generating the generation rule corresponding to the knowledge information includes:
converting the data-driven knowledge into the generation rule based on a white box artificial intelligence (AI) algorithm; and
A method of providing an integrated knowledge base, comprising converting the format of an iterative decision tree (IDT) of the expert-driven knowledge into the generation rule. An electronic device that provides an integrated knowledge base integrating multiple types of knowledge to support clinical decision-making, comprising:
processor; and
Contains a memory in which at least one program is stored,
The processor executes the at least one program,
Acquire knowledge information, including legacy knowledge, data-driven knowledge, and expert-driven knowledge, relevant to clinical decision-making for diseases;
Generate a virtual example for the knowledge information based on the acquired knowledge information,
Based on the virtual case, identify a rule corresponding to the acquired knowledge information among the rules included in the RDR-based knowledge model for supporting the clinical decision-making,
Evaluate the clinical decision-making recommendations contained in the identified rules, based on predetermined criteria;
Based on the results of the evaluation, integrating the knowledge information into the RDR-based knowledge model,
An electronic device providing an integrated knowledge base, configured to provide the integrated knowledge base including the integrated RDR-based knowledge model. A non-transitory computer-readable storage medium, comprising:
A medium configured to store computer readable instructions,
When the computer readable instructions are executed by a processor, the processor:
Acquiring knowledge information including legacy knowledge, data-driven knowledge, and expert-driven knowledge related to clinical decision-making for a disease;
generating a virtual example for the knowledge information based on the acquired knowledge information;
Based on the virtual case, identifying a rule corresponding to the acquired knowledge information among rules included in an RDR-based knowledge model for supporting the clinical decision-making;
evaluating the clinical decision-making recommendations contained in the identified rules, based on predetermined criteria;
Based on the results of the evaluation, integrating the knowledge information into the RDR-based knowledge model; and
Providing an integrated knowledge base including the integrated RDR-based knowledge model
A non-transitory computer-readable storage medium for performing the method of providing the integrated knowledge base comprising:

Images