US20190197428A1 - Systems and methods for refactoring a knowledge model to increase domain knowledge and reconcile electronic records - Google Patents
Systems and methods for refactoring a knowledge model to increase domain knowledge and reconcile electronic records Download PDFInfo
- Publication number
- US20190197428A1 US20190197428A1 US16/233,348 US201816233348A US2019197428A1 US 20190197428 A1 US20190197428 A1 US 20190197428A1 US 201816233348 A US201816233348 A US 201816233348A US 2019197428 A1 US2019197428 A1 US 2019197428A1
- Authority
- US
- United States
- Prior art keywords
- rules
- model
- knowledge
- knowledge model
- different
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 146
- 239000002131 composite material Substances 0.000 claims abstract description 16
- 238000002649 immunization Methods 0.000 description 28
- 230000003053 immunization Effects 0.000 description 28
- 239000003814 drug Substances 0.000 description 27
- 206010020751 Hypersensitivity Diseases 0.000 description 25
- 230000007815 allergy Effects 0.000 description 25
- 229940079593 drug Drugs 0.000 description 25
- 230000004069 differentiation Effects 0.000 description 24
- 238000002483 medication Methods 0.000 description 19
- 206010040047 Sepsis Diseases 0.000 description 16
- 230000036541 health Effects 0.000 description 8
- 238000002255 vaccination Methods 0.000 description 7
- 230000008859 change Effects 0.000 description 6
- 238000004891 communication Methods 0.000 description 6
- 206010062070 Peritonitis bacterial Diseases 0.000 description 5
- 230000036760 body temperature Effects 0.000 description 5
- 238000007726 management method Methods 0.000 description 5
- 230000035488 systolic blood pressure Effects 0.000 description 5
- 230000003247 decreasing effect Effects 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 4
- 230000006872 improvement Effects 0.000 description 4
- 238000013507 mapping Methods 0.000 description 4
- 230000007246 mechanism Effects 0.000 description 4
- 238000012986 modification Methods 0.000 description 4
- 230000004048 modification Effects 0.000 description 4
- 230000006399 behavior Effects 0.000 description 3
- 230000036772 blood pressure Effects 0.000 description 3
- 238000012545 processing Methods 0.000 description 3
- 238000010572 single replacement reaction Methods 0.000 description 3
- 230000008901 benefit Effects 0.000 description 2
- 230000007423 decrease Effects 0.000 description 2
- 238000011156 evaluation Methods 0.000 description 2
- 238000012423 maintenance Methods 0.000 description 2
- 239000000463 material Substances 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 238000012384 transportation and delivery Methods 0.000 description 2
- 230000002159 abnormal effect Effects 0.000 description 1
- 230000009471 action Effects 0.000 description 1
- 230000003466 anti-cipated effect Effects 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 238000012550 audit Methods 0.000 description 1
- 238000013474 audit trail Methods 0.000 description 1
- 238000009530 blood pressure measurement Methods 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 230000001149 cognitive effect Effects 0.000 description 1
- 238000004883 computer application Methods 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 230000008878 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 230000035558 fertility Effects 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000002068 genetic effect Effects 0.000 description 1
- 230000008676 import Effects 0.000 description 1
- 230000005055 memory storage Effects 0.000 description 1
- 238000012806 monitoring device Methods 0.000 description 1
- 238000010606 normalization Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000012856 packing Methods 0.000 description 1
- 230000037361 pathway Effects 0.000 description 1
- 238000012913 prioritisation Methods 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 238000012552 review Methods 0.000 description 1
- 238000013515 script Methods 0.000 description 1
- 230000003319 supportive effect Effects 0.000 description 1
- 230000007723 transport mechanism Effects 0.000 description 1
- 238000011282 treatment Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
- G06N20/00—Machine learning
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
- G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
- G06N5/00—Computing arrangements using knowledge-based models
- G06N5/02—Knowledge representation; Symbolic representation
- G06N5/022—Knowledge engineering; Knowledge acquisition
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
- G06N5/00—Computing arrangements using knowledge-based models
- G06N5/02—Knowledge representation; Symbolic representation
- G06N5/022—Knowledge engineering; Knowledge acquisition
- G06N5/025—Extracting rules from data
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
- G06N5/00—Computing arrangements using knowledge-based models
- G06N5/04—Inference or reasoning models
- G06N5/045—Explanation of inference; Explainable artificial intelligence [XAI]; Interpretable artificial intelligence
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
- G06N5/00—Computing arrangements using knowledge-based models
- G06N5/04—Inference or reasoning models
- G06N5/046—Forward inferencing; Production systems
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
- G16H50/50—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for simulation or modelling of medical disorders
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H70/00—ICT specially adapted for the handling or processing of medical references
- G16H70/40—ICT specially adapted for the handling or processing of medical references relating to drugs, e.g. their side effects or intended usage
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H70/00—ICT specially adapted for the handling or processing of medical references
- G16H70/60—ICT specially adapted for the handling or processing of medical references relating to pathologies
Definitions
- this disclosure describes, among other things, methods, systems, and computer-readable media for improving the structure of a knowledge model and improving the knowledge of a domain ontology.
- a method determines that two or more rules in a knowledge model have different thresholds and correspond to a matching path.
- the method comprises generating a replacement rule having a composite threshold by refactoring the different thresholds of the two or more rules. Then, in some embodiments, the method modifies the knowledge model by replacing the two or more rules with the replacement rule.
- one or more computer-readable storage media are provided for storing computer instructions thereon for execution by one or more processors to perform a method.
- the method receives a knowledge model comprising a plurality of rules.
- the method determines a total number of different forms capable of being generated from the plurality of rules. For at least one form in the plurality of forms, the method determines that at least two of the plurality of rules correspond to the at least one form. The method further determines that at least two of the plurality of rules that correspond to the at least one form have different thresholds. Continuing, in an embodiment, the method determines that the at least two of the plurality of rules having different thresholds correspond to a matching path in the at least one form. In embodiments, the method generates a replacement rule having a composite threshold by refactoring the different thresholds of the at least two of the plurality of rules. The method then modifies the knowledge model by replacing the at least two of the plurality of rules with the replacement rule.
- this disclosure also describes, among other things, methods, systems, and computer-readable media for applying concept- or ontology-based models, also known as ontology-based models, to reconcile the information currently stored in one system with information imported from a plurality of diverse systems.
- a computerized method in an embodiment of the present invention.
- the computerized method obtains electronic records from a plurality of diverse systems.
- the plurality of diverse record systems having the electronic records maintain the records in different data formats.
- the method reconciles the electronic records obtained from the plurality of diverse systems with one another using an ontology-based model. Based on reconciling the electronic records, the method generates inferential knowledge.
- a system in another embodiment.
- the system comprises a processor and a memory coupled to the processor.
- the system further comprise a module stored in the memory and executed via the processor.
- the module obtains electronic records from a plurality of diverse systems, in embodiments.
- the plurality of diverse record systems stored the electronic records in different data formats, in some embodiments.
- the module reconciles the electronic records obtained from the plurality of diverse systems with one another using an ontology-based model, in accordance with the system.
- the module generates inferential knowledge based on reconciling the electronic records.
- a method in yet another embodiment, is provided.
- the method obtains electronic records from a plurality of diverse system having electronic records in different data formats, in embodiments.
- the method reconciles the electronic records obtained from the plurality of diverse systems with one another using an ontology-based model in a knowledge model.
- the method applies one or more of the medications ontology model, the allergies ontology model, the immunizations ontology model, and the problems ontology model to the electronic records, in an embodiment.
- the method recognizes discrete data items that are relevant to a meaningful use decision regarding one or more of medications, allergies, immunizations, and problems.
- the method generates inferential knowledge based on the discrete data items recognized as being relevant to a meaningful use decision regarding one or more of medications, allergies, immunizations, and problems, by applying a forecasting model to the discrete data items, the forecasting model being specific to one of medications, allergies, immunizations, or problems.
- another method is provided.
- the method obtains electronic records from a plurality of diverse systems, the plurality of diverse record systems having the electronic records in different data formats.
- the method reconciles the electronic records obtained from the plurality of diverse systems with one another using an ontology-based model.
- the method identifies, in the electronic records obtained from the plurality of diverse systems, information related to one or more of a medications ontology model, an allergies ontology model, an immunizations ontology model, and a problems ontology model.
- the method applies one or more of the medications ontology model, the allergies ontology model, the immunizations ontology model, and the problems ontology model to the electronic records obtained from the plurality of diverse systems. Then, based on the application of one or more of the medications ontology model, the allergies ontology model, the immunizations ontology model, and the problems ontology model to the electronic records, the method recognizes discrete data items that are relevant to a meaningful use decision regarding one or more of medications, allergies, immunizations, and problems. The method continues by generating inferential knowledge based on the discrete data items recognized as being relevant to a meaningful use decision regarding one or more of medications, allergies, immunizations, and problems.
- the method generates inferential knowledge by applying a forecasting model to the discrete data items, the forecasting model being specific to one of medications, allergies, immunizations, or problems. Based on applying the forecasting model to the discrete data items, the method generates a recommendation specific to one of medications, allergies, immunizations, or problems, wherein the recommendation requests a user input to confirm.
- FIG. 1 depicts a simplified representation of an exemplary domain knowledge in accordance with an embodiment of the present invention
- FIG. 2 depicts a simplified representation of exemplary rules in accordance with an embodiment of the present invention
- FIG. 3 depicts a simplified representation of exemplary ontology in accordance with an embodiment of the present invention
- FIG. 4 depicts a simplified representation of an exemplary taxonomic hierarchy an ontology in accordance with an embodiment of the present invention
- FIG. 5 depicts an exemplary system in accordance with an embodiment of the present invention
- FIG. 6 depicts an exemplary model in accordance with an embodiment of the present invention
- FIG. 7 depicts an exemplary model structure metrics report in accordance with an embodiment of the present invention.
- FIG. 8 depicts an exemplary model structure metrics report in accordance with an embodiment of the present invention.
- FIG. 9 depicts a flowchart of an exemplary method in accordance with an embodiment of the present invention.
- FIG. 10 depicts a simplified representation of exemplary rules in accordance with an embodiment of the present invention.
- FIG. 11 depicts a simplified representation of exemplary rules in accordance with an embodiment of the present invention.
- FIG. 12 depicts a flowchart of an exemplary method in accordance with an embodiment of the present invention.
- FIG. 13 depicts a flowchart of an exemplary method in accordance with an embodiment of the present invention.
- FIG. 14 depicts an exemplary graphical user interface (GUI) in accordance with an embodiment of the present invention
- FIG. 15 depicts an exemplary graphical user interface (GUI) in accordance with an embodiment of the present invention.
- FIG. 16 depicts an exemplary computing environment in accordance with an embodiment of the present invention.
- the computerized system applied rules to evaluate the selected records.
- a separate rule is used to evaluate each possible combination of variables and values for each variable that may be present in the record.
- a separate rule is drafted to address each and every distinct combination of variable(s) and/or values(s) for each variable. For example, in order to evaluate records for one condition (i.e., variable) having multiple available states (i.e., value), a rule is drafted for each distinct permutation of combinations that may be present in the record.
- the number and complexity of rules utilized escalates.
- condition A having four available states
- condition B having six available states
- condition C having three available states
- condition D having three available states
- condition E having four available states
- rules database consumes vast amounts of physical memory in order to store the supportive rules for record evaluations involving hundreds or thousands of conditions.
- processing resources are utilized to by the computerized system in order to execute the rules against records for evaluation involving hundreds or thousands of conditions.
- the computer programming code for the corresponding rules is to be modified in an effort to keep the rules database up-to-date.
- the complexity of the information stored in electronic records is growing faster than the capability available for scaling up the rules in a rules database.
- the present invention represents a paradigm shift away from rules dependency.
- the present invention provides a contextually intelligent framework that leverages a contextualization mechanism in order to reduce a computerized system's dependence on rules and a rules database.
- the present invention consumes less technological resources and more efficiently consumes technological resources (i.e., physical memory and processing power) relative to consumption in the absence of the systems, methods, and computer-readable media discussed hereinabove.
- the present invention reduces the maintenance of keeping a rules database up-to-date and increase the capabilities for scaling-up a rules database with fewer rules (i.e., rule complexity increases while a total number of rules decreases), relative to computerized systems in the absence of the systems, methods, and computer-readable media discussed herein.
- the embodiments herein also provide robust support for high level cognitive structures, maintains greater consistency and implicit relationships when modeling knowledge, and reduces the number of errors. Generally, the embodiments herein provide improved knowledge consistency and implicit relationships, relative to over other computerized systems operating in the absence of the systems, methods, and computer-readable media discussed herein.
- Embodiments of the contextually intelligent framework perform refactoring of rules within a knowledge model.
- refactoring reduces the number of rules and increases the number of concepts within a domain of an ontology, relative to other computerized systems operating in the absence of the contextualization mechanism. Accordingly, new concepts are identified and automatically used to generate new axioms based on the results of the refactoring methods discussed herein.
- the contextually intelligent framework modifies and improves the internal data structure of the knowledge model, while maintaining the desired external behavior of the knowledge model. For example, a single concept may be used to evaluate records with regard to Condition A. The one concept may, for example, replace n number of different rules that were initially drafted to evaluate Condition A in records.
- one concept might be used to replace 30 existing rules for evaluating electronic records for the clinical condition of spontaneous bacterial peritonitis and multiple available states for the clinical condition of spontaneous bacterial peritonitis. Additionally, because the enhanced knowledge model produced via the contextually intelligent framework has fewer rules after refactoring, the level of maintenance used for the enhanced knowledge model is reduced.
- refactoring rules in order to identify new concepts and axioms increases the diversity and depth of the domain knowledge of the knowledge model, and increases the “reusability” of the knowledge model across domains.
- a rule is generally drafted and inherently limited in its application to evaluate a particular concept (e.g., Condition A) and a particular domain
- concepts and axioms are generally not limited in application to a particular concept and a particular domain.
- concepts and axioms increase the reusability of the knowledge model across domains, which is an improvement over the limitations of rules alone.
- domain knowledge refers to knowledge about the environment in which a system is operating.
- Exemplary domain knowledge includes clinical domain knowledge.
- Further examples of clinical domain knowledge include sepsis domain knowledge, unique electronic numbering domain knowledge (e.g., Bates numbering), and medical terminology domain knowledge (e.g., Medcin®, Systematized Nomenclature of Medicine (SNOMED)).
- FIG. 1 illustrates a simplified representation of an exemplary clinical domain knowledge.
- Domain knowledge may be encoded (i.e., using a computer language and/or data) as one or more sets of rules, forming a knowledge model.
- a knowledge model comprises a repository that stores the sets of rules representing the domain knowledge as structured data and unstructured data.
- the rules of the knowledge model encode the domain knowledge as statements in the form of an “if-then” (antecedent-consequent) sentence that describes logical inferences obtained from the domain knowledge and the knowledge model itself.
- FIG. 2 illustrates an exemplary set of domain specific rules 200 .
- the knowledge model is capable of storing, analyzing, reasoning, and reusing knowledge, such that a knowledge model is highly specialized and distinct from a hierarchal database or a relational database, for example.
- the terms “knowledge base” and “knowledge model” are used interchangeably herein.
- the knowledge model comprises a repository of rules for the domain knowledge
- the knowledge model may also represent the domain knowledge using one or more ontologies.
- a domain ontology provides explicit, formal specifications of all of the terms within a domain knowledge and all of the relations among terms within the domain knowledge.
- FIG. 3 illustrates a simplified representation of exemplary ontology.
- a domain ontology uses classes and subclasses to explicitly describe concepts in the domain.
- a domain ontology comprises a representation, formal naming, and definition of categories, properties, and relations between concepts and data associated with the domain knowledge.
- Each object within a class and each object within a subclass may be referred to as an “instance.”
- the classes, subclasses, and instances of the domain ontology may be represented in a taxonomic hierarchy.
- FIG. 4 illustrates an exemplary taxonomic hierarchy of classes, subclasses, and/or instances of an ontology.
- the taxonomic hierarchy comprises a “tree” or a “backbone” representing the higher-level classes (i.e., corresponding to concepts in the domain knowledge) within the domain ontology, with subclasses and instances shown as nested nodes, wherein the nesting reflects the relations between classes, subclasses, and/or instances of an ontology.
- each class may have a designated “mode” that indicates a degree of certainty of the knowledge being represented.
- an ontology may be represented using axioms.
- An axiom refers to an assertion in a logical form that is distinguishable from the previously-described rules. Together, a plurality of axioms formulate an overall theory of the corresponding ontology, as the ontology describes of defines the corresponding domain. Axioms may include a theory derived from other axiomatic statements, for example, thus generating inferential knowledge within the domain knowledge. For example, the symbol “ ⁇ ” is used to state that one element is a subset of another element.
- the exemplary axiom x ⁇ y (read from left to right) is a statement that x is a subset of y.
- the exemplary axiom x ⁇ y is a statement that x is contained in y, and/or that y contains x.
- the exemplary axiom x ⁇ y is a statement that x is obtainable from y by removing zero or more elements, and/or that y is obtainable from x by adding zero or more elements.
- axioms are complex logical statements that are distinguishable from the relatively less complex “if-then” statements of the previously-described rules.
- the knowledge model discussed herein comprises a domain-ontology-based taxonomic hierarchy that represents rules, axioms, and the relations between classes, subclasses, and/or instances within the ontology.
- a computer system generally leverages such a knowledge model to solve complex problems.
- a knowledge-based computer system includes a knowledge model, a user interface, and an inference engine.
- the systems and methods described hereinafter are not limited to such computer systems, and may be operable locally or remotely, using web-based applications, the cloud, local and/or distributed networks, servers, virtual servers, and/or virtual machines, for example.
- Embodiments described herein operate to modify and improve an existing knowledge model by improving the internal structure (e.g., rules, axioms) of the knowledge model, while maintaining the external behavior of the knowledge model.
- the embodiments comprise systems, methods, and computer-readable media that refactor and restructure a knowledge model of a domain knowledge.
- the domain knowledge that is modeled by the knowledge model is a clinical domain knowledge involving one or more of problems, allergies, medicines, immunizations, conditions (e.g., sepsis, spontaneous bacterial peritonitis, or spontaneous bacterial peritonitis with sepsis).
- FIG. 5 an exemplary system 500 is shown.
- the system 500 comprises a data repository 502 that stores data.
- the data repository 502 comprises a model repository 504 that stores a plurality of knowledge models.
- Each of the knowledge models may correspond to a different domain knowledge, in one example.
- each of the knowledge models may correspond to one domain knowledge.
- the domain knowledge of the clinical condition of Sepsis may be represented by a first knowledge model for Sepsis, a second knowledge model for Sepsis, and a third knowledge for Sepsis, wherein each knowledge model is different and stored in the model repository 504 .
- the model repository 504 stores a plurality of knowledge models, wherein at least a portion of the knowledge models correspond to the same or similar domain knowledge.
- the domain knowledge of Immunizations may be represented by a first knowledge model
- the domain knowledge of Allergies may be represented by a second knowledge model
- another domain knowledge of Medicines e.g., pharmaceuticals, treatments, and clinical interventions
- each knowledge model is different and stored in the model repository 504 .
- a knowledge model comprises both explicit and implicit knowledge of the domain knowledge.
- FIG. 6 presents an exemplary portion of a model 600 that represents explicit (e.g., “WHEN”) and implicit (e.g., “INFER”) domain knowledge.
- the portion of the model 600 indicates how the model may generate implicit knowledge (e.g., inferences 602 , 604 , and 608 ) from explicit knowledge when values and conditions align.
- implicit knowledge e.g., inferences 602 , 604 , and 608
- Such models of clinical domain knowledge are stored in the model repository 504 of the data repository 502 .
- the data repository 502 further comprises a metrics repository 506 that stores a plurality of metrics reports.
- the metrics reports store information that quantify and describe the structure and complexity of the knowledge models, wherein the metrics reports are generated through one or more web-based applications, as discussed hereinafter.
- the data repository 502 , the model repository 504 , and the metrics repository 506 may be managed and evaluated using one or more web-based applications.
- the web-based applications include a control center 508 , through which a model structure differentiation tool 510 , a model output diversity tool 512 , and a model restructuring tool 514 are used to modify, and thus, improve the internal data structure (e.g., rules, axioms) of the knowledge model itself, while maintaining the external behavior of knowledge model.
- the control center 508 receives and reads one or more of the knowledge models stored in the model repository, in embodiments.
- control center 508 receives and reads a first model (e.g., sepsis 1) and a second model (e.g., sepsis 2) for handoff to the other web-based applications.
- a first model e.g., sepsis 1
- a second model e.g., sepsis 2
- each knowledge model comprises a knowledge model having rules, axioms, and one or more ontologies.
- the control center 508 provides the one or more knowledge models to the model structure differentiation tool 510 and/or the model output diversity tool 512 .
- the model structure differentiation tool 510 receives one or more knowledge models from the control center 508 .
- the model structure differentiation tool 510 identifies a structure of a first knowledge model and identifies a structure of a second knowledge model.
- structure refers to one or more of the rules, axioms, taxonomic hierarchy of an ontology, rule maps, and a master document.
- the model structure differentiation tool 510 identifies the rules, axioms, taxonomic hierarchy, a rules maps, and a master document for each model received.
- the model structure differentiation tool 510 may further determines differences between two or more of the models received.
- the model structure differentiation tool 510 may determine differences an existing model prior to refactoring and said model after refactoring, as discussed hereinafter. For example, between a first and second model, the model structure differentiation tool 510 may recognize differences in one or more of: rules of the first model relative to rules of the second model, rule thresholds of the first model relative to rule thresholds of the second model, axioms of the first model relative to axioms of the second model, taxonomic hierarchy of the first model relative to taxonomic hierarchy of the second model, classes of the first model relative to classes of the second model, subclasses of the first model relative to subclasses of the second model rules mapping of the first model relative to a rules mapping of the second model, instances of the first model relative to instances of the second model and a master document of the first model relative to a master document of the second model.
- the model structure differentiation tool 510 may recognize each individual difference between two or more models relative to one another, for example.
- the model structure differentiation tool 510 may perform the identification of model structure and the recognition of structural differences between models corresponding to the same domain knowledge, in some embodiments. In other embodiments, the model structure differentiation tool 510 may perform the identification of model structure and the recognition of structural differences between models corresponding to the different and varied domain knowledge.
- the model structure differentiation tool 510 may perform the identification of model structure and the recognition of structural differences between models corresponding to the same domain knowledge of Sepsis.
- the model structure differentiation tool 510 identify the structure of a Sepsis model structure and recognize structural differences between said model and a Spontaneous Bacterial Peritonitis model.
- the model structure differentiation tool 510 generates a model structure metrics report comprising the structural metrics of each model alone, and/or the structural metrics of the model relative to one or more other models (e.g., a refactored version of a model).
- models e.g., pre-refactoring and post-refactoring
- the recognition of overlap between models provides the system 500 with insight and knowledge of how refactoring changes a model.
- the recognition of overlap between models corresponding to different domain knowledge provides the system 500 with insight and knowledge of how refactoring changes to one model may inadvertently result in a change to another, second model. Inadvertent results may produce errors or negatively impact the performance of one or more models that are not being refactored at the time.
- the model structure metrics report is communicated to the metrics repository 506 , in some embodiments.
- FIG. 7 provides an exemplary portion 700 of a model structure metrics report.
- the exemplary portion 700 of the model structure metrics report identifies specific individual differences between a first model (e.g., sepsis 1 is a first model prior to refactoring) and a second model (e.g., sepsis1-fca is the first model as refactored), such as, for example, a total number of rules in the first model, a total number of rules in the second model, a number of rules that are present in the first model and absent from the second model, and a number of rules that are absent in the first model and present in the second model.
- a first model e.g., sepsis 1 is a first model prior to refactoring
- a second model e.g., sepsis1-fca is the first model as refactored
- the exemplary portion 700 of the model structure metrics report identifies specific individual differences between a first model (e.g., pre-refactoring sepsis1) and a second model (e.g., refactored sepsis1-fca), such as, for example, a total number of axioms in the first model, a total number of axioms in the second model, a number of axioms that are present in the first model and absent from the second model, and/or a number of axioms that are absent in the first model and present in the second model.
- a first model e.g., pre-refactoring sepsis1
- a second model e.g., refactored sepsis1-fca
- the exemplary portion 700 of the model structure metrics report identifies specific individual differences between models, such as, for example, a total number of domain concepts in the first model, a total number of domain concepts in the second model, a number of domain concepts that are present in the first model and absent from the second model, and a number of domain concepts that are absent in the first model and present in the second model.
- a model structure metrics report provides highly-granular, specific information as generated by the model structure differentiation tool 510 .
- the model structure differentiation tool 510 generates metrics regarding the rules in each model.
- the model structure metrics report may include one or more of a rule premise size, a rule consequence, a rule size, a nodes count (e.g., with regard to taxonomic hierarchy), a count of specific value premise nodes, referenced entities, and the like, as determined and recognized by model structure differentiation tool 510 .
- FIG. 8 provides an exemplary portion 800 of a model structure metrics report that provides rule size distribution(s) of a first model and a second model.
- the model structure metrics report may also be communicated with or shared with the model output diversity tool 512 and/or the model restructuring tool 514 , in some embodiments.
- the model output diversity tool 512 receives one or more models from the control center 508 , in embodiments. Additionally or alternatively, model output diversity tool 512 , receives the model structure metrics report as input from the model structure differentiation tool 510 . In embodiments, the model output diversity tool 512 determines the “fecundity” or diversity of a knowledge model. As such, the model output diversity tool 512 may determine complexity and depth of knowledge modeled by a first model (e.g., a model prior to refactoring) and a second model (e.g., said model subsequent to refactoring, or said model with anticipated changes to result when refactoring is implemented). Accordingly, the modifications and improvements to the internal structure of a knowledge model are quantifiable and visible via reports.
- a first model e.g., a model prior to refactoring
- a second model e.g., said model subsequent to refactoring, or said model with anticipated changes to result when refactoring is implemented. Accordingly, the modifications and improvements to
- the model output diversity tool 512 determines a number of distinct forms capable of being created from the rules, axioms, and concepts in the model, traces and identifies the number of distinct paths within each individual form, identifies which concepts lead to the same form(s), and/or determines a distribution of path(s) that may be generated from each individual consideration.
- path The terms “path,” “output,” and “end-state” are used interchangeably herein.
- the model output diversity tool 512 determines an overall output, output distribution, and/or output variation of a knowledge model, for example, pre-refactoring and/or post-refactoring.
- the overall output refers to a total number of distinct outputs a knowledge base is capable of generating. Accordingly, the overall outputs measures each and every distinct path that may be traced through the knowledge base, using the rules, axioms, and ontology of the knowledge base. Generally, the overall outputs does not consider overlap between paths such that two paths are determined to be distinct paths even through the two path may vary by only one different node, for example.
- the output distribution refers to the distribution of the outputs capable of being produced, relative to other outputs produced by varied possible inputs.
- the output distribution describes the distribution of outputs that may be produced by various inputs.
- the output distribution measures what variance of output may be produced by using all or many different inputs.
- the distribution of output values when charted may be clustered tightly together, or widely spread apart, for example. For example, when ten distinct inputs produce the same output, the ten distinct inputs are not widely distributed and are equivalent. In yet another example, when ten distinct inputs produce ten distinct outputs and the ten distinct outputs overlap each other at 90% in the output distribution, the ten distinct inputs may be recognized as equivalent (e.g., output-equivalent inputs).
- the model output diversity tool 512 determines that input 1 and input 2 belong to the same equivalence class, such that input 1 and input 2 are output-equivalent inputs. In contrast, when (K and input 1 ⁇ output 1 ) and (K and input 2 ⁇ output 2 ), the model output diversity tool 512 determines that input 1 and input 2 do not belong same equivalence class, such that input 1 and input 2 are not output-equivalent inputs.
- Output variation considers the degree of overlap between distinct paths (e.g., considers whether ten distinct paths only vary from one another by a single different node).
- the model output diversity tool 512 determines output variation.
- Output variation describes a measure of variance of the outputs (e.g., outputs are very different from one another, outputs are very similar to one another).
- output variation describes how distinct outputs are from one another. For example, when a distribution of all 50 outputs overlap each other at 90%, the output variation is 10% (e.g., relatively low) because the outputs are not different from one another. In contrast, for example, when 90% of the 50 distinct outputs do not overlap one another in the output distribution, the output variation diversity is relatively high.
- the output variation may be considered when determining the output distribution.
- the model output diversity tool 512 may determine that input 1 and input 2 belong to the same equivalence class, such that input 1 and input 2 are output-equivalent inputs.
- the model output diversity tool 512 may generating an output diversity report including one or more of the overall output, output distribution, and output variation.
- the output diversity report is communicated to the metrics repository 506 , in some embodiments.
- the output diversity report may also be communicated with or shared with the model structure differentiation tool 510 and/or the model restructuring tool 514 .
- the model restructuring tool 514 receives one or more models as input from the control center 508 .
- the model restructuring tool 514 received a first knowledge model to be evaluated and refactored.
- the model restructuring tool 514 refactors rules in the first knowledge model, in embodiments, in order to generate said knowledge model as restructured and improved.
- refactoring is performed in order to cure an inefficiently structured knowledge model.
- An existing knowledge model may be inefficiently structured when rules are initially created using artificial and/or arbitrary thresholds (e.g., cutoff points) and the existing knowledge model may comprise many different rules, as initially generated for each and every iteration of a concept, as previously discussed.
- the model restructuring tool 514 refactors rules and generates axioms when restructuring the knowledge model, thus improving the structure of knowledge model and increasing the complexity and depth of the domain knowledge.
- the system 500 which includes the model restructuring tool 514 , restructures the knowledge base.
- the model restructuring tool 514 also generates results and exports the results to the model repository, in embodiments.
- a refactored model is provided to the model structure differentiation tool 510 for generation of a model structure metrics report of the refactored model and/or is provided to the model output diversity tool 512 for generation of an output diversity report of the refactored model, as previously discussed.
- FIG. 9 a flow chart representing an exemplary method 900 is presented in accordance with embodiments of the present invention.
- the method 900 is performed via the system 500 .
- the method 900 is performed via the model restructuring tool 514 .
- the method 900 may be a computerized method in an embodiment.
- the method 900 may be performed by executing one or more computer-readable media having non-transitory instructions stored thereon using one or more processors.
- the method 900 comprises determining that two or more rules in a knowledge model have different thresholds and correspond to a matching path, shown at block 902 .
- an exemplary set of domain specific rules are shown that reflect clinical domain knowledge of sepsis.
- the exemplary domain specific rules include various thresholds for a patient's age.
- the exemplary domain specific rules may have been initially created using artificial and/or arbitrary thresholds (e.g., cutoff points).
- a rule has been generated for various age ranges, with rule iterations involving values for blood pressure measurements obtained by a blood pressure cuff or blood pressure invasive and body temperatures, as shown in exemplary FIG. 2 .
- the method 900 determines whether two or more domain specific rules in a knowledge model that have different thresholds also correspond to a matching path and/or the same output.
- rules 200 that reflect seven different age range thresholds and two different conditions (i.e., systolic blood pressure cuff, systolic blood pressure invasive).
- rules there are six different rules, each having different age ranges as thresholds for blood pressure (i.e., box 1002 (Age from 1 month)(Age up to 2 years), (Age from 0 day)(Age up to 1 week), (Age from 1 week)(Age up to 1 month), box 1004 (Age from 1 month)(Age up to 2 Years), (Age from 0 day)(Age up to 1 week), (Age from 1 week)(Age up to 1 month)).
- Boxes 1006 and 1008 are shown in FIG. 10 to visually group various domain specific rules in the knowledge model having different thresholds and having a matching path.
- Boxes 1010 and 1012 are shown in FIG. 10 to visually group various domain specific rules in the knowledge model having different thresholds and having a matching path.
- FIG. 10 In another example shown in FIG. 10 , eight different domain specific rules in the knowledge model, each having a different age range as a threshold of body temperature (i.e., Age from 0 day, Age up to 1 week), produce the same path, and thus, correspond to a matching path (i.e., all eight rules have an output, path, or end-state of [[is judged VALUE decreased]]).
- the various thresholds do not change the output, end-state, or path such that the eight rules are output-equivalents.
- Box 1014 is shown in FIG. 10 to visually group various domain specific rules in the knowledge model having different thresholds but that having a matching path.
- the method 900 comprises generating a replacement rule having a composite threshold by refactoring the different thresholds of the two or more rules.
- a single replacement rule is generated by refactoring several rules having varying thresholds and determined to correspond to the same path. For example, ten rules may be refactored in order to generate one single replacement rule.
- multiple replacement rules are generated by refactoring of several rules such that the number of replacement rules is fewer than the original number of rules being refactored.
- ten rules may be refactored in order to generate five replacement rules having one or more new, refactored thresholds.
- the domain specific rules 200 of FIG. 2 determined to be output equivalents may be refactored to generate one or more replacement rules with new thresholds.
- All of the various age thresholds shown in the domain specific 200 e.g., there are eight initial age ranges
- the eight different domain specific rules for evaluating body temperature that have different age ranges as thresholds and all eight producing the same path may be refactored to generate one replacement rule having a composite threshold of (Age from 0 day)(Age from 18 years).
- generating the replacement rule having the composite threshold by refactoring the different thresholds of the two or more rules comprises merging the different thresholds of the two or more rules, wherein merging the different thresholds generates a composite threshold that comprises the different thresholds.
- a least a portion of the two or more rules are merged into one composite rule.
- the method 900 further comprises modifying the knowledge model by replacing the two or more rules with the replacement rule, as presented at block 906 .
- a single replacement rule is generated from the refactoring of several rules having varying thresholds.
- the one replacement rule having composite age threshold of (Age from 0 day)(Age from 18 years) may replace all eight of the existing rules within the knowledge model.
- the eight rules indicated that the output decision of decrease in body temperature was produced i.e., a same or matching path
- one new concept may be generated and used to replace the eight rules via the method 900 .
- the new concept may be used to generate a new axiom that replaces the eight rules, in such embodiments.
- the two or more rules may be removed or deleted from the knowledge model.
- the method 900 may be performed with respect to all rules within a knowledge model such that the entire knowledge model may be evaluated and refactored.
- the number of rules in the knowledge base may be reduced, the average rule size may be reduced, the average size of an “if” premise (antecedent) in rules may be reduced, and/or the average size of a “then” statement (consequent) in rules may be reduced.
- one or more additional concepts as axioms may be generated and added to the domain ontology of the knowledge model, wherein those additional concepts (i.e., represented as one or more new axioms) may be reused in one or more other domain ontologies (e.g., reusable axioms).
- the rules refactoring and generation of new concepts is such that the method 900 changed the structure of the domain knowledge and improves the domain knowledge itself. As such, the method 900 provides an improvement to domain knowledge and knowledge model technology.
- the method 900 may further determine and recognize rule, axiom, and/or concept overlap between the knowledge model and other knowledge models in different domains, for example. As such, the method 900 has knowledge of exactly how refactoring a knowledge model may result in a change to another, second knowledge model, wherein those changes may produce errors or negatively impact the performance the second model. In some embodiment, the method 900 herein may utilize the model structure metrics report in order to provide recommendations for refactoring, prior to implementing the modifications.
- Exemplary recommendations and/or modifications to the knowledge model may include a recommendation to add a disjunctive axiom, one or more rules to remove as redundant to one another or redundant to an axiom, and/or rule refactoring and rules to merge.
- the recommendations may be provided to a user for review and approval prior to modifying the knowledge model, and/or may be exported to the model repository 504 .
- the method 900 comprises identifying a plurality of rules within the knowledge base. The method 900 may then determine a total number of different forms capable of being generated from the plurality of rules. Accordingly, the method 900 may determine a total number of different paths available within each one of the different forms. The method 900 may further comprise generating and/or receiving an output diversity report and a model structure metrics report for a knowledge model, before and/or after refactoring. As such, the method 900 may involve the model structure differentiation tool 510 and a model output diversity tool 512 , as previously described, in addition to the model restructuring tool 514 .
- the method 900 may comprise identifying, for each one of the different paths determined within each one of the different forms, at least one rule corresponding to the path.
- the method 900 identifies, for each of the different forms, two or more rules that correspond to a matching path within the form. As such, each patch with a form may be evaluated in view of one or more rules. Then, the method 900 may recognize whether two or more rules that correspond to the matching path have different thresholds, for example. The identification of rule thresholds may be performed before or after identifying one or more shared paths within a form, in various embodiments.
- a flow chart representing an exemplary method 1200 is presented in accordance with embodiments of the present invention.
- the method 1200 is performed using the previously-described system 500 .
- the method 900 is performed using the model structure differentiation tool 510 , the model output diversity tool 512 and the model restructuring tool 514 , as previously described.
- the method 1200 may be a computerized method, in one embodiment.
- the method 1200 may be performed by executing one or more computer-readable media having non-transitory instructions stored thereon using one or more processors.
- the method 1200 receives a knowledge model comprising a plurality of rules.
- the knowledge model further comprises a plurality of axioms and/or one or more ontologies.
- the knowledge model may be uploaded, for example, into one or more web-based applications that provide an interface for performing the method 1200 via one or more processors.
- the method 1200 determines a total number of different forms capable of being generated from the plurality of rules. The different forms may be identified and each available path may be traced within each form. In some embodiments, the method 1200 determines how many of the forms that are capable of being generated are also reusable for domain ontologies other that the domain ontology associated with the existing knowledge model.
- the method 1200 determines a measure or degree of diversity between each of the distinct paths capable of generation within each form, for example.
- the method 1200 may determine that two or more paths within one of the plurality of forms are input equivalent paths when the two or more path have a distribution overlap of at least 75%, 80%, or 90%.
- the method 1200 may determine that two or more paths within a form are matching paths based on a determination that the two or more paths are input equivalent paths.
- the relatively high degree of overlap between the two paths may be sufficient to determine, via one or more processors, that the two paths correspond to a matching path.
- the method 1200 determines that at least two of the plurality of rules correspond to at least one form, as shown at block 1206 .
- the method 1200 determines that at least two of the plurality of rules that correspond to at least one form have different thresholds.
- the method 1200 determines that at least two of the plurality of rules having different thresholds correspond to a matching path in the at least one form.
- rules may be determined to correspond to one path or to a matching path when the different thresholds in the rules do not effectuate a change to the path in the form, when the same value n is input to the two or more rules, for example.
- the method 1200 generates a replacement rule having a composite threshold by refactoring the different thresholds of the at least two of the plurality of rules having different thresholds and corresponding to the matching path in the at least one form. (The generation of replacement rules has been discussed in detail previously and is not reiterated here for brevity).
- the method 1200 modifies the knowledge model by replacing the at least two of the plurality of rules with the replacement rule, as previously discussed.
- the method 1200 may be repeated for each rule within the plurality of rules of the knowledge model, in embodiments. As such, the entirety of the rules in the knowledge model may be refactored with respect to forms that may be generated.
- the method 1200 may generate, via the one or more processors, at least one axiom based on refactoring the different thresholds of the at least one of the plurality of rules. In such an embodiment, the method 1200 modifies the knowledge model by adding the at least one axiom to the plurality of the axioms in the knowledge model. In another example, the method 1200 may generate, via one or more processors, at least one concept based on the refactoring. In such an example, the method 1200 modifies the knowledge model by adding the at least one concept to an ontology of the knowledge model. The addition of concepts to an ontology and axioms expressing the taxonomic hierarchy increases the complexity of the domain ontology and improves the reusability of the concepts in the knowledge model.
- the method 1200 further determines, via one or more processors, that one or more of the plurality of rules are redundant based on at least one of the plurality of axioms.
- redundancy detection an examination of the exemplary axiom A ⁇ B (A is a subset of B), the rule A, C ⁇ D (a material conditional statement that if A, C are true, then D is also true), and the rule B, C ⁇ D (a material conditional statement that if B, C are true, then D is also true) reveals that the rule A, C ⁇ D is a redundant rule because the axiom defines that A is a subset of B and thus A is encompassed by the other rule B, C ⁇ D.
- the redundant rules may be filtered out of the rule pool prior to refactoring, via the method 1200 .
- the method 1200 may modify the knowledge model by removing or deleting the one or more of the plurality of rules that are determined to be redundant from the knowledge base.
- the knowledge model having an improved internal structure may be implemented and leveraged by computer systems, as discussed hereinafter.
- embodiments of the present invention utilize concept-based models, also known as ontology-based models, as discussed above with regard to knowledge models, to reconcile information currently stored in one system with information imported from a plurality of diverse systems, in order to generate recommendations that promote continuity of care in clinical settings.
- concept-based models also known as ontology-based models, as discussed above with regard to knowledge models
- a refactored knowledge model having an improved internal structure may be implemented and leveraged by computer systems, such that ontology-based models within the refactored knowledge model are applied to evaluate and reconcile electronic information.
- a clinician needs to navigate through a sequence of several GUIs before the clinician is able to comply with meaningful use requirements.
- the clinician imports information from multiple sources in different GUIs and compares the imported information presented on one GUI to the information currently on-file for a particular patient presented on another GUI (i.e., the clinician is navigating back and forth between different GUIs).
- the clinician then makes a decision as to whether the information currently on-file for a particular patient includes the imported information. All of these steps are repeated with regard to each of four different pieces of information in order to comply with meaningful use requirements: problems, allergies, medicines, and immunizations.
- problems, allergies, medicines, and immunizations problems, allergies, medicines, and immunizations.
- the clinician has to slog through duplicate information, remember the information that they have visually seen, and then recognize when information is missing. This cumbersome compliance requirement is also repeated for every single patient encounter (e.g., a clinical visit or admission to a hospital).
- FIG. 13 present an exemplary method 1300 in accordance with embodiments of the present invention.
- the method 1300 is preformed subsequent to modifying the knowledge model by replacing the at least two of the plurality of rules with the replacement rule, as discussed above.
- the method 1300 may be a computerized method, in one embodiment.
- the method 1300 may be performed by executing one or more computer-readable media having non-transitory instructions stored thereon using one or more processors.
- electronic records are obtained from a plurality of diverse systems, as shown at block 1302 .
- the diverse systems having the records store and/or otherwise utilize the records in different data formats that may or may not be compatible with the other systems.
- the electronic records obtained include registries (e.g., an immunization registry), electronic health records, electronic medical records, payer information, pharmacy records, laboratory information, employee information (i.e., which clinicians has, is, or will interact with a patient), and/or information captured by devices (i.e., data obtained from physiological monitoring devices capturing vital signs, etc.).
- the electronic records of each system may be stored in a particular format. Examples of data formats include HL7, FHIR, and XML.
- the method 1300 reconciles the records obtained from the plurality of diverse systems with one another using an ontology-based model within the knowledge base, as illustrated at block 1304 .
- reconciling the electronic records obtained from the plurality of diverse record systems comprises identifying, in the electronic records obtained from the plurality of diverse systems, information related to one or more of a medications ontology model, an allergies ontology model, an immunizations ontology model, and a problems ontology model.
- reconciling the electronic records obtained from the plurality of diverse record systems comprises applying one or more of the medications ontology model, the allergies ontology model, the immunizations ontology model, and the problems ontology model to the electronic records obtained from the plurality of diverse systems. Based on the application of one or more of the medications ontology model, the allergies ontology model, the immunizations ontology model, and the problems ontology model to the electronic records, recognizing discrete data items that are relevant to a meaningful use decision regarding one or more of medications, allergies, immunizations, and problems.
- reconciling the electronic records obtained from the plurality of diverse record systems includes performing one or more of data cleansing, data standardization, concept or ontology normalization, records prioritization, and person matching on the electronic records.
- the method 1300 continues by generating inferential knowledge based on reconciling the record, as shown at block 1306 .
- generating inferential knowledge based on the discrete data items recognized as being relevant to a meaningful use decision regarding one or more of medications, allergies, immunizations, and problems.
- generating inferential knowledge comprises applying a forecasting model to the discrete data items, the forecasting model being specific to one of medications, allergies, immunizations, or problems. Based on applying the forecasting model to the discrete data items, a recommendation specific to one of medications, allergies, immunizations, or problems may be generated, in some embodiments.
- FIG. 14 provides an exemplary GUI 1400 .
- the GUI 1400 includes one or more recommendations 1402 and 1404 to reconcile a patient's existing vaccination record 1406 with an imported record 1408 for the patient.
- the single GUI 1400 presents the patient's existing vaccination record 1406 in one pane side-by side with the imported records 1408 for the patient in another pane such that a user viewing the GUI 1400 does not need to navigate back and forth between different GUIs, screens, tabs, or the like.
- the recommendation requests a user input to confirm or deny the recommendation.
- the GUI 1400 includes user-selectable options to Accept All recommendations 1410 , Reject All recommendations 1412 , as well as individually selectable options 1414 and 1416 to accept or reject each recommendation regarding the imported records 1408 .
- FIG. 15 provides an exemplary GUI 1500 .
- the GUI 1500 includes one or more recommendations 1502 and 1504 to reconcile a patient's existing vaccination record 1506 with imported records 1508 for the patient.
- the single GUI 1500 presents the patient's existing vaccination record 1506 side-by side with the imported records 1508 for the patient such that a user viewing the GUI 1500 does not need to navigate back and forth between different GUIs.
- the recommendation requests a user input to confirm or deny the recommendation.
- the GUI 1500 includes user-selectable options to Accept All recommendations 1510 , Reject All recommendations 1512 , as well as individually selectable options 1514 and 1516 to accept or reject each recommendation regarding the imported records 1508 .
- patient care opportunities may be identified based on the inferential knowledge, in accordance with the method 1300 . For example, having merged selected and user-confirmed records on immunizations from diverse systems, the method 1300 recognizes the patient is overdue to receive one vaccination and is approaching a deadline to receive another vaccination that is not yet overdue. The method 1300 may enable a clinical user to enter a medical order or may auto-populate a medical order for that patient to address the patient care opportunities.
- the method 1300 generates inferential knowledge including patient's immunization status, a reason for the patient to be vaccinated, and a suggested vaccination opportunity, which are all provided to a clinician user when records are merged in an electronic health record for a patient, for example.
- reconciling the electronic records obtained from the plurality of diverse systems with one another includes identifying information in the electronic records that is not present in at least one of the plurality of systems.
- the method 1300 updates the at least one of the plurality of systems to include the identified information.
- the methods discussed herein may be performed using a contextually intelligent framework.
- the contextually intelligent framework comprises a content management workspace, a content component definition model, a discern ontology, and electronic health records.
- the contextually intelligent framework integrates these components, which represent content, content definitions, and models, with one another for interoperability and for ontology-guided reconciliation of electronic records. Because these components and/or tools are integrated together to create the contextually intelligent framework, the contextually intelligent framework prevents data and information from being kept in separate silos.
- the content management workspace is a knowledge management system that supports structured clinical knowledge and terminology mapping, referencing, authoring, and license version management.
- the content component definition model is a model of reason over knowledge.
- the content component definition model provides contextualization of complex medical situations, supports clinical ontology, document models, bridge rules, analytics, and implicit relationships.
- the content component definition model further comprises multiple models of all questions and term hierarchies, for example.
- the content component definition model includes correlators, interpreters, data items, and attributes of data items, in embodiments.
- the discern ontologies provides a framework of concepts and concept templates.
- the discern ontology relies on specific pathways or “trees.”
- the content management workspace and the discern ontologies may comprise information regarding content definitions (e.g., standards, orders, diagnostics, education, and template questions). Additionally or alternatively, the content component definition model builds on the discern ontology's concepts and concept templates.
- the electronic health records are a source of current patient context, meaning that the electronic records include information as to what is known for a patient at the current point in time.
- the electronic health records are being reconciled with the information imported from a plurality of diverse systems, via the methods described herein and implemented through the contextually intelligent framework.
- a system comprises a retrieval service, the contextually intelligent framework, and electronic health records and/or clinical workflows.
- the retrieval service obtains, accesses, or otherwise retrieves a plurality of electronic records from diverse systems.
- the retrieval service may perform patient information gathering for one or more of problems, allergies, medicines, immunizations, and in some embodiments, sepsis.
- the retrieval service may analyze the configuration of each of the diverse systems and the electronic records retrieved from each of the diverse systems.
- the retrieval service may prioritize one of the diverse systems over the other systems, for example.
- the retrieval service may create an order of importance or priority for the diverse systems, in some embodiments.
- the retrieval service may further group electronic records together or apart to reflect the diverse system from which the retrieval service obtained the electronic records.
- the retrieval service may perform a de-duplication of the electronic records.
- the retrieval service may group and/or sort the electronic records, as well. For example, when grouping records, the retrieval service may group two records together such that only one of the electronic records is hidden and another record, in said group, is shown to the system.
- the contextually intelligent framework performs a de-duplication of the electronic records processed by the retrieval service.
- the contextually intelligent framework may group and/or sort the electronic records, in such an embodiment. For example, when grouping records, the contextually intelligent framework may group two records together such that only one of the electronic records is hidden and another record, in said group, is shown to the system.
- the contextually intelligent framework applies forecasting models to the electronic records, as processed by the retrieval service.
- One or more forecasting models may be applied to electronic records corresponding to the patient for which information is being reconciled.
- a model that is specific to problems, allergies, medicines, immunizations, or in some embodiments, sepsis is applied.
- the forecasting model is ontology-based, such that the information being reconciled for a particular patient is placed into the context of a problem-specific ontology, an allergies-specific ontology, a medicine-specific ontology, an immunizations-specific ontology, or a sepsis-specific ontology, for example.
- the forecasting model is used to recognize, based on the patient information mapped to a specific ontology, recommendations to place a medical order for the patient, for example, wherein the medical order promotes continuity of care for the patient.
- the forecasting model provides the patient information, as mapped to a specific ontology, for reconciliation recommendations regarding another electronic health record and/or for providing the orderable recommendations to a clinician user via a clinical workflow.
- the forecasting model provides advanced decision support regarding one or more of meaningful use reconciliation requirements, problems, allergies, medications, and immunizations.
- a reconciliation recommendation and/or an orderable recommendation may be output from the contextually intelligent framework. Reconciliation is achieved based on user input to confirm the reconciliation recommendation, at admission, discharge, and/or another time point regarding a patient encounter or clinical documentation.
- the orderable recommendations may be integrated automatically into one or more clinical workflows corresponding to the patient for which information is being reconciled.
- FIG. 16 an exemplary computing environment is depicted, in accordance with an embodiment of the present invention. It will be understood by those of ordinary skill in the art that the exemplary computing environment 1600 is just one example of a suitable computing environment and is not intended to limit the scope of use or functionality of the present invention. Similarly, the computing environment 1600 should not be interpreted as imputing any dependency and/or any requirements with regard to each component and combination(s) of components illustrated in FIG. 16 . It will be appreciated by those having ordinary skill in the art that the connections illustrated in FIG.
- FIG. 16 are also exemplary as other methods, hardware, software, and devices for establishing a communications link between the components, devices, systems, and entities, as shown in FIG. 16 , may be utilized in implementation of the present invention.
- the connections are depicted using one or more solid lines, it will be understood by those having ordinary skill in the art that the exemplary connections of FIG. 16 may be hardwired or wireless, and may use intermediary components that have been omitted or not included in FIG. 16 for simplicity's sake. As such, the absence of components from FIG. 16 should be not be interpreted as limiting the present invention to exclude additional components and combination(s) of components.
- devices and components are represented in FIG. 16 as singular devices and components, it will be appreciated that some embodiments may include a plurality of the devices and components such that FIG. 16 should not be considered as limiting the number of a device or component.
- the computing environment 1600 of FIG. 16 is illustrated as being a distributed environment where components and devices may be remote from one another and may perform separate tasks.
- the components and devices may communicate with one another and may be linked to each other using a network 1602 .
- the network 1602 may include wireless and/or physical (e.g., hardwired) connections.
- Exemplary networks include a telecommunications network of a service provider or carrier, Wide Area Network (WAN), a Local Area Network (LAN), a Wireless Local Area Network (WLAN), a cellular telecommunications network, a Wi-Fi network, a short range wireless network, a Wireless Metropolitan Area Network (WMAN), a Bluetooth® capable network, a fiber optic network, or a combination thereof.
- the network 1602 generally, provides the components and devices access to the Internet and web-based applications.
- the computing environment 1600 comprises a computing device in the form of a server 1604 . Although illustrated as one component in FIG. 16 , the present invention may utilize a plurality of local servers and/or remote servers in the computing environment 1600 .
- the server 1604 may include components such as a processing unit, internal system memory, and a suitable system bus for coupling to various components, including a database or database cluster.
- the system bus may be any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, and a local bus, using any of a variety of bus architectures.
- such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronic Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus, also known as Mezzanine bus.
- ISA Industry Standard Architecture
- MCA Micro Channel Architecture
- EISA Enhanced ISA
- VESA Video Electronic Standards Association
- PCI Peripheral Component Interconnect
- the server 1604 may include or may have access to computer-readable media.
- Computer-readable media can be any available media that may be accessed by server 1604 , and includes volatile and nonvolatile media, as well as removable and non-removable media.
- Computer-readable media may include computer storage media and communication media.
- Computer storage media may include, without limitation, volatile and nonvolatile media, as well as removable and non-removable media, implemented in any method or technology for storage of information, such as computer-readable instructions, data structures, program modules, or other data.
- computer storage media may include, but is not limited to, Random Access Memory (RAM), Read-Only Memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disks (DVDs) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage, or other magnetic storage device, or any other medium which can be used to store the desired information and which may be accessed by the server 1604 .
- Computer storage media does not comprise signals per se.
- Communication media typically embodies computer-readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and may include any information delivery media.
- modulated data signal refers to a signal that has one or more of its attributes set or changed in such a manner as to encode information in the signal.
- communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency (RF), infrared, and other wireless media. Combinations of any of the above also may be included within the scope of computer-readable media.
- the server 1604 uses logical connections to communicate with one or more remote computers 1606 within the computing environment 1600 .
- the server 1604 may employ a modem to establish communications with the Internet, the server 1604 may connect to the Internet using Wi-Fi or wireless access points, or the server may use a wireless network adapter to access the Internet.
- the server 1604 engages in two-way communication with any or all of the components and devices illustrated in FIG. 16 , using the network 1602 . Accordingly, the server 1604 may send data to and receive data from the remote computers 1606 over the network 1602 .
- the remote computers 1606 may include multiple computing devices. In an embodiment having a distributed network, the remote computers 1606 may be located at one or more different geographic locations. In an embodiment where the remote computers 1606 is a plurality of computing devices, each of the plurality of computing devices may be located across various locations such as buildings in a campus, medical and research facilities at a medical complex, offices or “branches” of a banking/credit entity, or may be mobile devices that are wearable or carried by personnel, or attached to vehicles or trackable items in a warehouse, for example.
- the remote computers 1606 is physically located in a medical setting such as, for example, a laboratory, inpatient room, an outpatient room, a hospital, a medical vehicle, a veterinary environment, an ambulatory setting, a medical billing office, a financial or administrative office, hospital administration setting, an in-home medical care environment, and/or medical professionals' offices.
- a medical professional may include physicians; medical specialists such as surgeons, radiologists, cardiologists, and oncologists; emergency medical technicians; physicians' assistants; nurse practitioners; nurses; nurses' aides; pharmacists; dieticians; microbiologists; laboratory experts; genetic counselors; researchers; veterinarians; students; and the like.
- the remote computers 1606 may be physically located in a non-medical setting, such as a packing and shipping facility or deployed within a fleet of delivery or courier vehicles.
- the computing environment 1600 includes a data store 1608 .
- the data store 1608 may be implemented using multiple data stores that are communicatively coupled to one another, independent of the geographic or physical location of a memory device.
- Exemplary data stores may store data in the form of artifacts, server lists, properties associated with servers, environments, properties associated with environments, computer instructions encoded in multiple different computer programming languages, deployment scripts, applications, properties associated with applications, release packages, version information for release packages, build levels associated with applications, identifiers for applications, identifiers for release packages, users, roles associated with users, permissions associated with roles, workflows and steps in the workflows, clients, servers associated with clients, attributes associated with properties, audit information, and/or audit trails for workflows.
- Exemplary data stores may also store data in the form of electronic records, for example, electronic medical records of patients, transaction records, billing records, task and workflow records, chronological event records, and the like.
- the data store 1608 includes physical memory that is configured to store information encoded in data.
- the data store 1608 may provide storage for computer-readable instructions, computer-executable instructions, data structures, data arrays, computer programs, applications, and other data that supports the functions and action to be undertaken using the computing environment 1600 and components shown in exemplary FIG. 16 .
- program modules may be located in local and/or remote computer storage media including, for example only, memory storage devices.
- Embodiments of the present invention may be described in the context of computer-executable instructions, such as program modules, being executed by a computing device.
- Program modules may include, but are not limited to, routines, programs, objects, components, and data structures that perform particular tasks or implement particular abstract data types.
- the server 1604 may access, retrieve, communicate, receive, and update information stored in the data store 1608 , including program modules. Accordingly, the server 1604 may execute, using a processor, computer instructions stored in the data store 1608 in order to perform embodiments described herein.
- FIG. 16 Although internal components of the devices in FIG. 16 , such as the server 1604 , are not illustrated, those of ordinary skill in the art will appreciate that internal components and their interconnection are present in the devices of FIG. 16 . Accordingly, additional details concerning the internal construction device are not further disclosed herein.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Medical Informatics (AREA)
- Health & Medical Sciences (AREA)
- Public Health (AREA)
- Primary Health Care (AREA)
- Epidemiology (AREA)
- General Health & Medical Sciences (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Data Mining & Analysis (AREA)
- Computing Systems (AREA)
- Artificial Intelligence (AREA)
- Mathematical Physics (AREA)
- Evolutionary Computation (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Computational Linguistics (AREA)
- Bioinformatics & Cheminformatics (AREA)
- Toxicology (AREA)
- Medicinal Chemistry (AREA)
- Pharmacology & Pharmacy (AREA)
- Chemical & Material Sciences (AREA)
- Biomedical Technology (AREA)
- Databases & Information Systems (AREA)
- Pathology (AREA)
- Computer Vision & Pattern Recognition (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Automation & Control Theory (AREA)
- Fuzzy Systems (AREA)
Abstract
Description
- This application entitled “Systems and Methods for Refactoring a Knowledge Model and Increasing Domain Knowledge,” is a non-provisional application that claims the benefit of provisional U.S. App. No. 62/610,714, filed on 27 Dec. 2017 and entitled “Ontology-Guided Reconciliation of Electronic Records,” the entirety of which is incorporated herein by reference.
- This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. The present invention is defined by the claims as supported by the Specification, including the Detailed Description.
- In brief and at a high level, this disclosure describes, among other things, methods, systems, and computer-readable media for improving the structure of a knowledge model and improving the knowledge of a domain ontology.
- In one embodiment, a method is provided. The method determines that two or more rules in a knowledge model have different thresholds and correspond to a matching path. In embodiments, the method comprises generating a replacement rule having a composite threshold by refactoring the different thresholds of the two or more rules. Then, in some embodiments, the method modifies the knowledge model by replacing the two or more rules with the replacement rule.
- In another embodiment, one or more computer-readable storage media are provided for storing computer instructions thereon for execution by one or more processors to perform a method. The method receives a knowledge model comprising a plurality of rules. The method, in some embodiments, determines a total number of different forms capable of being generated from the plurality of rules. For at least one form in the plurality of forms, the method determines that at least two of the plurality of rules correspond to the at least one form. The method further determines that at least two of the plurality of rules that correspond to the at least one form have different thresholds. Continuing, in an embodiment, the method determines that the at least two of the plurality of rules having different thresholds correspond to a matching path in the at least one form. In embodiments, the method generates a replacement rule having a composite threshold by refactoring the different thresholds of the at least two of the plurality of rules. The method then modifies the knowledge model by replacing the at least two of the plurality of rules with the replacement rule.
- In brief and at a high level, this disclosure also describes, among other things, methods, systems, and computer-readable media for applying concept- or ontology-based models, also known as ontology-based models, to reconcile the information currently stored in one system with information imported from a plurality of diverse systems.
- In one embodiment, a computerized method is provided in an embodiment of the present invention. The computerized method obtains electronic records from a plurality of diverse systems. In embodiments, the plurality of diverse record systems having the electronic records maintain the records in different data formats. The method reconciles the electronic records obtained from the plurality of diverse systems with one another using an ontology-based model. Based on reconciling the electronic records, the method generates inferential knowledge.
- A system is provided in another embodiment. The system comprises a processor and a memory coupled to the processor. The system further comprise a module stored in the memory and executed via the processor. The module obtains electronic records from a plurality of diverse systems, in embodiments. The plurality of diverse record systems stored the electronic records in different data formats, in some embodiments. The module reconciles the electronic records obtained from the plurality of diverse systems with one another using an ontology-based model, in accordance with the system. In embodiments, the module generates inferential knowledge based on reconciling the electronic records.
- In yet another embodiment, a method is provided. The method obtains electronic records from a plurality of diverse system having electronic records in different data formats, in embodiments. The method reconciles the electronic records obtained from the plurality of diverse systems with one another using an ontology-based model in a knowledge model. In reconciliation, the method applies one or more of the medications ontology model, the allergies ontology model, the immunizations ontology model, and the problems ontology model to the electronic records, in an embodiment. Additionally, in reconciling the a the electronic records, the method recognizes discrete data items that are relevant to a meaningful use decision regarding one or more of medications, allergies, immunizations, and problems. In embodiments, the method generates inferential knowledge based on the discrete data items recognized as being relevant to a meaningful use decision regarding one or more of medications, allergies, immunizations, and problems, by applying a forecasting model to the discrete data items, the forecasting model being specific to one of medications, allergies, immunizations, or problems.
- In an embodiment, another method is provided. In such an embodiment, the method obtains electronic records from a plurality of diverse systems, the plurality of diverse record systems having the electronic records in different data formats. The method reconciles the electronic records obtained from the plurality of diverse systems with one another using an ontology-based model. In order to reconcile the electronic records, the method identifies, in the electronic records obtained from the plurality of diverse systems, information related to one or more of a medications ontology model, an allergies ontology model, an immunizations ontology model, and a problems ontology model. Further, the method applies one or more of the medications ontology model, the allergies ontology model, the immunizations ontology model, and the problems ontology model to the electronic records obtained from the plurality of diverse systems. Then, based on the application of one or more of the medications ontology model, the allergies ontology model, the immunizations ontology model, and the problems ontology model to the electronic records, the method recognizes discrete data items that are relevant to a meaningful use decision regarding one or more of medications, allergies, immunizations, and problems. The method continues by generating inferential knowledge based on the discrete data items recognized as being relevant to a meaningful use decision regarding one or more of medications, allergies, immunizations, and problems. In embodiment, the method generates inferential knowledge by applying a forecasting model to the discrete data items, the forecasting model being specific to one of medications, allergies, immunizations, or problems. Based on applying the forecasting model to the discrete data items, the method generates a recommendation specific to one of medications, allergies, immunizations, or problems, wherein the recommendation requests a user input to confirm.
- Illustrative embodiments of the present invention are described in detail below with reference to the attached drawing figures, and wherein:
-
FIG. 1 depicts a simplified representation of an exemplary domain knowledge in accordance with an embodiment of the present invention; -
FIG. 2 depicts a simplified representation of exemplary rules in accordance with an embodiment of the present invention; -
FIG. 3 depicts a simplified representation of exemplary ontology in accordance with an embodiment of the present invention; -
FIG. 4 depicts a simplified representation of an exemplary taxonomic hierarchy an ontology in accordance with an embodiment of the present invention; -
FIG. 5 depicts an exemplary system in accordance with an embodiment of the present invention; -
FIG. 6 depicts an exemplary model in accordance with an embodiment of the present invention; -
FIG. 7 depicts an exemplary model structure metrics report in accordance with an embodiment of the present invention; -
FIG. 8 depicts an exemplary model structure metrics report in accordance with an embodiment of the present invention; -
FIG. 9 depicts a flowchart of an exemplary method in accordance with an embodiment of the present invention; -
FIG. 10 depicts a simplified representation of exemplary rules in accordance with an embodiment of the present invention; -
FIG. 11 depicts a simplified representation of exemplary rules in accordance with an embodiment of the present invention; -
FIG. 12 depicts a flowchart of an exemplary method in accordance with an embodiment of the present invention; -
FIG. 13 depicts a flowchart of an exemplary method in accordance with an embodiment of the present invention; -
FIG. 14 depicts an exemplary graphical user interface (GUI) in accordance with an embodiment of the present invention; -
FIG. 15 depicts an exemplary graphical user interface (GUI) in accordance with an embodiment of the present invention; and -
FIG. 16 depicts an exemplary computing environment in accordance with an embodiment of the present invention. - The subject matter of the present invention is described with specificity herein to meet statutory requirements. However, the description itself is not intended to limit the scope of this patent. Rather, the inventors have contemplated that the claimed subject matter might also be embodied in other ways, to include different steps or combinations of steps similar to the ones described in this document, in conjunction with other present or future technologies. Moreover, although the terms “step” and/or “block” may be used herein to connote different elements of methods employed, the terms should not be interpreted as implying any particular order among or between various steps herein disclosed unless and except when the order of individual steps is explicitly described. Further, it will be apparent from this Detailed Description that the technological solutions disclosed herein are only a portion of those provided by the present invention. As such, the technological problems, solutions, advances, and improvements expressly referenced and explained should not be construed in a way that would limit the benefits and application of embodiments of the present invention.
- In order for a computerized system to aggregate selected records and understand the information stored in electronic records, the computerized system applied rules to evaluate the selected records. A separate rule is used to evaluate each possible combination of variables and values for each variable that may be present in the record. Thus, a separate rule is drafted to address each and every distinct combination of variable(s) and/or values(s) for each variable. For example, in order to evaluate records for one condition (i.e., variable) having multiple available states (i.e., value), a rule is drafted for each distinct permutation of combinations that may be present in the record. As the amount of information stored in electronic records increases, the number and complexity of rules utilized escalates.
- To illustrate, in order to for a computerized system to evaluate records involving five conditions, condition A having four available states, condition B having six available states, condition C having three available states, condition D having three available states, and condition E having four available states, the computerized system leverages a rule database storing a separate rule to evaluate each one of the 864 available permutations of the five conditions and available states. As such, rules database consumes vast amounts of physical memory in order to store the supportive rules for record evaluations involving hundreds or thousands of conditions. Additionally, a significant amount of processing resources are utilized to by the computerized system in order to execute the rules against records for evaluation involving hundreds or thousands of conditions. Further, each time that a change is made to one of the conditions and/or the available states for the conditions (e.g., new condition to add, a condition to remove, new state to add to a condition, and/or state to remove for a condition), the computer programming code for the corresponding rules is to be modified in an effort to keep the rules database up-to-date. As an additional difficulty, the complexity of the information stored in electronic records is growing faster than the capability available for scaling up the rules in a rules database.
- The present invention represents a paradigm shift away from rules dependency. The present invention provides a contextually intelligent framework that leverages a contextualization mechanism in order to reduce a computerized system's dependence on rules and a rules database. By leveraging a contextualization mechanism, the present invention consumes less technological resources and more efficiently consumes technological resources (i.e., physical memory and processing power) relative to consumption in the absence of the systems, methods, and computer-readable media discussed hereinabove. Additionally, the present invention reduces the maintenance of keeping a rules database up-to-date and increase the capabilities for scaling-up a rules database with fewer rules (i.e., rule complexity increases while a total number of rules decreases), relative to computerized systems in the absence of the systems, methods, and computer-readable media discussed herein. The embodiments herein also provide robust support for high level cognitive structures, maintains greater consistency and implicit relationships when modeling knowledge, and reduces the number of errors. Generally, the embodiments herein provide improved knowledge consistency and implicit relationships, relative to over other computerized systems operating in the absence of the systems, methods, and computer-readable media discussed herein.
- Embodiments of the contextually intelligent framework perform refactoring of rules within a knowledge model. At a high level, refactoring reduces the number of rules and increases the number of concepts within a domain of an ontology, relative to other computerized systems operating in the absence of the contextualization mechanism. Accordingly, new concepts are identified and automatically used to generate new axioms based on the results of the refactoring methods discussed herein. By refactoring a knowledge model, the contextually intelligent framework modifies and improves the internal data structure of the knowledge model, while maintaining the desired external behavior of the knowledge model. For example, a single concept may be used to evaluate records with regard to Condition A. The one concept may, for example, replace n number of different rules that were initially drafted to evaluate Condition A in records. To illustrate refactoring of rules using the contextualization mechanism of the contextually intelligent framework, one concept might be used to replace 30 existing rules for evaluating electronic records for the clinical condition of spontaneous bacterial peritonitis and multiple available states for the clinical condition of spontaneous bacterial peritonitis. Additionally, because the enhanced knowledge model produced via the contextually intelligent framework has fewer rules after refactoring, the level of maintenance used for the enhanced knowledge model is reduced.
- Additionally, refactoring rules in order to identify new concepts and axioms increases the diversity and depth of the domain knowledge of the knowledge model, and increases the “reusability” of the knowledge model across domains. For example, while a rule is generally drafted and inherently limited in its application to evaluate a particular concept (e.g., Condition A) and a particular domain, concepts and axioms are generally not limited in application to a particular concept and a particular domain. As such, concepts and axioms increase the reusability of the knowledge model across domains, which is an improvement over the limitations of rules alone.
- Beginning with domain knowledge, domain knowledge refers to knowledge about the environment in which a system is operating. Exemplary domain knowledge includes clinical domain knowledge. Further examples of clinical domain knowledge include sepsis domain knowledge, unique electronic numbering domain knowledge (e.g., Bates numbering), and medical terminology domain knowledge (e.g., Medcin®, Systematized Nomenclature of Medicine (SNOMED)).
FIG. 1 illustrates a simplified representation of an exemplary clinical domain knowledge. Domain knowledge may be encoded (i.e., using a computer language and/or data) as one or more sets of rules, forming a knowledge model. A knowledge model comprises a repository that stores the sets of rules representing the domain knowledge as structured data and unstructured data. The rules of the knowledge model encode the domain knowledge as statements in the form of an “if-then” (antecedent-consequent) sentence that describes logical inferences obtained from the domain knowledge and the knowledge model itself.FIG. 2 illustrates an exemplary set of domain specific rules 200. The knowledge model is capable of storing, analyzing, reasoning, and reusing knowledge, such that a knowledge model is highly specialized and distinct from a hierarchal database or a relational database, for example. The terms “knowledge base” and “knowledge model” are used interchangeably herein. - While the knowledge model comprises a repository of rules for the domain knowledge, the knowledge model may also represent the domain knowledge using one or more ontologies. A domain ontology provides explicit, formal specifications of all of the terms within a domain knowledge and all of the relations among terms within the domain knowledge.
FIG. 3 illustrates a simplified representation of exemplary ontology. Generally, a domain ontology uses classes and subclasses to explicitly describe concepts in the domain. A domain ontology comprises a representation, formal naming, and definition of categories, properties, and relations between concepts and data associated with the domain knowledge. Each object within a class and each object within a subclass may be referred to as an “instance.” The classes, subclasses, and instances of the domain ontology may be represented in a taxonomic hierarchy. The terms “class” and “concept” are used interchangeably herein unless otherwise designated.FIG. 4 illustrates an exemplary taxonomic hierarchy of classes, subclasses, and/or instances of an ontology. The taxonomic hierarchy comprises a “tree” or a “backbone” representing the higher-level classes (i.e., corresponding to concepts in the domain knowledge) within the domain ontology, with subclasses and instances shown as nested nodes, wherein the nesting reflects the relations between classes, subclasses, and/or instances of an ontology. Generally, each class may have a designated “mode” that indicates a degree of certainty of the knowledge being represented. For example, a class representing Condition A may have a computer-determined mode of “Probable” or “Certain.” Instances within that class may include “observations” having a computer-determined state (e.g., value has increased, decreased, value is normal, abnormal, within normal range, outside of normal range). - In addition to representing the relations between classes, subclasses, and instances through a taxonomic hierarchy, an ontology may be represented using axioms. An axiom refers to an assertion in a logical form that is distinguishable from the previously-described rules. Together, a plurality of axioms formulate an overall theory of the corresponding ontology, as the ontology describes of defines the corresponding domain. Axioms may include a theory derived from other axiomatic statements, for example, thus generating inferential knowledge within the domain knowledge. For example, the symbol “⊆” is used to state that one element is a subset of another element. To illustrate, the exemplary axiom x⊆y (read from left to right) is a statement that x is a subset of y. As such, the exemplary axiom x⊆y is a statement that x is contained in y, and/or that y contains x. Further, the exemplary axiom x⊆y is a statement that x is obtainable from y by removing zero or more elements, and/or that y is obtainable from x by adding zero or more elements. Generally, the symbol “⊂” is used in an axiomatic statement to define membership of an element to another element, the symbols “∩” or “∧” are used in an axiomatic statement to define a conjunction between two or more elements, and the symbols “∈” or “159” are used in an axiomatic statement to define a disjunction between two or more elements. Accordingly, axioms are complex logical statements that are distinguishable from the relatively less complex “if-then” statements of the previously-described rules.
- Having discussed domain knowledge, knowledge models, rules, ontologies, and axioms, the knowledge model discussed herein comprises a domain-ontology-based taxonomic hierarchy that represents rules, axioms, and the relations between classes, subclasses, and/or instances within the ontology. A computer system generally leverages such a knowledge model to solve complex problems. At a specific level, a knowledge-based computer system includes a knowledge model, a user interface, and an inference engine. However, it will be understood that the systems and methods described hereinafter are not limited to such computer systems, and may be operable locally or remotely, using web-based applications, the cloud, local and/or distributed networks, servers, virtual servers, and/or virtual machines, for example.
- Embodiments described herein operate to modify and improve an existing knowledge model by improving the internal structure (e.g., rules, axioms) of the knowledge model, while maintaining the external behavior of the knowledge model. The embodiments comprise systems, methods, and computer-readable media that refactor and restructure a knowledge model of a domain knowledge. In some embodiments the domain knowledge that is modeled by the knowledge model is a clinical domain knowledge involving one or more of problems, allergies, medicines, immunizations, conditions (e.g., sepsis, spontaneous bacterial peritonitis, or spontaneous bacterial peritonitis with sepsis). Beginning with
FIG. 5 , anexemplary system 500 is shown. Thesystem 500 comprises adata repository 502 that stores data. Thedata repository 502 comprises amodel repository 504 that stores a plurality of knowledge models. Each of the knowledge models may correspond to a different domain knowledge, in one example. In another example, each of the knowledge models may correspond to one domain knowledge. For example, the domain knowledge of the clinical condition of Sepsis may be represented by a first knowledge model for Sepsis, a second knowledge model for Sepsis, and a third knowledge for Sepsis, wherein each knowledge model is different and stored in themodel repository 504. In this example, themodel repository 504 stores a plurality of knowledge models, wherein at least a portion of the knowledge models correspond to the same or similar domain knowledge. In another example, the domain knowledge of Immunizations may be represented by a first knowledge model, the domain knowledge of Allergies may be represented by a second knowledge model, and another domain knowledge of Medicines (e.g., pharmaceuticals, treatments, and clinical interventions) is represented by a third knowledge model, wherein each knowledge model is different and stored in themodel repository 504. A knowledge model comprises both explicit and implicit knowledge of the domain knowledge. For example,FIG. 6 presents an exemplary portion of amodel 600 that represents explicit (e.g., “WHEN”) and implicit (e.g., “INFER”) domain knowledge. As such, the portion of themodel 600 indicates how the model may generate implicit knowledge (e.g.,inferences model repository 504 of thedata repository 502. Thedata repository 502 further comprises ametrics repository 506 that stores a plurality of metrics reports. The metrics reports store information that quantify and describe the structure and complexity of the knowledge models, wherein the metrics reports are generated through one or more web-based applications, as discussed hereinafter. - The
data repository 502, themodel repository 504, and themetrics repository 506 may be managed and evaluated using one or more web-based applications. The web-based applications include acontrol center 508, through which a modelstructure differentiation tool 510, a modeloutput diversity tool 512, and amodel restructuring tool 514 are used to modify, and thus, improve the internal data structure (e.g., rules, axioms) of the knowledge model itself, while maintaining the external behavior of knowledge model. Thecontrol center 508 receives and reads one or more of the knowledge models stored in the model repository, in embodiments. For example, thecontrol center 508 receives and reads a first model (e.g., sepsis 1) and a second model (e.g., sepsis 2) for handoff to the other web-based applications. For example, each knowledge model comprises a knowledge model having rules, axioms, and one or more ontologies. Thecontrol center 508 provides the one or more knowledge models to the modelstructure differentiation tool 510 and/or the modeloutput diversity tool 512. - The model
structure differentiation tool 510 receives one or more knowledge models from thecontrol center 508. For example, the modelstructure differentiation tool 510 identifies a structure of a first knowledge model and identifies a structure of a second knowledge model. The term “structure” refers to one or more of the rules, axioms, taxonomic hierarchy of an ontology, rule maps, and a master document. In embodiments, the modelstructure differentiation tool 510 identifies the rules, axioms, taxonomic hierarchy, a rules maps, and a master document for each model received. When the modelstructure differentiation tool 510 receives two or more models, the modelstructure differentiation tool 510 may further determines differences between two or more of the models received. In further embodiments, the modelstructure differentiation tool 510 may determine differences an existing model prior to refactoring and said model after refactoring, as discussed hereinafter. For example, between a first and second model, the modelstructure differentiation tool 510 may recognize differences in one or more of: rules of the first model relative to rules of the second model, rule thresholds of the first model relative to rule thresholds of the second model, axioms of the first model relative to axioms of the second model, taxonomic hierarchy of the first model relative to taxonomic hierarchy of the second model, classes of the first model relative to classes of the second model, subclasses of the first model relative to subclasses of the second model rules mapping of the first model relative to a rules mapping of the second model, instances of the first model relative to instances of the second model and a master document of the first model relative to a master document of the second model. The modelstructure differentiation tool 510 may recognize each individual difference between two or more models relative to one another, for example. The modelstructure differentiation tool 510 may perform the identification of model structure and the recognition of structural differences between models corresponding to the same domain knowledge, in some embodiments. In other embodiments, the modelstructure differentiation tool 510 may perform the identification of model structure and the recognition of structural differences between models corresponding to the different and varied domain knowledge. For example, the modelstructure differentiation tool 510 may perform the identification of model structure and the recognition of structural differences between models corresponding to the same domain knowledge of Sepsis. In another example, the modelstructure differentiation tool 510 identify the structure of a Sepsis model structure and recognize structural differences between said model and a Spontaneous Bacterial Peritonitis model. Accordingly, the modelstructure differentiation tool 510 identifies and recognizes, based on the structure of one or more models, overlap in rules, axioms, taxonomic hierarchy, rules mapping, and master documents, independent of whether the models correspond to the same, similar, or different domain knowledge. - The model
structure differentiation tool 510 generates a model structure metrics report comprising the structural metrics of each model alone, and/or the structural metrics of the model relative to one or more other models (e.g., a refactored version of a model). As discussed in detail hereinafter, the recognition of overlap between models (e.g., pre-refactoring and post-refactoring) provides thesystem 500 with insight and knowledge of how refactoring changes a model. Further, the recognition of overlap between models corresponding to different domain knowledge provides thesystem 500 with insight and knowledge of how refactoring changes to one model may inadvertently result in a change to another, second model. Inadvertent results may produce errors or negatively impact the performance of one or more models that are not being refactored at the time. Once generated, the model structure metrics report is communicated to themetrics repository 506, in some embodiments. -
FIG. 7 provides anexemplary portion 700 of a model structure metrics report. Theexemplary portion 700 of the model structure metrics report identifies specific individual differences between a first model (e.g.,sepsis 1 is a first model prior to refactoring) and a second model (e.g., sepsis1-fca is the first model as refactored), such as, for example, a total number of rules in the first model, a total number of rules in the second model, a number of rules that are present in the first model and absent from the second model, and a number of rules that are absent in the first model and present in the second model. Theexemplary portion 700 of the model structure metrics report identifies specific individual differences between a first model (e.g., pre-refactoring sepsis1) and a second model (e.g., refactored sepsis1-fca), such as, for example, a total number of axioms in the first model, a total number of axioms in the second model, a number of axioms that are present in the first model and absent from the second model, and/or a number of axioms that are absent in the first model and present in the second model. Additionally or alternatively, theexemplary portion 700 of the model structure metrics report identifies specific individual differences between models, such as, for example, a total number of domain concepts in the first model, a total number of domain concepts in the second model, a number of domain concepts that are present in the first model and absent from the second model, and a number of domain concepts that are absent in the first model and present in the second model. As such, a model structure metrics report provides highly-granular, specific information as generated by the modelstructure differentiation tool 510. - In further embodiments, the model
structure differentiation tool 510 generates metrics regarding the rules in each model. For example, the model structure metrics report may include one or more of a rule premise size, a rule consequence, a rule size, a nodes count (e.g., with regard to taxonomic hierarchy), a count of specific value premise nodes, referenced entities, and the like, as determined and recognized by modelstructure differentiation tool 510.FIG. 8 provides anexemplary portion 800 of a model structure metrics report that provides rule size distribution(s) of a first model and a second model. The model structure metrics report may also be communicated with or shared with the modeloutput diversity tool 512 and/or themodel restructuring tool 514, in some embodiments. - The model
output diversity tool 512, receives one or more models from thecontrol center 508, in embodiments. Additionally or alternatively, modeloutput diversity tool 512, receives the model structure metrics report as input from the modelstructure differentiation tool 510. In embodiments, the modeloutput diversity tool 512 determines the “fecundity” or diversity of a knowledge model. As such, the modeloutput diversity tool 512 may determine complexity and depth of knowledge modeled by a first model (e.g., a model prior to refactoring) and a second model (e.g., said model subsequent to refactoring, or said model with anticipated changes to result when refactoring is implemented). Accordingly, the modifications and improvements to the internal structure of a knowledge model are quantifiable and visible via reports. In measuring the complexity and depth of the knowledge model, the modeloutput diversity tool 512 determines a number of distinct forms capable of being created from the rules, axioms, and concepts in the model, traces and identifies the number of distinct paths within each individual form, identifies which concepts lead to the same form(s), and/or determines a distribution of path(s) that may be generated from each individual consideration. The terms “path,” “output,” and “end-state” are used interchangeably herein. - In one embodiment, the model
output diversity tool 512 determines an overall output, output distribution, and/or output variation of a knowledge model, for example, pre-refactoring and/or post-refactoring. Generally, the overall output refers to a total number of distinct outputs a knowledge base is capable of generating. Accordingly, the overall outputs measures each and every distinct path that may be traced through the knowledge base, using the rules, axioms, and ontology of the knowledge base. Generally, the overall outputs does not consider overlap between paths such that two paths are determined to be distinct paths even through the two path may vary by only one different node, for example. - The output distribution refers to the distribution of the outputs capable of being produced, relative to other outputs produced by varied possible inputs. In simpler terms, the output distribution describes the distribution of outputs that may be produced by various inputs. Thus, the output distribution measures what variance of output may be produced by using all or many different inputs. The distribution of output values when charted may be clustered tightly together, or widely spread apart, for example. For example, when ten distinct inputs produce the same output, the ten distinct inputs are not widely distributed and are equivalent. In yet another example, when ten distinct inputs produce ten distinct outputs and the ten distinct outputs overlap each other at 90% in the output distribution, the ten distinct inputs may be recognized as equivalent (e.g., output-equivalent inputs). In another example, when both (K and input1⇒output1) and (K and input2⇒output1), the model
output diversity tool 512 determines that input1 and input2 belong to the same equivalence class, such that input1 and input2 are output-equivalent inputs. In contrast, when (K and input1⇒output1) and (K and input2⇒output2), the modeloutput diversity tool 512 determines that input1 and input2 do not belong same equivalence class, such that input1 and input2 are not output-equivalent inputs. - Output variation considers the degree of overlap between distinct paths (e.g., considers whether ten distinct paths only vary from one another by a single different node). The model
output diversity tool 512 determines output variation. Output variation describes a measure of variance of the outputs (e.g., outputs are very different from one another, outputs are very similar to one another). Generally, output variation describes how distinct outputs are from one another. For example, when a distribution of all 50 outputs overlap each other at 90%, the output variation is 10% (e.g., relatively low) because the outputs are not different from one another. In contrast, for example, when 90% of the 50 distinct outputs do not overlap one another in the output distribution, the output variation diversity is relatively high. In further embodiments, the output variation may be considered when determining the output distribution. In one example, when (K and input1⇒output1) and (K and input2⇒output2), and output1 and output2 overlap one another in the output distribution, the modeloutput diversity tool 512 may determine that input1 and input2 belong to the same equivalence class, such that input1 and input2 are output-equivalent inputs. The modeloutput diversity tool 512 may generating an output diversity report including one or more of the overall output, output distribution, and output variation. The output diversity report is communicated to themetrics repository 506, in some embodiments. The output diversity report may also be communicated with or shared with the modelstructure differentiation tool 510 and/or themodel restructuring tool 514. - The
model restructuring tool 514 receives one or more models as input from thecontrol center 508. For example, themodel restructuring tool 514 received a first knowledge model to be evaluated and refactored. Themodel restructuring tool 514 refactors rules in the first knowledge model, in embodiments, in order to generate said knowledge model as restructured and improved. At a high level, refactoring is performed in order to cure an inefficiently structured knowledge model. An existing knowledge model may be inefficiently structured when rules are initially created using artificial and/or arbitrary thresholds (e.g., cutoff points) and the existing knowledge model may comprise many different rules, as initially generated for each and every iteration of a concept, as previously discussed. Themodel restructuring tool 514 refactors rules and generates axioms when restructuring the knowledge model, thus improving the structure of knowledge model and increasing the complexity and depth of the domain knowledge. Using the methods and computer-readable media discussed hereinafter, thesystem 500, which includes themodel restructuring tool 514, restructures the knowledge base. Themodel restructuring tool 514 also generates results and exports the results to the model repository, in embodiments. In some embodiments, a refactored model is provided to the modelstructure differentiation tool 510 for generation of a model structure metrics report of the refactored model and/or is provided to the modeloutput diversity tool 512 for generation of an output diversity report of the refactored model, as previously discussed. - Turning to
FIG. 9 , a flow chart representing anexemplary method 900 is presented in accordance with embodiments of the present invention. In some embodiments, themethod 900 is performed via thesystem 500. In further embodiments, themethod 900 is performed via themodel restructuring tool 514. Themethod 900 may be a computerized method in an embodiment. In another embodiment, themethod 900 may be performed by executing one or more computer-readable media having non-transitory instructions stored thereon using one or more processors. - In embodiments, the
method 900 comprises determining that two or more rules in a knowledge model have different thresholds and correspond to a matching path, shown atblock 902. For example, recallingFIG. 2 , an exemplary set of domain specific rules are shown that reflect clinical domain knowledge of sepsis. As shown, the exemplary domain specific rules include various thresholds for a patient's age. As discussed previously, the exemplary domain specific rules may have been initially created using artificial and/or arbitrary thresholds (e.g., cutoff points). For example, a rule has been generated for various age ranges, with rule iterations involving values for blood pressure measurements obtained by a blood pressure cuff or blood pressure invasive and body temperatures, as shown in exemplaryFIG. 2 . Themethod 900 determines whether two or more domain specific rules in a knowledge model that have different thresholds also correspond to a matching path and/or the same output. - For example, recalling
FIG. 10 , there aremany rules 200 that reflect seven different age range thresholds and two different conditions (i.e., systolic blood pressure cuff, systolic blood pressure invasive). Within the exemplary rules, there are six different rules, each having different age ranges as thresholds for blood pressure (i.e., box 1002 (Age from 1 month)(Age up to 2 years), (Age from 0 day)(Age up to 1 week), (Age from 1 week)(Age up to 1 month), box 1004 (Age from 1 month)(Age up to 2 Years), (Age from 0 day)(Age up to 1 week), (Age from 1 week)(Age up to 1 month)). These six exemplary rules produce the same path such that all six rules share a “matching” path or output (i.e., (Systolic blood pressure) . . . [[is judged as VALUE decreased]]. In other words, when the same input n is evaluated against each of the six rules, the thresholds do not change the output of the rules such that the output is independent of the thresholds. Moreover, the rules may be determined to have matching paths, output, or end-states even when the rules reference different considerations such as methods of obtaining the input value (e.g., systolic blood pressure cuff, systolic blood pressure invasive).Boxes FIG. 10 to visually group various domain specific rules in the knowledge model having different thresholds and having a matching path.Boxes FIG. 10 to visually group various domain specific rules in the knowledge model having different thresholds and having a matching path. Boxes 1010 and 1012 are shown inFIG. 10 to visually group various domain specific rules in the knowledge model having different thresholds and having a matching path. - In another example shown in
FIG. 10 , eight different domain specific rules in the knowledge model, each having a different age range as a threshold of body temperature (i.e., Age from 0 day, Age up to 1 week), produce the same path, and thus, correspond to a matching path (i.e., all eight rules have an output, path, or end-state of [[is judged VALUE decreased]]). In such an example, when the same input n is evaluated against each of the eight rules, the various thresholds do not change the output, end-state, or path such that the eight rules are output-equivalents.Box 1014 is shown inFIG. 10 to visually group various domain specific rules in the knowledge model having different thresholds but that having a matching path. By determining that two or more rules in a knowledge model have different thresholds and determining that the two or more rules also correspond to a matching path, the two or more rules are used to generate one or more replacement rules, relatively condensed in number. - At
block 904, themethod 900 comprises generating a replacement rule having a composite threshold by refactoring the different thresholds of the two or more rules. In an embodiment, a single replacement rule is generated by refactoring several rules having varying thresholds and determined to correspond to the same path. For example, ten rules may be refactored in order to generate one single replacement rule. In another embodiment, multiple replacement rules are generated by refactoring of several rules such that the number of replacement rules is fewer than the original number of rules being refactored. In one example, ten rules may be refactored in order to generate five replacement rules having one or more new, refactored thresholds. - Turning to
FIG. 11 as an example, the domainspecific rules 200 ofFIG. 2 determined to be output equivalents may be refactored to generate one or more replacement rules with new thresholds. All of the various age thresholds shown in the domain specific 200 (e.g., there are eight initial age ranges) may be condensed into fiveage ranges FIG. 11 , each new composite age range threshold reflecting the refactoring of therules 200. For example, though now shown, the eight different domain specific rules for evaluating body temperature that have different age ranges as thresholds and all eight producing the same path (i.e., the output or end-state of [[is judged VALUE decreased]]), may be refactored to generate one replacement rule having a composite threshold of (Age from 0 day)(Age from 18 years). In some embodiments, generating the replacement rule having the composite threshold by refactoring the different thresholds of the two or more rules comprises merging the different thresholds of the two or more rules, wherein merging the different thresholds generates a composite threshold that comprises the different thresholds. As such, in some embodiments, a least a portion of the two or more rules are merged into one composite rule. - The
method 900 further comprises modifying the knowledge model by replacing the two or more rules with the replacement rule, as presented atblock 906. In an embodiment, a single replacement rule is generated from the refactoring of several rules having varying thresholds. Following the example of the eight different domain specific rules for evaluating body temperature, the one replacement rule having composite age threshold of (Age from 0 day)(Age from 18 years) may replace all eight of the existing rules within the knowledge model. Additionally or alternatively, because the eight rules indicated that the output decision of decrease in body temperature was produced (i.e., a same or matching path) regardless of an age, one new concept may be generated and used to replace the eight rules via themethod 900. The new concept may be used to generate a new axiom that replaces the eight rules, in such embodiments. In modifying the knowledge model, the two or more rules may be removed or deleted from the knowledge model. - Continuing, the
method 900 may be performed with respect to all rules within a knowledge model such that the entire knowledge model may be evaluated and refactored. By performing a refactoring directed to the whole knowledge model, for example, the number of rules in the knowledge base may be reduced, the average rule size may be reduced, the average size of an “if” premise (antecedent) in rules may be reduced, and/or the average size of a “then” statement (consequent) in rules may be reduced. Additionally or alternatively, by performing a refactoring with regard to all the rules in a knowledge model, for example, one or more additional concepts as axioms may be generated and added to the domain ontology of the knowledge model, wherein those additional concepts (i.e., represented as one or more new axioms) may be reused in one or more other domain ontologies (e.g., reusable axioms). The rules refactoring and generation of new concepts is such that themethod 900 changed the structure of the domain knowledge and improves the domain knowledge itself. As such, themethod 900 provides an improvement to domain knowledge and knowledge model technology. - In modifying one existing knowledge model by refactoring, the
method 900 may further determine and recognize rule, axiom, and/or concept overlap between the knowledge model and other knowledge models in different domains, for example. As such, themethod 900 has knowledge of exactly how refactoring a knowledge model may result in a change to another, second knowledge model, wherein those changes may produce errors or negatively impact the performance the second model. In some embodiment, themethod 900 herein may utilize the model structure metrics report in order to provide recommendations for refactoring, prior to implementing the modifications. Exemplary recommendations and/or modifications to the knowledge model may include a recommendation to add a disjunctive axiom, one or more rules to remove as redundant to one another or redundant to an axiom, and/or rule refactoring and rules to merge. The recommendations may be provided to a user for review and approval prior to modifying the knowledge model, and/or may be exported to themodel repository 504. - In further embodiments of the
method 900, themethod 900 comprises identifying a plurality of rules within the knowledge base. Themethod 900 may then determine a total number of different forms capable of being generated from the plurality of rules. Accordingly, themethod 900 may determine a total number of different paths available within each one of the different forms. Themethod 900 may further comprise generating and/or receiving an output diversity report and a model structure metrics report for a knowledge model, before and/or after refactoring. As such, themethod 900 may involve the modelstructure differentiation tool 510 and a modeloutput diversity tool 512, as previously described, in addition to themodel restructuring tool 514. - Additionally or alternatively, in some embodiments, the
method 900 may comprise identifying, for each one of the different paths determined within each one of the different forms, at least one rule corresponding to the path. In some embodiments, themethod 900 identifies, for each of the different forms, two or more rules that correspond to a matching path within the form. As such, each patch with a form may be evaluated in view of one or more rules. Then, themethod 900 may recognize whether two or more rules that correspond to the matching path have different thresholds, for example. The identification of rule thresholds may be performed before or after identifying one or more shared paths within a form, in various embodiments. - Continuing to
FIG. 12 , a flow chart representing anexemplary method 1200 is presented in accordance with embodiments of the present invention. In some embodiments, themethod 1200 is performed using the previously-describedsystem 500. In further embodiments, themethod 900 is performed using the modelstructure differentiation tool 510, the modeloutput diversity tool 512 and themodel restructuring tool 514, as previously described. Themethod 1200 may be a computerized method, in one embodiment. In another embodiment, themethod 1200 may be performed by executing one or more computer-readable media having non-transitory instructions stored thereon using one or more processors. - At
block 1202, themethod 1200 receives a knowledge model comprising a plurality of rules. In further embodiments, the knowledge model further comprises a plurality of axioms and/or one or more ontologies. The knowledge model may be uploaded, for example, into one or more web-based applications that provide an interface for performing themethod 1200 via one or more processors. Atblock 1204, themethod 1200 determines a total number of different forms capable of being generated from the plurality of rules. The different forms may be identified and each available path may be traced within each form. In some embodiments, themethod 1200 determines how many of the forms that are capable of being generated are also reusable for domain ontologies other that the domain ontology associated with the existing knowledge model. In yet another embodiment, themethod 1200 determines a measure or degree of diversity between each of the distinct paths capable of generation within each form, for example. In some embodiments, themethod 1200 may determine that two or more paths within one of the plurality of forms are input equivalent paths when the two or more path have a distribution overlap of at least 75%, 80%, or 90%. In one such embodiment, themethod 1200 may determine that two or more paths within a form are matching paths based on a determination that the two or more paths are input equivalent paths. Thus, even though two or more paths within a form may not be identical, the relatively high degree of overlap between the two paths may be sufficient to determine, via one or more processors, that the two paths correspond to a matching path. - For at least one form in the plurality of forms, the
method 1200 determines that at least two of the plurality of rules correspond to at least one form, as shown atblock 1206. At block, 1208 themethod 1200 determines that at least two of the plurality of rules that correspond to at least one form have different thresholds. Atblock 1210, themethod 1200 determines that at least two of the plurality of rules having different thresholds correspond to a matching path in the at least one form. As previously discussed, rules may be determined to correspond to one path or to a matching path when the different thresholds in the rules do not effectuate a change to the path in the form, when the same value n is input to the two or more rules, for example. - At
block 1212 themethod 1200 generates a replacement rule having a composite threshold by refactoring the different thresholds of the at least two of the plurality of rules having different thresholds and corresponding to the matching path in the at least one form. (The generation of replacement rules has been discussed in detail previously and is not reiterated here for brevity). Atblock 1214, themethod 1200 modifies the knowledge model by replacing the at least two of the plurality of rules with the replacement rule, as previously discussed. Themethod 1200 may be repeated for each rule within the plurality of rules of the knowledge model, in embodiments. As such, the entirety of the rules in the knowledge model may be refactored with respect to forms that may be generated. - Additionally or alternatively, the
method 1200 may generate, via the one or more processors, at least one axiom based on refactoring the different thresholds of the at least one of the plurality of rules. In such an embodiment, themethod 1200 modifies the knowledge model by adding the at least one axiom to the plurality of the axioms in the knowledge model. In another example, themethod 1200 may generate, via one or more processors, at least one concept based on the refactoring. In such an example, themethod 1200 modifies the knowledge model by adding the at least one concept to an ontology of the knowledge model. The addition of concepts to an ontology and axioms expressing the taxonomic hierarchy increases the complexity of the domain ontology and improves the reusability of the concepts in the knowledge model. - In one embodiment, the
method 1200 further determines, via one or more processors, that one or more of the plurality of rules are redundant based on at least one of the plurality of axioms. To illustrate redundancy detection, an examination of the exemplary axiom A⊂B (A is a subset of B), the rule A, C→D (a material conditional statement that if A, C are true, then D is also true), and the rule B, C→D (a material conditional statement that if B, C are true, then D is also true) reveals that the rule A, C→D is a redundant rule because the axiom defines that A is a subset of B and thus A is encompassed by the other rule B, C→D. When a rules is determined to be redundant to other rules and/or to an axiom, the redundant rules may be filtered out of the rule pool prior to refactoring, via themethod 1200. For example, themethod 1200 may modify the knowledge model by removing or deleting the one or more of the plurality of rules that are determined to be redundant from the knowledge base. - Once a knowledge model is refactored using the systems and/or methods discussed above, the knowledge model having an improved internal structure may be implemented and leveraged by computer systems, as discussed hereinafter.
- At a high level, embodiments of the present invention utilize concept-based models, also known as ontology-based models, as discussed above with regard to knowledge models, to reconcile information currently stored in one system with information imported from a plurality of diverse systems, in order to generate recommendations that promote continuity of care in clinical settings. As such, a refactored knowledge model having an improved internal structure may be implemented and leveraged by computer systems, such that ontology-based models within the refactored knowledge model are applied to evaluate and reconcile electronic information.
- At a practical level, other computerized systems are cumbersome and lack intelligence relative the systems, methods, and computer-readable media discussed herein. In an electronic medical information scenario, a clinician needs to navigate through a sequence of several GUIs before the clinician is able to comply with meaningful use requirements. The clinician imports information from multiple sources in different GUIs and compares the imported information presented on one GUI to the information currently on-file for a particular patient presented on another GUI (i.e., the clinician is navigating back and forth between different GUIs). The clinician then makes a decision as to whether the information currently on-file for a particular patient includes the imported information. All of these steps are repeated with regard to each of four different pieces of information in order to comply with meaningful use requirements: problems, allergies, medicines, and immunizations. Thus, the clinician has to slog through duplicate information, remember the information that they have visually seen, and then recognize when information is missing. This cumbersome compliance requirement is also repeated for every single patient encounter (e.g., a clinical visit or admission to a hospital).
-
FIG. 13 present anexemplary method 1300 in accordance with embodiments of the present invention. In some embodiments, themethod 1300 is preformed subsequent to modifying the knowledge model by replacing the at least two of the plurality of rules with the replacement rule, as discussed above. Themethod 1300 may be a computerized method, in one embodiment. In another embodiment, themethod 1300 may be performed by executing one or more computer-readable media having non-transitory instructions stored thereon using one or more processors. - In the
method 1300, electronic records are obtained from a plurality of diverse systems, as shown atblock 1302. The diverse systems having the records store and/or otherwise utilize the records in different data formats that may or may not be compatible with the other systems. In various embodiments, the electronic records obtained include registries (e.g., an immunization registry), electronic health records, electronic medical records, payer information, pharmacy records, laboratory information, employee information (i.e., which clinicians has, is, or will interact with a patient), and/or information captured by devices (i.e., data obtained from physiological monitoring devices capturing vital signs, etc.). The electronic records of each system may be stored in a particular format. Examples of data formats include HL7, FHIR, and XML. - The
method 1300 reconciles the records obtained from the plurality of diverse systems with one another using an ontology-based model within the knowledge base, as illustrated atblock 1304. In embodiments, reconciling the electronic records obtained from the plurality of diverse record systems comprises identifying, in the electronic records obtained from the plurality of diverse systems, information related to one or more of a medications ontology model, an allergies ontology model, an immunizations ontology model, and a problems ontology model. - In further embodiments, reconciling the electronic records obtained from the plurality of diverse record systems comprises applying one or more of the medications ontology model, the allergies ontology model, the immunizations ontology model, and the problems ontology model to the electronic records obtained from the plurality of diverse systems. Based on the application of one or more of the medications ontology model, the allergies ontology model, the immunizations ontology model, and the problems ontology model to the electronic records, recognizing discrete data items that are relevant to a meaningful use decision regarding one or more of medications, allergies, immunizations, and problems. In an embodiment, reconciling the electronic records obtained from the plurality of diverse record systems includes performing one or more of data cleansing, data standardization, concept or ontology normalization, records prioritization, and person matching on the electronic records.
- The
method 1300 continues by generating inferential knowledge based on reconciling the record, as shown atblock 1306. In an embodiment, generating inferential knowledge based on the discrete data items recognized as being relevant to a meaningful use decision regarding one or more of medications, allergies, immunizations, and problems. Additionally or alternatively, generating inferential knowledge comprises applying a forecasting model to the discrete data items, the forecasting model being specific to one of medications, allergies, immunizations, or problems. Based on applying the forecasting model to the discrete data items, a recommendation specific to one of medications, allergies, immunizations, or problems may be generated, in some embodiments. For example,FIG. 14 provides anexemplary GUI 1400. TheGUI 1400 includes one ormore recommendations vaccination record 1406 with an importedrecord 1408 for the patient. Thesingle GUI 1400 presents the patient's existingvaccination record 1406 in one pane side-by side with the importedrecords 1408 for the patient in another pane such that a user viewing theGUI 1400 does not need to navigate back and forth between different GUIs, screens, tabs, or the like. The recommendation requests a user input to confirm or deny the recommendation. For example, theGUI 1400 includes user-selectable options to Accept Allrecommendations 1410, Reject Allrecommendations 1412, as well as individuallyselectable options records 1408. When a user input confirms the recommendation, records are merged in an electronic health record for a patient and reconciliation for that particular information and the particular patient is concluded with regard to meaningful use compliance, for example. In another example,FIG. 15 provides anexemplary GUI 1500. TheGUI 1500 includes one ormore recommendations 1502 and 1504 to reconcile a patient's existingvaccination record 1506 with importedrecords 1508 for the patient. Thesingle GUI 1500 presents the patient's existingvaccination record 1506 side-by side with the importedrecords 1508 for the patient such that a user viewing theGUI 1500 does not need to navigate back and forth between different GUIs. The recommendation requests a user input to confirm or deny the recommendation. For example, theGUI 1500 includes user-selectable options to Accept Allrecommendations 1510, Reject Allrecommendations 1512, as well as individuallyselectable options 1514 and 1516 to accept or reject each recommendation regarding the importedrecords 1508. - Upon merging, patient care opportunities may be identified based on the inferential knowledge, in accordance with the
method 1300. For example, having merged selected and user-confirmed records on immunizations from diverse systems, themethod 1300 recognizes the patient is overdue to receive one vaccination and is approaching a deadline to receive another vaccination that is not yet overdue. Themethod 1300 may enable a clinical user to enter a medical order or may auto-populate a medical order for that patient to address the patient care opportunities. Accordingly, themethod 1300 generates inferential knowledge including patient's immunization status, a reason for the patient to be vaccinated, and a suggested vaccination opportunity, which are all provided to a clinician user when records are merged in an electronic health record for a patient, for example. - In some embodiments, reconciling the electronic records obtained from the plurality of diverse systems with one another includes identifying information in the electronic records that is not present in at least one of the plurality of systems. In one embodiment, the
method 1300 updates the at least one of the plurality of systems to include the identified information. - The methods discussed herein may be performed using a contextually intelligent framework. The contextually intelligent framework comprises a content management workspace, a content component definition model, a discern ontology, and electronic health records. The contextually intelligent framework integrates these components, which represent content, content definitions, and models, with one another for interoperability and for ontology-guided reconciliation of electronic records. Because these components and/or tools are integrated together to create the contextually intelligent framework, the contextually intelligent framework prevents data and information from being kept in separate silos.
- The content management workspace is a knowledge management system that supports structured clinical knowledge and terminology mapping, referencing, authoring, and license version management. The content component definition model is a model of reason over knowledge. The content component definition model provides contextualization of complex medical situations, supports clinical ontology, document models, bridge rules, analytics, and implicit relationships. The content component definition model further comprises multiple models of all questions and term hierarchies, for example. The content component definition model includes correlators, interpreters, data items, and attributes of data items, in embodiments.
- The discern ontologies provides a framework of concepts and concept templates. The discern ontology relies on specific pathways or “trees.” The content management workspace and the discern ontologies may comprise information regarding content definitions (e.g., standards, orders, diagnostics, education, and template questions). Additionally or alternatively, the content component definition model builds on the discern ontology's concepts and concept templates.
- The electronic health records are a source of current patient context, meaning that the electronic records include information as to what is known for a patient at the current point in time. In embodiments, the electronic health records are being reconciled with the information imported from a plurality of diverse systems, via the methods described herein and implemented through the contextually intelligent framework.
- Continuing, the contextually intelligent framework may be implemented in various ways. In one example, a system comprises a retrieval service, the contextually intelligent framework, and electronic health records and/or clinical workflows. In an embodiment, the retrieval service obtains, accesses, or otherwise retrieves a plurality of electronic records from diverse systems. In the context of meaningful use requirements, the retrieval service may perform patient information gathering for one or more of problems, allergies, medicines, immunizations, and in some embodiments, sepsis. The retrieval service may analyze the configuration of each of the diverse systems and the electronic records retrieved from each of the diverse systems. The retrieval service may prioritize one of the diverse systems over the other systems, for example. The retrieval service may create an order of importance or priority for the diverse systems, in some embodiments. The retrieval service may further group electronic records together or apart to reflect the diverse system from which the retrieval service obtained the electronic records. In the system, the retrieval service may perform a de-duplication of the electronic records. The retrieval service may group and/or sort the electronic records, as well. For example, when grouping records, the retrieval service may group two records together such that only one of the electronic records is hidden and another record, in said group, is shown to the system.
- In an alternative embodiment of the system, the contextually intelligent framework performs a de-duplication of the electronic records processed by the retrieval service. The contextually intelligent framework may group and/or sort the electronic records, in such an embodiment. For example, when grouping records, the contextually intelligent framework may group two records together such that only one of the electronic records is hidden and another record, in said group, is shown to the system.
- Continuing, in the system, the contextually intelligent framework applies forecasting models to the electronic records, as processed by the retrieval service. One or more forecasting models may be applied to electronic records corresponding to the patient for which information is being reconciled. In some embodiments, a model that is specific to problems, allergies, medicines, immunizations, or in some embodiments, sepsis, is applied. The forecasting model is ontology-based, such that the information being reconciled for a particular patient is placed into the context of a problem-specific ontology, an allergies-specific ontology, a medicine-specific ontology, an immunizations-specific ontology, or a sepsis-specific ontology, for example. The forecasting model is used to recognize, based on the patient information mapped to a specific ontology, recommendations to place a medical order for the patient, for example, wherein the medical order promotes continuity of care for the patient.
- The forecasting model provides the patient information, as mapped to a specific ontology, for reconciliation recommendations regarding another electronic health record and/or for providing the orderable recommendations to a clinician user via a clinical workflow. In embodiments, the forecasting model provides advanced decision support regarding one or more of meaningful use reconciliation requirements, problems, allergies, medications, and immunizations. As such, a reconciliation recommendation and/or an orderable recommendation may be output from the contextually intelligent framework. Reconciliation is achieved based on user input to confirm the reconciliation recommendation, at admission, discharge, and/or another time point regarding a patient encounter or clinical documentation. The orderable recommendations may be integrated automatically into one or more clinical workflows corresponding to the patient for which information is being reconciled.
- Hereinafter, an exemplary computing environment is described with regard to the systems, methods, and computer-media described hereinabove. Turning to
FIG. 16 , an exemplary computing environment is depicted, in accordance with an embodiment of the present invention. It will be understood by those of ordinary skill in the art that theexemplary computing environment 1600 is just one example of a suitable computing environment and is not intended to limit the scope of use or functionality of the present invention. Similarly, thecomputing environment 1600 should not be interpreted as imputing any dependency and/or any requirements with regard to each component and combination(s) of components illustrated inFIG. 16 . It will be appreciated by those having ordinary skill in the art that the connections illustrated inFIG. 16 are also exemplary as other methods, hardware, software, and devices for establishing a communications link between the components, devices, systems, and entities, as shown inFIG. 16 , may be utilized in implementation of the present invention. Although the connections are depicted using one or more solid lines, it will be understood by those having ordinary skill in the art that the exemplary connections ofFIG. 16 may be hardwired or wireless, and may use intermediary components that have been omitted or not included inFIG. 16 for simplicity's sake. As such, the absence of components fromFIG. 16 should be not be interpreted as limiting the present invention to exclude additional components and combination(s) of components. Moreover, though devices and components are represented inFIG. 16 as singular devices and components, it will be appreciated that some embodiments may include a plurality of the devices and components such thatFIG. 16 should not be considered as limiting the number of a device or component. - Continuing, the
computing environment 1600 ofFIG. 16 is illustrated as being a distributed environment where components and devices may be remote from one another and may perform separate tasks. The components and devices may communicate with one another and may be linked to each other using anetwork 1602. Thenetwork 1602 may include wireless and/or physical (e.g., hardwired) connections. Exemplary networks include a telecommunications network of a service provider or carrier, Wide Area Network (WAN), a Local Area Network (LAN), a Wireless Local Area Network (WLAN), a cellular telecommunications network, a Wi-Fi network, a short range wireless network, a Wireless Metropolitan Area Network (WMAN), a Bluetooth® capable network, a fiber optic network, or a combination thereof. Thenetwork 1602, generally, provides the components and devices access to the Internet and web-based applications. - The
computing environment 1600 comprises a computing device in the form of aserver 1604. Although illustrated as one component inFIG. 16 , the present invention may utilize a plurality of local servers and/or remote servers in thecomputing environment 1600. Theserver 1604 may include components such as a processing unit, internal system memory, and a suitable system bus for coupling to various components, including a database or database cluster. The system bus may be any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, and a local bus, using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronic Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus, also known as Mezzanine bus. - The
server 1604 may include or may have access to computer-readable media. Computer-readable media can be any available media that may be accessed byserver 1604, and includes volatile and nonvolatile media, as well as removable and non-removable media. By way of example, and not limitation, computer-readable media may include computer storage media and communication media. Computer storage media may include, without limitation, volatile and nonvolatile media, as well as removable and non-removable media, implemented in any method or technology for storage of information, such as computer-readable instructions, data structures, program modules, or other data. In this regard, computer storage media may include, but is not limited to, Random Access Memory (RAM), Read-Only Memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disks (DVDs) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage, or other magnetic storage device, or any other medium which can be used to store the desired information and which may be accessed by theserver 1604. Computer storage media does not comprise signals per se. - Communication media typically embodies computer-readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and may include any information delivery media. As used herein, the term “modulated data signal” refers to a signal that has one or more of its attributes set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency (RF), infrared, and other wireless media. Combinations of any of the above also may be included within the scope of computer-readable media.
- In embodiments, the
server 1604 uses logical connections to communicate with one or moreremote computers 1606 within thecomputing environment 1600. In embodiments where thenetwork 1602 includes a wireless network, theserver 1604 may employ a modem to establish communications with the Internet, theserver 1604 may connect to the Internet using Wi-Fi or wireless access points, or the server may use a wireless network adapter to access the Internet. Theserver 1604 engages in two-way communication with any or all of the components and devices illustrated inFIG. 16 , using thenetwork 1602. Accordingly, theserver 1604 may send data to and receive data from theremote computers 1606 over thenetwork 1602. - Although illustrated as a single device, the
remote computers 1606 may include multiple computing devices. In an embodiment having a distributed network, theremote computers 1606 may be located at one or more different geographic locations. In an embodiment where theremote computers 1606 is a plurality of computing devices, each of the plurality of computing devices may be located across various locations such as buildings in a campus, medical and research facilities at a medical complex, offices or “branches” of a banking/credit entity, or may be mobile devices that are wearable or carried by personnel, or attached to vehicles or trackable items in a warehouse, for example. - In some embodiments, the
remote computers 1606 is physically located in a medical setting such as, for example, a laboratory, inpatient room, an outpatient room, a hospital, a medical vehicle, a veterinary environment, an ambulatory setting, a medical billing office, a financial or administrative office, hospital administration setting, an in-home medical care environment, and/or medical professionals' offices. By way of example, a medical professional may include physicians; medical specialists such as surgeons, radiologists, cardiologists, and oncologists; emergency medical technicians; physicians' assistants; nurse practitioners; nurses; nurses' aides; pharmacists; dieticians; microbiologists; laboratory experts; genetic counselors; researchers; veterinarians; students; and the like. In other embodiments, theremote computers 1606 may be physically located in a non-medical setting, such as a packing and shipping facility or deployed within a fleet of delivery or courier vehicles. - Continuing, the
computing environment 1600 includes adata store 1608. Although shown as a single component, thedata store 1608 may be implemented using multiple data stores that are communicatively coupled to one another, independent of the geographic or physical location of a memory device. Exemplary data stores may store data in the form of artifacts, server lists, properties associated with servers, environments, properties associated with environments, computer instructions encoded in multiple different computer programming languages, deployment scripts, applications, properties associated with applications, release packages, version information for release packages, build levels associated with applications, identifiers for applications, identifiers for release packages, users, roles associated with users, permissions associated with roles, workflows and steps in the workflows, clients, servers associated with clients, attributes associated with properties, audit information, and/or audit trails for workflows. Exemplary data stores may also store data in the form of electronic records, for example, electronic medical records of patients, transaction records, billing records, task and workflow records, chronological event records, and the like. - Generally, the
data store 1608 includes physical memory that is configured to store information encoded in data. For example, thedata store 1608 may provide storage for computer-readable instructions, computer-executable instructions, data structures, data arrays, computer programs, applications, and other data that supports the functions and action to be undertaken using thecomputing environment 1600 and components shown in exemplaryFIG. 16 . - In a computing environment having distributed components that are communicatively coupled via the
network 1602, program modules may be located in local and/or remote computer storage media including, for example only, memory storage devices. Embodiments of the present invention may be described in the context of computer-executable instructions, such as program modules, being executed by a computing device. Program modules may include, but are not limited to, routines, programs, objects, components, and data structures that perform particular tasks or implement particular abstract data types. In embodiments, theserver 1604 may access, retrieve, communicate, receive, and update information stored in thedata store 1608, including program modules. Accordingly, theserver 1604 may execute, using a processor, computer instructions stored in thedata store 1608 in order to perform embodiments described herein. - Although internal components of the devices in
FIG. 16 , such as theserver 1604, are not illustrated, those of ordinary skill in the art will appreciate that internal components and their interconnection are present in the devices ofFIG. 16 . Accordingly, additional details concerning the internal construction device are not further disclosed herein. - Also, the present invention has been described in relation to particular embodiments, which are intended in all respects to be illustrative rather than restrictive. Thus the present invention is not limited to these embodiments, but variations and modifications may be made without departing from the scope of the present invention.
Claims (20)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US16/233,348 US20190197428A1 (en) | 2017-12-27 | 2018-12-27 | Systems and methods for refactoring a knowledge model to increase domain knowledge and reconcile electronic records |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201762610714P | 2017-12-27 | 2017-12-27 | |
US16/233,348 US20190197428A1 (en) | 2017-12-27 | 2018-12-27 | Systems and methods for refactoring a knowledge model to increase domain knowledge and reconcile electronic records |
Publications (1)
Publication Number | Publication Date |
---|---|
US20190197428A1 true US20190197428A1 (en) | 2019-06-27 |
Family
ID=66948926
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/233,341 Active 2041-11-17 US11605018B2 (en) | 2017-12-27 | 2018-12-27 | Ontology-guided reconciliation of electronic records |
US16/233,348 Pending US20190197428A1 (en) | 2017-12-27 | 2018-12-27 | Systems and methods for refactoring a knowledge model to increase domain knowledge and reconcile electronic records |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/233,341 Active 2041-11-17 US11605018B2 (en) | 2017-12-27 | 2018-12-27 | Ontology-guided reconciliation of electronic records |
Country Status (1)
Country | Link |
---|---|
US (2) | US11605018B2 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11675805B2 (en) | 2019-12-16 | 2023-06-13 | Cerner Innovation, Inc. | Concept agnostic reconcilation and prioritization based on deterministic and conservative weight methods |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10606958B2 (en) | 2018-01-10 | 2020-03-31 | International Business Machines Corporation | Machine learning modification and natural language processing |
US10423726B2 (en) | 2018-01-10 | 2019-09-24 | International Business Machines Corporation | Machine learning to integrate knowledge and natural language processing |
US10776586B2 (en) | 2018-01-10 | 2020-09-15 | International Business Machines Corporation | Machine learning to integrate knowledge and augment natural language processing |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20120041910A1 (en) * | 2009-04-30 | 2012-02-16 | Jacques Ludik | Method of establishing a process decision support system |
US20160180229A1 (en) * | 2014-12-17 | 2016-06-23 | Tata Consultancy Services Limited | Interpretation of a dataset |
Family Cites Families (151)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US3000978A (en) | 1959-11-12 | 1961-09-19 | Pittsburgh Plate Glass Co | Novel composition |
US4502708A (en) | 1982-03-18 | 1985-03-05 | Vickers, Incorporated | Power transmission |
US4847764C1 (en) | 1987-05-21 | 2001-09-11 | Meditrol Inc | System for dispensing drugs in health care instituions |
US5077666A (en) | 1988-11-07 | 1991-12-31 | Emtek Health Care Systems, Inc. | Medical information system with automatic updating of task list in response to charting interventions on task list window into an associated form |
US5072383A (en) | 1988-11-19 | 1991-12-10 | Emtek Health Care Systems, Inc. | Medical information system with automatic updating of task list in response to entering orders and charting interventions on associated forms |
JPH05197573A (en) | 1991-08-26 | 1993-08-06 | Hewlett Packard Co <Hp> | Task controlling system with task oriented paradigm |
US5721913A (en) | 1994-05-05 | 1998-02-24 | Lucent Technologies Inc. | Integrated activity management system |
US5557514A (en) | 1994-06-23 | 1996-09-17 | Medicode, Inc. | Method and system for generating statistically-based medical provider utilization profiles |
JP3267066B2 (en) | 1994-09-30 | 2002-03-18 | 富士ゼロックス株式会社 | Workflow support system |
US5842173A (en) | 1994-10-14 | 1998-11-24 | Strum; David P. | Computer-based surgical services management system |
US5745901A (en) | 1994-11-08 | 1998-04-28 | Kodak Limited | Workflow initiated by graphical symbols |
US5758095A (en) | 1995-02-24 | 1998-05-26 | Albaum; David | Interactive medication ordering system |
US5692125A (en) | 1995-05-09 | 1997-11-25 | International Business Machines Corporation | System and method for scheduling linked events with fixed and dynamic conditions |
US6671563B1 (en) | 1995-05-15 | 2003-12-30 | Alaris Medical Systems, Inc. | System and method for collecting data and managing patient care |
US6061506A (en) | 1995-08-29 | 2000-05-09 | Omega Software Technologies, Inc. | Adaptive strategy-based system |
US6037940A (en) | 1995-10-20 | 2000-03-14 | Araxsys, Inc. | Graphical user interface in a medical protocol system having time delay rules and a publisher's view |
US5790119A (en) | 1995-10-30 | 1998-08-04 | Xerox Corporation | Apparatus and method for programming a job ticket in a document processing system |
JP3493847B2 (en) | 1995-11-15 | 2004-02-03 | 株式会社日立製作所 | Wide-area medical information system |
US5799297A (en) | 1995-12-15 | 1998-08-25 | Ncr Corporation | Task workflow management system and method including an external program execution feature |
US5970463A (en) | 1996-05-01 | 1999-10-19 | Practice Patterns Science, Inc. | Medical claims integration and data analysis system |
US5842976A (en) | 1996-05-16 | 1998-12-01 | Pyxis Corporation | Dispensing, storage, control and inventory system with medication and treatment chart record |
US6064984A (en) | 1996-08-29 | 2000-05-16 | Marketknowledge, Inc. | Graphical user interface for a computer-implemented financial planning tool |
US5924074A (en) | 1996-09-27 | 1999-07-13 | Azron Incorporated | Electronic medical records system |
JPH10105623A (en) | 1996-09-27 | 1998-04-24 | Hitachi Ltd | Hierarchical work flow management method and work flow document circulation method |
US5937388A (en) | 1996-12-05 | 1999-08-10 | Hewlett-Packard Company | System and method for performing scalable distribution of process flow activities in a distributed workflow management system |
US5826239A (en) | 1996-12-17 | 1998-10-20 | Hewlett-Packard Company | Distributed workflow resource management system and method |
US5784635A (en) | 1996-12-31 | 1998-07-21 | Integration Concepts, Inc. | System and method for the rationalization of physician data |
JP2815346B2 (en) | 1997-01-31 | 1998-10-27 | 株式会社亀田医療情報研究所 | Medical planning support system |
WO1998044440A1 (en) | 1997-03-31 | 1998-10-08 | Bellsouth Intellectual Property Corporation | A system and method for generating an invoice to rebill charges to the elements of an organization |
US5991728A (en) | 1997-04-30 | 1999-11-23 | Deroyal Industries, Inc. | Method and system for the tracking and profiling of supply usage in a health care environment |
US5987422A (en) | 1997-05-29 | 1999-11-16 | Oracle Corporation | Method for executing a procedure that requires input from a role |
US6052669A (en) | 1997-06-06 | 2000-04-18 | Haworth, Inc. | Graphical user interface supporting method and system for remote order generation of furniture products |
US6304886B1 (en) | 1997-06-19 | 2001-10-16 | International Business Machines Corporation | System and method for building a web site using specific interface |
US6308188B1 (en) | 1997-06-19 | 2001-10-23 | International Business Machines Corporation | System and method for building a web site with automated workflow |
US6915265B1 (en) | 1997-10-29 | 2005-07-05 | Janice Johnson | Method and system for consolidating and distributing information |
US6314556B1 (en) | 1997-11-07 | 2001-11-06 | Deroyal Business Systems, Llc | Modular health care information management system utilizing reusable software objects |
US5995937A (en) | 1997-11-07 | 1999-11-30 | Deroyal Industries, Inc. | Modular health-care information management system utilizing reusable software objects |
US6088679A (en) | 1997-12-01 | 2000-07-11 | The United States Of America As Represented By The Secretary Of Commerce | Workflow management employing role-based access control |
US6225998B1 (en) | 1997-12-02 | 2001-05-01 | Aspect Communications | Visual design of workflows for transaction processing |
US6115646A (en) | 1997-12-18 | 2000-09-05 | Nortel Networks Limited | Dynamic and generic process automation system |
US6208974B1 (en) | 1997-12-30 | 2001-03-27 | Medical Management International, Inc. | Method and system for managing wellness plans for a medical care practice |
US6014629A (en) | 1998-01-13 | 2000-01-11 | Moore U.S.A. Inc. | Personalized health care provider directory |
WO1999044167A1 (en) | 1998-02-27 | 1999-09-02 | Rx Communications, Inc. | Pharmacy drug management system providing patient specific drug dosing, drug interaction analysis, order generation, and patient data matching |
US6078982A (en) | 1998-03-24 | 2000-06-20 | Hewlett-Packard Company | Pre-locking scheme for allowing consistent and concurrent workflow process execution in a workflow management system |
US6052684A (en) | 1998-03-24 | 2000-04-18 | Hewlett-Packard Company | System and method for performing consistent workflow process execution in a workflow management system |
US6208345B1 (en) | 1998-04-15 | 2001-03-27 | Adc Telecommunications, Inc. | Visual data integration system and method |
JPH11306244A (en) | 1998-04-16 | 1999-11-05 | Hitachi Ltd | Work management system |
US6430538B1 (en) | 1998-04-30 | 2002-08-06 | Enterworks | Workflow management system, method and medium with personal subflows |
US6728947B1 (en) | 1998-06-05 | 2004-04-27 | R. R. Donnelley & Sons Company | Workflow distributing apparatus and method |
US6067548A (en) | 1998-07-16 | 2000-05-23 | E Guanxi, Inc. | Dynamic organization model and management computing system and method therefor |
AU5670099A (en) | 1998-08-03 | 2000-02-28 | Corporate Express, Inc. | Customer management system for use with office products supplier |
JP2003528358A (en) | 1998-08-24 | 2003-09-24 | 富士通株式会社 | Workflow system and method |
US6311192B1 (en) | 1998-09-29 | 2001-10-30 | Electronic Data Systems Corporation | Method for initiating workflows in an automated organization management system |
US6349329B1 (en) | 1998-09-29 | 2002-02-19 | Radiowave.Com, Inc. | Coordinating delivery of supplemental materials with radio broadcast material |
AU2707200A (en) | 1998-11-30 | 2000-06-19 | Siebel Systems, Inc. | Assignment manager |
US6279009B1 (en) | 1998-12-04 | 2001-08-21 | Impresse Corporation | Dynamic creation of workflows from deterministic models of real world processes |
US6278901B1 (en) | 1998-12-18 | 2001-08-21 | Impresse Corporation | Methods for creating aggregate plans useful in manufacturing environments |
US6085184A (en) | 1998-12-22 | 2000-07-04 | Ac Properties B.V. | System, method and article of manufacture for a dynamic toolbar in a tutorial system |
US6308163B1 (en) | 1999-03-16 | 2001-10-23 | Hewlett-Packard Company | System and method for enterprise workflow resource management |
US6484144B2 (en) | 1999-03-23 | 2002-11-19 | Dental Medicine International L.L.C. | Method and system for healthcare treatment planning and assessment |
JP2001014389A (en) | 1999-06-25 | 2001-01-19 | Hitachi Ltd | Workflow server and client terminal |
US6970844B1 (en) | 1999-08-27 | 2005-11-29 | Computer Sciences Corporation | Flow designer for establishing and maintaining assignment and strategy process maps |
JP4529213B2 (en) | 2000-01-19 | 2010-08-25 | 富士ゼロックス株式会社 | Element organization support apparatus and storage medium on which element organization support program is recorded |
US7788631B2 (en) | 2000-02-24 | 2010-08-31 | General Dynamics Advanced Information Systems, Inc. | Process automation system |
US7725525B2 (en) | 2000-05-09 | 2010-05-25 | James Duncan Work | Method and apparatus for internet-based human network brokering |
US20030023593A1 (en) | 2000-05-11 | 2003-01-30 | Richard Schmidt | Real-time adaptive data mining system and method |
US6458080B1 (en) | 2000-05-31 | 2002-10-01 | International Business Machines Corporation | Managing parameters effecting the comprehensive health of a user |
US7457765B2 (en) | 2000-06-02 | 2008-11-25 | Drason Consulting Services, Llc | Method and system for scheduling employees in a patient care environment |
US20020018066A1 (en) | 2000-07-05 | 2002-02-14 | Amos Vizer | System and method for a dynamic professional syllabus |
US6618717B1 (en) | 2000-07-31 | 2003-09-09 | Eliyon Technologies Corporation | Computer method and apparatus for determining content owner of a website |
AU2002211405A1 (en) | 2000-10-02 | 2002-04-15 | International Projects Consultancy Services, Inc. | Object-based workflow system and method |
EP1332418A4 (en) | 2000-10-03 | 2006-06-07 | Michael Setteducati | Workflow management software overview |
US7027997B1 (en) | 2000-11-02 | 2006-04-11 | Verizon Laboratories Inc. | Flexible web-based interface for workflow management systems |
US7653566B2 (en) | 2000-11-30 | 2010-01-26 | Handysoft Global Corporation | Systems and methods for automating a process of business decision making and workflow |
US20020128871A1 (en) | 2000-12-07 | 2002-09-12 | Dan Adamson | Method, apparatus, and system for aggregating, targeting, and synchronizing health information delivery |
US7937655B2 (en) | 2000-12-22 | 2011-05-03 | Oracle International Corporation | Workflows with associated processes |
US20020128890A1 (en) | 2000-12-26 | 2002-09-12 | Appareon | System, method and article of manufacture for workflow management of a supply chain system |
US20020129031A1 (en) | 2001-01-05 | 2002-09-12 | Lau Lee Min | Managing relationships between unique concepts in a database |
US7240324B2 (en) | 2001-02-28 | 2007-07-03 | Hewlett-Packard Development Company, L.P. | Event-based scheduling method and system for workflow activities |
US7184967B1 (en) | 2001-03-06 | 2007-02-27 | Microsoft Corporation | System and method utilizing a graphical user interface of a business process workflow scheduling program |
US6966049B2 (en) | 2001-04-24 | 2005-11-15 | Heuristics Physics Laboratories, Inc. | Software development tool employing workflows for developing user interactive programs |
US20030158832A1 (en) | 2001-05-31 | 2003-08-21 | Sijacic Michael Anthony | Methods and system for defining and creating custom activities within process management software |
US7296056B2 (en) | 2001-07-30 | 2007-11-13 | International Business Machines Corporation | Method, system, and program for selecting one user to assign a work item in a workflow |
US7047535B2 (en) | 2001-07-30 | 2006-05-16 | International Business Machines Corporation | Method, system, and program for performing workflow related operations using an application programming interface |
US7689441B1 (en) | 2001-08-20 | 2010-03-30 | Siemens Medical Solutions Health Services Corporation | Integrated order and scheduling in a healthcare administration system |
US6714913B2 (en) | 2001-08-31 | 2004-03-30 | Siemens Medical Solutions Health Services Corporation | System and user interface for processing task schedule information |
US7653873B2 (en) | 2001-08-31 | 2010-01-26 | Siemens Medical Solutions Health Services Corporation | System and user interface supporting task schedule configuration |
US6912549B2 (en) | 2001-09-05 | 2005-06-28 | Siemens Medical Solutions Health Services Corporation | System for processing and consolidating records |
US7447644B2 (en) | 2001-09-12 | 2008-11-04 | Siemens Medical Solutions Usa, Inc. | System and user interface for processing healthcare related event information |
US20030074225A1 (en) | 2001-10-12 | 2003-04-17 | Borsand Gerald C. | Pharmaceutical information tracking system |
US7890349B2 (en) | 2001-10-22 | 2011-02-15 | Siemens Medical Solutions Usa, Inc. | Resource monitoring system for processing location related information in a healthcare enterprise |
US7437302B2 (en) | 2001-10-22 | 2008-10-14 | Siemens Medical Solutions Usa, Inc. | System for managing healthcare related information supporting operation of a healthcare enterprise |
US7788111B2 (en) | 2001-10-22 | 2010-08-31 | Siemens Medical Solutions Usa, Inc. | System for providing healthcare related information |
US7051012B2 (en) | 2001-10-22 | 2006-05-23 | Siemens Medical Solutions Health Services Corporation | User interface system for maintaining organization related information for use in supporting organization operation |
US7155720B2 (en) | 2001-10-26 | 2006-12-26 | Hewlett-Packard Development Company, L.P. | Dynamic task assignment in workflows |
US7756728B2 (en) | 2001-10-31 | 2010-07-13 | Siemens Medical Solutions Usa, Inc. | Healthcare system and user interface for consolidating patient related information from different sources |
WO2003040964A2 (en) | 2001-11-02 | 2003-05-15 | Siemens Medical Solutions Usa, Inc. | Patient data mining for diagnosis and projections of patient states |
US7457731B2 (en) | 2001-12-14 | 2008-11-25 | Siemens Medical Solutions Usa, Inc. | Early detection of disease outbreak using electronic patient data to reduce public health threat from bio-terrorism |
US6978268B2 (en) | 2002-03-16 | 2005-12-20 | Siemens Medical Solutions Health Services Corporation | Healthcare organization central record and record identifier management system |
US7590932B2 (en) | 2002-03-16 | 2009-09-15 | Siemens Medical Solutions Usa, Inc. | Electronic healthcare management form creation |
US7035862B2 (en) | 2002-05-09 | 2006-04-25 | Siemens Medical Solutions Health Services Corporation | Method for processing information from an information repository |
AU2003293339B2 (en) | 2002-12-03 | 2008-09-18 | Siemens Medical Solutions Usa, Inc. | Systems and methods for automated extraction and processing of billing information in patient records |
US20050027566A1 (en) | 2003-07-09 | 2005-02-03 | Haskell Robert Emmons | Terminology management system |
US7403936B2 (en) | 2004-03-05 | 2008-07-22 | Siemens Medical Solutions Usa, Inc. | Optimizing database access for record linkage by tiling the space of record pairs |
US8401986B1 (en) | 2004-08-05 | 2013-03-19 | Versata Development Group, Inc. | System and method for efficiently generating association rules |
US7562026B2 (en) | 2004-11-12 | 2009-07-14 | Siemens Medical Solutions Usa, Inc. | Healthcare procedure and resource scheduling system |
US8768741B1 (en) | 2005-01-03 | 2014-07-01 | Cerner Innovation, Inc. | Displaying an item of work in a workflow context |
US8775207B2 (en) | 2005-02-02 | 2014-07-08 | Siemens Medical Solutions Usa, Inc. | Integrated treatment planning and scheduling system |
US7650321B2 (en) * | 2005-02-16 | 2010-01-19 | Siemens Medical Solutions Usa, Inc. | Two classifier based system for classifying anomalous medical patient records |
US8652039B2 (en) | 2005-03-02 | 2014-02-18 | Siemens Medical Solutions Usa, Inc. | Guiding differential diagnosis through information maximization |
JP2008546098A (en) | 2005-05-31 | 2008-12-18 | シーメンス メディカル ソリューションズ ユーエスエー インコーポレイテッド | Data-dependent filtering system and method for patient demographic record query |
US8392232B2 (en) | 2005-06-16 | 2013-03-05 | Siemens Medical Solutions Usa, Inc. | Healthcare resource management system |
US20070130206A1 (en) * | 2005-08-05 | 2007-06-07 | Siemens Corporate Research Inc | System and Method For Integrating Heterogeneous Biomedical Information |
US7630947B2 (en) | 2005-08-25 | 2009-12-08 | Siemens Medical Solutions Usa, Inc. | Medical ontologies for computer assisted clinical decision support |
US7895055B2 (en) | 2005-12-14 | 2011-02-22 | Siemens Aktiengesellschaft | Method and system to optimize and automate clinical workflow |
US7805385B2 (en) | 2006-04-17 | 2010-09-28 | Siemens Medical Solutions Usa, Inc. | Prognosis modeling from literature and other sources |
US7844560B2 (en) | 2006-04-17 | 2010-11-30 | Siemens Medical Solutions Usa, Inc. | Personalized prognosis modeling in medical treatment planning |
US7813941B2 (en) | 2006-07-26 | 2010-10-12 | Siemens Medical Solutions Usa, Inc. | Patient bed search system |
US7840511B2 (en) | 2006-09-06 | 2010-11-23 | Siemens Medical Solutions Usa, Inc. | Learning or inferring medical concepts from medical transcripts using probabilistic models with words or phrases identification |
US8200527B1 (en) | 2007-04-25 | 2012-06-12 | Convergys Cmg Utah, Inc. | Method for prioritizing and presenting recommendations regarding organizaion's customer care capabilities |
US10231077B2 (en) | 2007-07-03 | 2019-03-12 | Eingot Llc | Records access and management |
US20090043634A1 (en) | 2007-08-06 | 2009-02-12 | Siemens Medical Solutions Usa, Inc. | Worker Adaptive Task management and Workflow System |
US20090112618A1 (en) | 2007-10-01 | 2009-04-30 | Johnson Christopher D | Systems and methods for viewing biometrical information and dynamically adapting schedule and process interdependencies with clinical process decisioning |
US8266168B2 (en) | 2008-04-24 | 2012-09-11 | Lexisnexis Risk & Information Analytics Group Inc. | Database systems and methods for linking records and entity representations with sufficiently high confidence |
US8571884B2 (en) | 2008-06-13 | 2013-10-29 | Aionex, Inc. | Healthcare communication and workflow management system and method |
US20100004948A1 (en) | 2008-07-01 | 2010-01-07 | Mckesson Financial Holdings Limited | Apparatus, method, system and computer program product for creating, individualizing and integrating care plans |
US20110071850A1 (en) | 2009-09-23 | 2011-03-24 | General Electric Company | Method and system for managing healthcare resources |
US20120245948A1 (en) | 2009-09-25 | 2012-09-27 | Mark Allen Nolte | Gauging resource intensiveness of providing care to a patient |
US9818164B2 (en) | 2009-09-25 | 2017-11-14 | Cerner Innovation, Inc. | Facilitating and tracking clinician-assignment status |
US8326667B2 (en) | 2010-06-14 | 2012-12-04 | General Motors Llc | Method and system for staffing a call center utilizing a time-based, graduated shrink ramp schedule |
US11068657B2 (en) * | 2010-06-28 | 2021-07-20 | Skyscanner Limited | Natural language question answering system and method based on deep semantics |
US9032513B2 (en) | 2010-09-01 | 2015-05-12 | Apixio, Inc. | Systems and methods for event stream platforms which enable applications |
US20120239671A1 (en) | 2011-03-16 | 2012-09-20 | Apixio, Inc. | System and method for optimizing and routing health information |
US10460266B2 (en) | 2010-12-30 | 2019-10-29 | Cerner Innovation, Inc. | Optimizing workflows |
US20130046558A1 (en) | 2011-08-18 | 2013-02-21 | Siemens Medical Solutions Usa, Inc. | System and Method for Identifying Inconsistent and/or Duplicate Data in Health Records |
US8909584B2 (en) | 2011-09-29 | 2014-12-09 | International Business Machines Corporation | Minimizing rule sets in a rule management system |
US20140058748A1 (en) | 2012-08-23 | 2014-02-27 | Cerner Innovation, Inc. | Populating custom patient worklists using demographic and clinical criteria |
US20140095203A1 (en) | 2012-09-28 | 2014-04-03 | Siemens Medical Solutions Usa, Inc. | Medical workflow determination and optimization |
US9129046B2 (en) | 2013-02-25 | 2015-09-08 | 4medica, Inc. | Systems and methods for managing a master patient index including duplicate record detection |
US20170124269A1 (en) | 2013-08-12 | 2017-05-04 | Cerner Innovation, Inc. | Determining new knowledge for clinical decision support |
US20150081326A1 (en) | 2013-09-19 | 2015-03-19 | Siemens Medical Solutions Usa, Inc. | Healthcare Process Management Using Context |
GB2521406A (en) | 2013-12-18 | 2015-06-24 | Ibm | Transforming rules into generalised rules in a rule management system |
TWI521466B (en) | 2014-02-07 | 2016-02-11 | 財團法人臺灣基督長老教會馬偕紀念社會事業基金會馬偕紀念醫院 | A computational device for data management and decision |
US20150317311A1 (en) | 2014-04-30 | 2015-11-05 | Cerner Innovation, Inc. | Patient search quality indicator |
US20150149362A1 (en) * | 2015-02-04 | 2015-05-28 | vitaTrackr, Inc. | Encryption and Distribution of Health-related Data |
US9864598B2 (en) | 2015-09-18 | 2018-01-09 | ReactiveCore LLC | System and method for providing supplemental functionalities to a computer program |
US11610075B2 (en) | 2016-04-29 | 2023-03-21 | Hewlett Packard Enterprise Development Lp | Hierarchical rule clustering |
US10671646B2 (en) | 2016-12-22 | 2020-06-02 | Aon Global Operations Ltd (Singapore Branch) | Methods and systems for linking data records from disparate databases |
US20200342991A1 (en) | 2018-01-16 | 2020-10-29 | Koninklijke Philips N.V. | Detecting recurrence of a medical condition |
US11327975B2 (en) | 2018-03-30 | 2022-05-10 | Experian Health, Inc. | Methods and systems for improved entity recognition and insights |
US11675805B2 (en) | 2019-12-16 | 2023-06-13 | Cerner Innovation, Inc. | Concept agnostic reconcilation and prioritization based on deterministic and conservative weight methods |
-
2018
- 2018-12-27 US US16/233,341 patent/US11605018B2/en active Active
- 2018-12-27 US US16/233,348 patent/US20190197428A1/en active Pending
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20120041910A1 (en) * | 2009-04-30 | 2012-02-16 | Jacques Ludik | Method of establishing a process decision support system |
US20160180229A1 (en) * | 2014-12-17 | 2016-06-23 | Tata Consultancy Services Limited | Interpretation of a dataset |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11675805B2 (en) | 2019-12-16 | 2023-06-13 | Cerner Innovation, Inc. | Concept agnostic reconcilation and prioritization based on deterministic and conservative weight methods |
Also Published As
Publication number | Publication date |
---|---|
US11605018B2 (en) | 2023-03-14 |
US20190197421A1 (en) | 2019-06-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11605018B2 (en) | Ontology-guided reconciliation of electronic records | |
Chatterjee et al. | A hybrid MCDM technique for risk management in construction projects | |
US20200251225A1 (en) | Health information transformation system | |
Peleg | Computer-interpretable clinical guidelines: a methodological review | |
Mans et al. | Process mining in healthcare: evaluating and exploiting operational healthcare processes | |
US8015136B1 (en) | Algorithmic method for generating a medical utilization profile for a patient and to be used for medical risk analysis decisioning | |
US20200402665A1 (en) | Unplanned readmission prediction using an interactive augmented intelligent (iai) system | |
AU2011319965B2 (en) | System and method for machine based medical diagnostic code identification, accumulation, analysis and automatic claim process adjudication | |
Kiourtis et al. | Structurally mapping healthcare data to HL7 FHIR through ontology alignment | |
US11250954B2 (en) | Patient readmission prediction tool | |
US20150088548A1 (en) | System and Method for Determining a Sufficiency of Data Entry in an Electronic Health Record | |
Sanchez et al. | A knowledge-based clinical decision support system for the diagnosis of Alzheimer disease | |
US11935630B2 (en) | System assisted data blending | |
US20210005312A1 (en) | Health management system with multidimensional performance representation | |
US10755197B2 (en) | Rule-based feature engineering, model creation and hosting | |
Sreenivasan et al. | Interoperability issues in EHR systems: Research directions | |
US20180005123A1 (en) | Combining semantic and business process modeling in a multi-layer framework | |
Liu et al. | Requirements engineering for health data analytics: Challenges and possible directions | |
Papadopoulos et al. | A systematic review of technologies and standards used in the development of rule-based clinical decision support systems | |
Ozonze et al. | Automating electronic health record data quality assessment | |
Mandreoli et al. | Real-world data mining meets clinical practice: Research challenges and perspective | |
Cremonesi et al. | The need for multimodal health data modeling: A practical approach for a federated-learning healthcare platform | |
Ong et al. | A framework for classification of electronic health data extraction-transformation-loading challenges in data network participation | |
Saiod et al. | Electronic health records: benefits and challenges for data quality | |
CN114188036A (en) | Operation scheme evaluation method, device and system and storage medium |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: CERNER INNOVATION, INC., KANSAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:THE UNIVERSITY OF MANCHESTER;REEL/FRAME:050675/0388 Effective date: 20190410 Owner name: CERNER INNOVATION, INC., KANSAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:KODISH-WACHS, JODI;OVERHAGE, JOSEPH MARCUS;MCKNIGHT, LAWRENCE;AND OTHERS;SIGNING DATES FROM 20190130 TO 20190305;REEL/FRAME:050675/0358 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: PRE-INTERVIEW COMMUNICATION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE AFTER FINAL ACTION FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: ADVISORY ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |