System and method for ontologically classifying records

Abstract

A system and method for procedure-based decision support using ontology-based classification of database records are described. The procedure-based decision support can facilitate the extraction of contextually relevant data from a database. The data is formatted to be compatible with a data library of a knowledge base using one or more scripts and populated into the library as entities. The classification of the entities can be inferred using the available data. One or more classifications of the entities may be returned to the procedure-based decision support to facilitate the calculation of recommended values.

Description

Technical Field

[0001] Technical Field Aspects of the present application relate to devices, systems, and methods for classifying records based on asserted ontology axioms.

Background Art

[0002] Background Conventional electronic health records (EHRs) generally utilize relational databases for organizing and storing patient records. These databases use structured and unstructured fields to store values (e.g., numerical values, descriptive values, or explanatory values) in any number of tables and nested tables. While relational databases facilitate the storage of vast amounts of data, complex queries conventionally required each iteration of the query to be described in procedural code. For example, decision support applications (e.g., patient care workflow automation applications) conventionally operate using computational algorithms that proceed based on complex query schemas.

Summary of the Invention

[0003] Brief Summary In order to aggregate and evaluate complex query requests (e.g., queries that include multiple inclusion criteria, exclusion criteria, or a combination of both) in a conventional computerized system, each iteration of the query is expressed as procedural code. The systems, methods, and devices described herein present a paradigm shift from these conventional procedure-based constraints. In contrast to conventional systems, the systems described herein facilitate a hybrid procedural- and ontology-based data evaluation. Among several advantages, the systems, methods, and devices described herein can detect trigger events such as changes to fields of database records via a set of procedurally-executed code that monitors operations associated with a database that holds database records. Database records can be relationally linked to a plurality of database fields that include fields of the database records. A plurality of values stored in the plurality of database fields, and field addresses for each of the plurality of values, can be extracted from the database records by a procedurally-executed portion of the code (e.g., an object-oriented script). In some aspects, an identifier that links a database field to a database record can be extracted. Based on the extracted values, by executing a script that writes a formatted version of the plurality of values to a corresponding set of fields mapped to the plurality of database fields based on the field addresses, an entity is generated within a knowledge base library. Based on inferences drawn from an inference component retrieved from a knowledge base library that includes the generated entity, a class of the entity is computed. In response to the computation of the entity class, classification data of the entity is returned as an input to a procedurally-defined workflow. The classification data can include at least findings of a value among the plurality of values within the entity, and a superclass ontologically defined by inferences drawn from an inference component retrieved from a knowledge base library that includes the generated entity. Based on the classification data, workflow actions can be executed within a procedurally-defined workflow.

[0004] The present invention will be described in detail with reference to the accompanying drawings in this specification.

Brief Description of the Drawings

[0005]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Modes for Carrying Out the Invention

[0006] Detailed Description To understand and aggregate information stored in electronic records, conventional computerized systems applied rules for evaluating selected records. Separate rules were used to evaluate each possible combination of variables and variable values that could exist in the records. Thus, different rules were prepared to accommodate each and every individual combination of variables and / or values of each variable. For example, for evaluating a record with respect to one condition (e.g., a variable) having multiple available states (e.g., values), rules were prepared for each different permutation of possible combinations that could exist in the record. As the amount of information stored in electronic records increased, the number and complexity of the rules used increased. For this reason, a huge number of rules were required in conventional computerized systems.

[0007] For example, to aggregate and evaluate by a conventional computerized system whether any of a plurality of records stored in a relational database supports the progression from a first point to a second point in a decision support workflow, rules for evaluating each combination of individual variables and / or values may be required. Generally, a decision point is a procedural and programmed step within a workflow, where the progression along one of at least two possible paths is defined by a set of rules. The paths can be simple (e.g., a closed loop, or its equivalent on the program, waiting until the rules of the decision point are satisfied) or complex. In a conventional workflow, the evaluation of the data stored in the database by an algorithm may be included in these two paths. As a simplified example, a conventional decision point may include an if / else programming expression. If the condition of the if expression is satisfied, the workflow can proceed along the path defined by the workflow. Otherwise, the workflow can proceed along the path defined by the else expression of the workflow.

[0008] Even if there are only five conditions where a particular decision point has four available states for condition A, six available states for condition B, three available states for condition C, three available states for condition D, and four available states for condition E, a conventional computerized system may need to use 864 different rules to access and evaluate each of the 864 available combinations. For example, a conventional patient care workflow for automating the diagnosis of a viral infection may include procedural rules for each combination of clinical test values (e.g., oxygen saturation, cell count, antibody count, PCR results, etc.) and physical symptoms (e.g., body temperature, inflammation, cough, etc.) that are defined as necessary to verify a viral infection. Additionally, rules may be required for each combination of types of values that may be stored in a record. Furthermore, conventional procedural code may include rules for each combination of fields that may be used in a relational database. For example, body temperature values may be stored in various locations within a database based on the source of the body temperature measurement (e.g., oral, temporal, rectal, etc.) and the unit used to record the body temperature (e.g., Celsius or Fahrenheit).

[0009] Furthermore, differences between the structures of any two relational databases can prevent the interoperability of procedural code because the organization of a particular field may be different in the structure of each relational database. In other words, these procedurally coded rules may only be able to evaluate a single relational database structure, in which case a conventional computerized system cannot reuse procedurally coded rules for any relational database that does not follow a particular structure.

[0010] Therefore, the rules database consumes a huge amount of computer-readable memory to store assistance rules for record evaluation involving hundreds or thousands of conditions. Further, in conventional computerized systems, a significant amount of processing resources are used to execute rules for evaluation involving hundreds or thousands of conditions against records. Further, each time a change is made to a condition or one of the available states for a condition (e.g., addition of a new condition, deletion of a condition, addition of a new state to a condition, or deletion of a state for a condition), the procedural code for the corresponding rule is changed to keep the rules database up to date.

[0011] The aspects described herein represent a paradigm shift away from dependence on procedural rules. More precisely, the aspects described herein may facilitate a hybridization of decision support executed procedurally and classification inference based on ontologies. In particular, the aspects described herein provide methods, systems, and media for facilitating the automatic import of variables and / or values related to one or more decision support workflows by a knowledge base library. In some aspects, the automatic import of variables and / or values is facilitated by one or more scripts. For example, a script may be executed that maps the location (e.g., field address) of a database field of variables and / or values called by a decision support workflow to a corresponding set of fields of entities in the knowledge base library. The inference unit may be able to classify variables and / or values based on the asserted relationships in the knowledge base library, and classification data may be returned to facilitate the calculations defined by one or more decision support workflows. The classification data may be the class, direct superclass, or indirect superclass to which the generated entity belongs.

[0012] Referring to FIG. 1, an exemplary process flow 100 includes a knowledge-based classification system and a hybrid procedural decision support workflow according to the aspects described herein. The decision support workflow can be any other workflow that includes a diagnostic support workflow, a reservation scheduling support workflow, a claims processing support workflow, or a trigger (e.g., an action that starts the workflow detected by a program), and at least one decision point (e.g., an algorithm that evaluates data programmed in a procedural manner), including an algorithm programmed in a procedural manner. Generally, the process flow 100 facilitates the progression from a first point to a second point of the decision support workflow. In some aspects, the first point can be a trigger for the workflow, and the second point can be an end or non-end decision point in the workflow.

[0013] Some embodiments of the process flow 100 can start from the initiation of the decision support process 102. The initiation of the decision support process 102 can be triggered by any action detected by a program that starts the decision support workflow based on the process that the workflow supports. For example, in some aspects, the initiation of the decision support workflow can be automatically triggered in response to the program detection of a change in a database record. The change in the database record can include the addition of data to one or more fields of the database that holds the database record. For example, referring briefly to FIG. 3, the initiation of the decision support process can be triggered by the decision support application 312 that monitors the operation of the record database 320 held by the record repository server 316. The initiation of the decision support process workflow 102 can be triggered in response to the periodic, continuous, intermittent, or on-demand execution of the decision support workflow. For example, referring briefly to FIG. 3, the initiation of the decision support process can be triggered by the periodic, continuous, intermittent, or on-demand execution of the workflow 314 held by the decision support application 312.

[0014] In some embodiments of process flow 100, the data from the database records is analyzed in block 104 based on the launched decision support workflow. The data may be analyzed from database 128 using any suitable means. For example, in one particular aspect, a script is programmatically coded to extract the values stored in the database fields associated with the first decision point of the launched decision support workflow. In some embodiments, one of the values extracted corresponds to an identifier of the database record. The identifier may be an alphanumeric value associated with each of the fields of the database record. For example, the identifier can be a patient identification value, an index key value, or any other value that defines the relationship of multiple fields as belonging to the same database record. Further, in block 104, a field address corresponding to each of the database fields storing the extracted values can be extracted. The field address can be a value that uniquely identifies the identity or location of the field in the database. Database records in the database may include multiple values in fields associated with a particular field address (e.g., multiple fields having a field address identified as storing temperature in degrees Celsius).

[0015] The exemplary process flow 100 includes, at block 106, mapping the extracted data to entities within a knowledge-based system. In some aspects, the extracted data is mapped by execution of a script within a decision support application (e.g., the decision support application 312 of FIG. 3). The script can include a programming formula that writes a formatted version of the field value to a corresponding field within an entity of the knowledge-based system. The script can, additionally or alternatively, communicate the formatted version of the field value to an ontology-derived classification component (e.g., the ontology-derived classification component 302 of FIG. 3). For example, the script can determine the identity of each value extracted from the database based on the field address. Further, the script can include a formula that links the field address associated with the database to the field address of an entity within the knowledge-based system library. The script can further include a formula that converts the format of the extracted value to the native format of the corresponding field within the entity. For example, the script can convert a value from a small integer field to a floating point number. As another example, the script can perform a conversion from a variable string to a fixed string, a conversion from a decimal to a floating point number, or any other format conversion. Further, the script can include a formula that converts the value to the native unit of the corresponding field within the entity. For example, a value stored in a field having a field address identified as storing temperature in Celsius can be converted to Fahrenheit. As another example, a value stored in a field identified as storing a date of birth can be converted to an age in days, months, years, or any combination thereof.

[0016] In some aspects of process flow 100, block 106 includes creating an entity within a knowledge-based system. For example, the script may include a programmatic way to query the knowledge-based system about an entity corresponding to the identifier extracted from the database at block 104. If the knowledge-based system includes an entity corresponding to the identifier, the script can use other data extracted from database 128 to modify the entity within the knowledge-based system. On the other hand, if the knowledge-based system does not include an entity corresponding to the identifier, the script can automatically perform the operation of creating a new entity within the knowledge-based system. In one aspect, at least one field including the identifier extracted from database 128 is populated in the newly created entity. Similarly, the script can facilitate the creation of an entity by communicating the extracted data to an ontology-induced classification component (e.g., ontology-induced classification component 302 of FIG. 3).

[0017] Some aspects of process flow 100 include, at block 130, initiating an ontology-guided classification of entities generated or modified at block 106 within a knowledge-based system. For example, inference unit 108 can be activated to classify entities based on the logical consequences of the data asserted in the entities. As shown in FIG. 1, the output of inference unit 108 includes classification data 110. Classification data 110 includes at least one inferred classification of an entity stored within a knowledge base library. In other words, referring briefly to FIG. 3, inference unit 108 accepts the rules, concepts, classes, and the relationships connecting each as logical axioms that are true, as defined by data schema knowledge 304 and taxonomy knowledge 306. Inference unit 108 evaluates each entity in the library according to the rules and concepts and infers to which class 114 that entity belongs. For example, if inference unit 108 infers based on the asserted axioms that an entity contains data belonging to an unconfirmed diagnosis class, inference unit 108 assigns that entity to that unconfirmed diagnosis class within the knowledge base library. Similarly, in one aspect, inference unit 108 assigns a field of an entity to a finding class 112 based on the asserted axioms. For example, a body temperature field having a value of 98.6 can be classified as belonging to the "normaltemperature" finding class. In contrast, a body temperature field having a value of 102.7 can be classified as belonging to the "increasedtemperature" finding class. In other words, inference unit 108 can classify entities and the constituent fields of entities based on the asserted axioms.

[0018] In some embodiments, the inference unit 108 can output additional classification data. For example, the inference unit 108 can identify at least one superclass 116 or direct superclass of an entity, or at least one file, based on the asserted axioms. A superclass refers to all classes including the ontological hierarchy of the inferred class. A direct superclass refers to any class immediately above the inferred class in the ontological hierarchy.

[0019] Furthermore, the inference unit 108 can write data to a database or a file. In some embodiments, the inference unit 108 writes data to a database or a file in response to the classification of an entity. For example, the inference unit 108 can output the class to which the entity belongs, the superclass to which the entity belongs, the direct superclass to which the entity belongs, the class to which the field of the entity belongs, the superclass to which the field of the entity belongs, the direct superclass to which the field of the entity belongs, or any combination thereof.

[0020] Some embodiments of the process flow 100 include communicating the classification data 110 to a decision support process at block 118. In some embodiments, the communication of the classification data 110 can be facilitated by at least one script. For example, the script can include a programmatic form that inputs a formatted version of at least one classification data into a field in the decision support workflow.

[0021] Some aspects of process flow 100 include, at block 120, executing an algorithm of a decision support process workflow based on classification data. In some aspects, the decision support process workflow may proceed to a first decision point in the workflow based on the classification data. For example, referring to FIG. 2, an exemplary decision support process workflow 200 including decision points according to the aspects described herein is provided. As shown, the decision support process workflow 200 may facilitate a diagnostic response to Covid-19. The exemplary decision support process workflow 200 includes a trigger event at block 202, decision points 206 and 214, and end points 208, 210, 212, 216, 218, 220, 222, 224, and 226. The trigger event at block 202 initiates a classification of the patient's knowledge base based on data stored in the electronic health record (EHR) corresponding to the patient. The classification data is returned to the algorithm of the decision support process workflow and analyzed at block 204. In response, the exemplary decision support process workflow 200 proceeds to decision point 206.

[0022] At decision point 206, the classification data is analyzed based on an algorithm represented by a program associated with decision point 206. As illustratively shown in FIG. 2, decision point 206 includes four possible paths. A patient can be evaluated by decision point 206 as a confirmed Covid-19 diagnosis, a positive Covid-19 test result, a negative Covid-19 test result, or no Covid-19 diagnosis or test. If the analysis of the classification data corresponding to the patient entity meets at least one of the rules of decision point 206, the exemplary decision support process workflow 200 can proceed to the next procedural type process of the workflow. For example, patients evaluated by decision point 206 as a confirmed Covid-19 diagnosis, a positive Covid-19 test result, or a negative Covid-19 test result proceed to terminal points 208, 210, or 212, respectively. In contrast, patients evaluated by decision point 206 as no Covid-19 diagnosis or test proceed to decision point 214.

[0023] Returning to FIG. 1 and continuing to refer to FIG. 2, some embodiments of flow 100 include, at block 122, determining whether a terminal point has been reached in the decision support process workflow. For example, based on the classification data, a script can determine whether decision support process workflow 200 has proceeded to terminal points 208, 210, 212, 216, 218, 220, 222, or 224. If the decision support process workflow has proceeded to a terminal point, flow 100 performs, at the terminal point of block 126, the actions encoded by the decision support process workflow. For example, the decision support process workflow may modify a query to a care provider, or instruct a patient's record (e.g., a database record) with a script that triggers a warning when a clinical intervention, or a portion of a database record, is viewed via an application. Additionally, the workflow of the decision support process can, among other things, automatically initiate another workflow or generate and communicate a request for information.

[0024] Alternatively, when the decision support process workflow has advanced to a decision point (e.g., decision point 214) or any other non-terminal point within the workflow, process flow 100 advances to block 124. At block 124, process flow 100 determines whether the workflow has reached the same point with respect to the database record based on the same data parsed from the database record. For example, a script can evaluate a log file to determine whether the decision support process workflow 200 has previously advanced to decision point 206 or 214 but cannot advance further. Further, this script can evaluate the log file and the database record to determine whether data has been added to the patient's record (e.g., the database record) after the decision support process workflow 200 has advanced to decision point 206 or 214 but cannot advance further. In response to a determination that new data has been added or that the workflow has not advanced to the same point, block 124 can return to block 104. Alternatively, in response to a determination that no new data has been added and that the workflow has advanced to the same point, block 124 can advance to block 126.

[0025] Referring to FIG. 3, an exemplary system 300 is shown that includes a knowledge-based classification system hybridized with a procedural decision support according to the aspects described herein. Generally, system 300 facilitates the execution of a procedurally coded decision support workflow (e.g., workflow 200 of FIG. 2) using classification data output from a knowledge-based ontology-driven processing environment 340. Some aspects of system 300 include an ontology-driven classification component 302, a network 308, at least one user device 310, a decision support application 312, and a record repository server 316.

[0026] The ontology-derived classification component 302 can include hardware, software, firmware, or any combination thereof. Further, some aspects of the ontology-derived classification component 302 can be subroutines or sub-components of an application, cloud service, or any other computing platform. Generally, the ontology-derived classification component 302 receives queries from a decision support application 312 that hosts at least one procedurally-coded decision support workflow 314 (e.g., workflow 200 of FIG. 2) and at least one procedurally-coded script 318. The ontology-derived classification component 302 ingests data, generates entities, and infers about classifications based on ontological concepts and rules. Classification data for the entities (e.g., classes, superclasses, direct superclasses, and findings) are generated using the ontological concepts and rules. Thus, some aspects of the ontology-derived classification component 302 include an ingestion control unit 332, an ontology entity modification unit 334, an ontology entity generation unit 336, and an inference unit 338.

[0027] The capture control unit 332 generally identifies queries transmitted by the decision support application 312. The capture control unit 332 can identify the queries in any suitable manner. For example, in some embodiments, the capture control unit 332 can crawl the decision support application 312 continuously, periodically, or intermittently for documents containing data parsed from the record repository server 316. In other embodiments, the capture control unit 332 monitors data communicated from the decision support application 312, analyzes the data, and identifies data parsed from the record repository server 316. In some embodiments, the capture control unit 332 compares the identifiers included in the data with a set of identifiers stored in a lookup table to determine whether the entity corresponding to the identifier is new or has been previously processed in the knowledge base environment 340. When the capture control unit 332 detects that an entity containing an identifier does not exist in the knowledge base library, the capture control unit 332 activates an ontology entity generation unit, such as the ontology entity generation unit 336. Additionally or alternatively, when the capture control unit 332 detects an entity in the knowledge base library that includes an identifier in a field, the capture control unit 332 activates an ontology entity modification unit, such as the ontology entity modification unit 334.

[0028] The ontology entity change unit 334 generally accepts a formatted version of the values from the script and outputs machine-readable changes to the existing entities in the knowledge base library (e.g., knowledge base library 340). The changes can include adding values to data fields that were not previously populated, replacing values in data fields that were previously populated, deleting values in data fields that were previously populated, adding values to new instances of data fields that were previously populated, or any other computer-understandable data manipulation function. The values can be mapped to the data fields of the entity based on the data encoded by the script (e.g., script 318). The ontology entity change unit 334 comprises a module, a software application, or a set of applications (which may include programs, routines, functions, or computer-executable services) that is executed by a processor associated with the ontology-derived classification component 302.

[0029] The ontology entity generation unit 336 generally accepts a formatted version of the values from the script and outputs machine-readable entities into the knowledge base library (e.g., knowledge base library 340). The values can be mapped to the data fields of the entity based on the data encoded by the script (e.g., script 318). The ontology entity generation unit 336 comprises a module, a software application, or a set of applications (which may include programs, routines, functions, or computer-executable services) that is executed by a processor associated with the ontology-derived classification component 302.

[0030] The inference unit 338 generally infers the logical consequences of the asserted patient entities. The output of the inference unit 338 includes the inferred classification of each record (e.g., the asserted patient entity) stored in the record database (e.g., the record database 320) based on the knowledge base library. In other words, the inference unit 338 accepts rules, concepts, classes, and the relationships connecting each as true logical axioms. As will be discussed in more detail with reference to FIG. 4, the inference unit 338 evaluates the values of each entity in the knowledge base library (e.g., the knowledge base library 340) according to the rules and concepts, and infers to which class that entity belongs. For example, if the inference unit 338 infers that an entity includes a value belonging to an asserted class (e.g., class 404 in FIG. 4) based on the asserted axioms of the knowledge base library, the inference unit 338 assigns that record to the asserted class. Thus, the inference of the inference unit 338 about an entity can depend on the knowledge base library and the values included in the entity. As a result of the values in the entity being changed, the inference unit 338 may reclassify the entity. Similarly, as a result of a change in the concept, rule, or relationship of a class, or the addition of a class, the inference unit 338 may reclassify the entity. In other words, the classification of an entity dynamically depends on the values associated with that entity.

[0031] Furthermore, the inference unit 338 can infer findings of one or more values within each entity. This finding can be inferred by the inference unit 338 based on concepts, rules, and relationships asserted in the knowledge base library. For example, a value of a field corresponding to a body temperature higher than a predetermined threshold may have a finding of IncreasedTemperature. Similarly, a value below the predetermined threshold may have a finding of NormalTemperature. In some aspects, the inference unit 138 writes data to a database or file in response to a determination that the patient record belongs to a predetermined class. In some aspects, the specific database record or specific file to which the data is written varies based on the class to which the patient record is assigned. Exemplary inference units include Cyc, KAON2, Cwm, Drools (registered trademark), Flora-2, Jena, Prova.

[0032] In some embodiments, the ontology-derived classification component 302 is communicatively coupled to a knowledge base library 340. Generally, a knowledge base library stores a plurality of rules, concepts, relationships, and taxonomies that are asserted to be true. Additionally, the knowledge base library can hold one or more entities. In some embodiments, entities can be populated into the knowledge base library by the ontology-derived classification component 302, the script 318, or a combination of both. Entities included in the knowledge base library include a plurality of data fields that at least include identifiers corresponding to identifiers of database records held by a record database (e.g., record database 320). The values of the entities are asserted to be true. However, in at least one embodiment, the classes of the entities are not asserted to be true. Instead, the classes of the entities are inferred based on rules, concepts, relationships, and taxonomies that are asserted to be true in the knowledge base library 340. The knowledge base library can be held by one or more servers and one or more databases. As shown in FIG. 3, an exemplary knowledge base library 340 includes a data schema knowledge database 304 and a taxonomy knowledge database 306.

[0033] The data schema knowledge database 304 stores and maintains one or more data schema knowledge libraries. The data schema knowledge library comprises a computer - understandable model of all domain knowledge associated with the data schema. For example, the data schema knowledge library includes field nomenclature, field types, metadata, domain resources, field addresses, and other similar framework rules. Similarly, the taxonomy knowledge database 306 stores and maintains one or more taxonomy knowledge libraries. The taxonomy knowledge library comprises a computer - understandable model of all domain knowledge associated with the taxonomy. For example, in some embodiments, the taxonomy knowledge database 306 includes a SNOMED CT library.

[0034] Network 308 generally facilitates communication between the ontology-guided classification component 302, user device 310, record repository server 316, other devices or servers connected to network 308, or any combination thereof. Thus, network 308 can include an access point, router, switch, or other generally understood network component that provides wired or wireless network connectivity. In other words, network 308 can include multiple networks or a network of networks, but is shown in a simplified form so as not to obscure aspects of the present disclosure. By way of example, network 308 can include one or more wide area networks (WANs), one or more local area networks (LANs), one or more public networks such as the Internet, one or more private networks, one or more telecommunications networks, or any combination thereof. In other words, if network 308 includes a wireless telecommunications network, components such as base stations, communication towers, or even access points (and other components) can enable wireless connectivity. Network environments are commonplace in enterprise-scale computer networks, intranets, and the Internet. Thus, network 308 is not described in great detail herein.

[0035] System 300 includes user device 310. User device 310 generally facilitates interaction between the outputs of ontology-guided classification component 302 and decision support application 312 and the user (i.e., the user of the device). Further, user device 310 may facilitate access to record repository server 316. User device 310 may facilitate this interaction by executing an application stored on a computer-readable medium that enables user device 310 to communicatively couple with ontology-guided classification component 302, record repository server 316, or both. Alternatively, user device 310 may locally execute some or all of the components of ontology-guided classification component 302, although such a configuration is not shown in FIG. 3. The application may include operational modules that can utilize combinations of hardware, firmware, and computer-executable instructions. The application may include any number of other elements that facilitate communication with ontology-guided classification component 302, record repository server 316, or any combination thereof, such as protocols for account login, encryption, and decryption. For example, the application may be a locally-executed EHR client, cloud-based EHR client, EHR web portal, mobile EHR app, or any other suitable application. Exemplary examples of EHR client applications include, but are not limited to, Cerner® Millennium®, PowerChart®, and PowerTrials®. Some aspects of user device 310 include some or all of the components of computing device 500, which are discussed in relation to FIG. 5.

[0036] System 300 includes a decision support application 312 that facilitates the execution of a procedurally-coded workflow 314. The hosted workflow 314 can be in any format suitable for holding procedural code. In certain embodiments, each workflow, such as workflow 314, includes code corresponding to a diagnostic decision support tool. As shown in FIG. 2, an exemplary workflow can be programmatically coded to assist in the diagnosis and treatment of viral infections such as COVID-19. However, it will be understood that this is only an example of a procedurally-coded workflow. For example, the decision support application can assist in diagnosis, treatment, patient scheduling, or any combination thereof. In one embodiment, the execution of the decision support application based on classification data is to determine the effect of one or more drugs, determine the effect of one or more medical interventions, support the extubation of a patient, propose the extubation of a patient, support the adjustment of a patient's treatment, support the adjustment of a pharmaceutical, propose the adjustment of a patient's treatment, support the setting of a ventilator, propose the adjustment of the setting of a ventilator, remove a patient from ventilation, propose the removal of a patient from ventilation, evaluate the condition of a patient before surgery, evaluate the condition of a patient during surgery, evaluate the condition of a patient after surgery, evaluate the condition of a patient before a medical procedure, evaluate the condition of a patient during a medical procedure, evaluate the condition of a patient after a medical procedure, monitor for air leaks, monitor for improper ventilation, monitor movement, monitor stress levels, monitor medical conditions, or monitor diseases, and provide information related to one or more of these.

[0037] The decision support application 312 can also hold one or more scripts 318. The script 318 can include program code for extracting values stored in database fields of records held by a recording database (e.g., recording database 320). Further, the script 318 can extract the field address associated with each value extracted from the record. Further, the script 318 can include an expression that links the field address associated with the database to the corresponding field address of an entity within the knowledge base system library. The script 318 can further include an expression that converts the format of the extracted value to the native format of the corresponding field within the entity. For example, the script 318 can convert a value from a small integer field to a floating point number. As another example, the script can perform a conversion from a variable string to a fixed string, a conversion from a decimal to a floating point number, or any other format conversion. Further, the script 318 can include an expression that converts the value to the native unit of the corresponding field within the entity. For example, a value stored in a field having a field address identified as storing temperature in Celsius can be converted to Fahrenheit. As another example, a value stored in a field identified as storing a date of birth can be converted to an age in days, months, years, or any combination thereof. The script 318 can include computer-executable procedural code in any suitable format. For example, in some embodiments, the script 318 can include files in json, java (registered trademark), C++, C#, Python, R, PHP, Visual Basic.NET, JavaScript (registered trademark), Ruby, Perl, SIMSCRIPT, Object Pascal, Objective-C, Dart, Swift, Scala, Kotlin, Common Lisp, MATLAB (registered trademark), or Smalltalk.

[0038] System 300 also includes the recording repository server 316 described above. The recording repository server 316 generally facilitates the storage and retention of data. Generally, data can be stored via any suitable computer-readable medium that is communicatively accessible to the processing components of the recording repository server 316. For example, the data can be stored in a recording database 320 in which a data schema is defined. As will be understood by those skilled in the art, the data schema of a recording database (e.g., recording database 320) can vary widely. For example, the nomenclature, table structure, field structure, and database language (SQL, Oracle, SQL Server, MySQL®, etc.) preferred by the person constructing and managing the database directly and indirectly affect the overall data schema.

[0039] The record repository server 316 generally holds one or more record databases 320 that store and organize data records. The record repository server 316 can include hardware, software, and firmware that facilitate the creation, retrieval, and modification of data records stored in the record database 320. Each database 320 has a data schema. The data schema includes the relational associations, metadata, and configuration of each field and table of the database 320. In some aspects, the record repository server 316 constitutes an EHR system. The EHR system can further include one or more computers or servers that contain medical records that can be held in one or more databases and that facilitate the storage and retrieval of medical records associated with patients. Each medical record includes the personal medical or health data of a particular patient and any other data associated with the patient (e.g., unique identifiers, demographic data, appointment schedules, facility admission information, etc.). Examples of EHR systems include Cerner® Millennium®. In some aspects, the record repository server 316 also includes an interoperability interface, which is a computing interface that enables data transmission between the database 320 and another device (e.g., the user device 310, the ontology-guided classification component 302, the decision support application 312, or any other device). In particular, the interoperability interface can define how calls, codes, or requests are made in the data schema used by the record database 320 held by the record repository server 316.

[0040] It should be understood that the system 300 of FIG. 3 is a preferred example of the configuration of the components. In various aspects, other components may or may not be included, which are not shown. Further, each of the components may be implemented by a single device or by multiple devices, and thus the quantities shown in FIG. 3 are non-limiting examples.

[0041] In a conventional computerized system, a computer programmer would convert the diagnostic criteria included in the standard treatment, prediction model, or standard procedure into procedural code that identifies each iteration of the diagnostic criteria. As described above, even from relatively uncomplicated diagnostic criteria, the number of possible permutations can be quite large. For example, for a particular diagnostic criterion having only five selection criteria conditions where condition A has four available states, condition B has six available states, condition C has three available states, condition D has three available states, and condition E has four available states, there could be 864 available permutations (i.e., 4×6×3×3×4 = available permutations of available states). Further, in any of the permutations of the procedural code, if the position of even one of ",", ";", "(", or ")" is incorrect, it can result in a non-functional procedural code or a procedural code with inappropriate operation. Each permutation of the procedural code includes the state for each condition based on a unique criterion for diagnosis, and reusing or using for another purpose the procedural code created for one clinical trial along with the criteria of another clinical trial has not been an option conventionally.

[0042] In contrast, referring to FIG. 4 and continuing to refer to FIG. 3, by using a knowledge base library having an ontology hierarchy (e.g., ontology hierarchy 400) and the systems and methods described herein, the need for customized procedural code for querying a database of records so as to facilitate the workflow coded in procedural form held by a decision support application (e.g., decision support application 312) is significantly reduced or eliminated. FIG. 4 shows an exemplary ontology hierarchy 400 according to the aspects described herein. The exemplary ontology hierarchy 400 shown is a representative portion of a hierarchy that can be generated from a knowledge base library (e.g., knowledge base library 340) by an ontology-derived classification component (e.g., ontology-derived classification component 302 of FIG. 3).

[0043] Similar to ontologies in other fields of science and technology, an ontology hierarchy (e.g., ontology hierarchy 400) consists of a "tree", "backbone", or "hierarchy" that represents the relationships of concepts and rules 402 and classes 404. For example, the shown concept 406 includes a group of numerical concepts including the Temperature concept. Each concept 406 is linked to at least one rule 408 by a set of characteristics 410. The characteristics of a concept are the features of that concept. This feature can include logical features such as directed binary relationships, e.g., transitive relationships, symmetric relationships, inverse relationships, functional relationships, etc., that define rules that are true for instances of that concept. For example, in ontology hierarchy 400, the shown characteristic 410 specifies that the Temperature concept can have a response defined by a rule defined by the IncreasedTemperature rule or the NormalTemperature rule. Further, characteristics can include associations with interoperability data schemas. For example, in ontology hierarchy 400, the Temperature concept has a characteristic 410 that associates the Temperature concept with a specific FHIR (registered trademark) code (e.g., field address, 8310-5).

[0044] As described above, ontology hierarchy reference rules related to concepts and classes. Rule 308 defines a directed binary relationship, logical formula, or combination thereof that is asserted to be true for a certain entity. In other words, for each analyzed entity, an inferencer (e.g., inference unit 338) assumes that if the rule IncreasedTemperature is true when evaluated using the body temperature data (e.g., the value stored in the data field) included in the entity, the finding answer for the Temperature concept is IncreasedTemperature.

[0045] As described above, an ontology hierarchy reference class related to concepts and rules. A class is a logical axiom that describes an entity based only on the rules and concepts of the ontology hierarchy. The ontology hierarchy may include one or more asserted classes. Each class is defined by its relationship to applicable concepts. For example, ontology hierarchy 400 includes the two classes 404 shown (i.e., Covid-19_Diagnosis_Confirmed, and Covid-19_Lab_Result_Positive). For example, if an entity contains value data for which the logical axiom for its class is true, the inference unit infers that the entity is a member of the Covid-19_Diagnosis_Confirmed class. Although two classes are shown in FIG. 4, the ontology hierarchy may include multiple classes.

[0046] Continuing, FIG. 5 shows an exemplary method 500 for integrating classification data of a knowledge base of an entity (e.g., a patient record) according to the aspects described herein into a procedurally coded decision support workflow. For example, aspects of method 500 may facilitate a procedurally coded workflow (e.g., workflow 200 of FIG. 2) maintained by a decision support application (e.g., the decision support application of FIG. 3) based on classification data generated by inferences from an ontology-guided classification component (e.g., ontology-guided classification component 302 of FIG. 3) and a knowledge base library (e.g., knowledge base library 340 of FIG. 3). Aspects of method 500 may be implemented by a processor executing instructions stored on a computer-readable medium. The processor can execute the instructions using any combination of hardware, firmware, or software that the processor can directly or indirectly access. For example, some aspects of method 500 may be implemented by ontology-guided classification component 302 as described in connection with FIG. 3.

[0047] Generally, method 500 detects a trigger event (e.g., a change to a database record or the execution of a procedurally-coded decision support workflow). For a database record, a set of values, field addresses, and identifiers are extracted. The extracted data is populated into entities within a knowledge base library. The rules, concepts, and relationships of the knowledge base library are asserted by an inference engine to infer the classes of the entities. Based on the inferred classes, classification data for the entities and values within the entities are calculated. The classification data is returned to a procedurally-coded decision support workflow, and this workflow is executed based on the classification data.

[0048] Some aspects of method 500 begin at block 502. At block 502, a change to a field of a database record is detected via a set of code that is executed procedurally to monitor operations associated with a database that holds the database record. For example, in some aspects, a script (e.g., script 318 of FIG. 3) crawls or queries a record repository server (e.g., record repository server 316 of FIG. 3) for changes to a record database (e.g., record database 320 of FIG. 3). The crawl or query can be continuous, periodic, or intermittent. Additionally or alternatively, repository server 316 can push newly-changed records to a decision support application intake control unit.

[0049] Some aspects of method 500 alternatively begin with the detection of a trigger event. For example, a procedurally-coded workflow (e.g., the procedurally-coded workflow 318 of FIG. 3) can be executed continuously, periodically, intermittently, or on demand within a decision support application (e.g., the decision support application 312 of FIG. 3). The workflow can be executed, for example, by a command issued by a user device (e.g., the user device 310 of FIG. 3). For example, a user can access patient records stored in a record repository via interaction with an EHR application interface. In response, the EHR application interface can initiate one or more workflows via a command sent to the decision support application. Execution of the workflow can initiate one or more scripts that query the patient's database record.

[0050] In block 504, a plurality of values stored in a database field are extracted from a database record. The values at least include an identifier corresponding to the database record. Further, in some aspects, for each database field associated with each of the plurality of values, a field address is extracted. For example, a script (e.g., the script 318 of FIG. 3) is procedurally coded such that values and corresponding field addresses for one or more database records held by a database (e.g., the record database 320) are extracted.

[0051] In block 506, an entity is generated in the knowledge base library by executing a script that writes a formatted version of a plurality of values to a corresponding set of fields mapped to a plurality of database fields based on field addresses. Some aspects of block 506 can be facilitated by executable procedural code of a script (e.g., script 318 of FIG. 3), an import control unit (e.g., import control unit 332 of FIG. 3), an ontology entity generation unit (e.g., ontology entity generation unit 336 of FIG. 3), or any combination thereof. For example, in one particular aspect, the script includes a computer-readable map of field addresses from a record database (e.g., record database 320 of FIG. 3) to a corresponding set of field addresses in an entity in the knowledge base library. The script can communicate an identifier extracted from the record database to the import control unit. The import control unit can query the knowledge base library for one (or more) entities that include the identifier as a value within a data field. In response to a negative query result (i.e., the query does not return an entity), the import control unit activates an ontology entity generation unit (e.g., ontology entity generation unit 336 of FIG. 3). The entity can be generated by the ontology entity generation unit using values extracted by the script in data fields defined by mappings encoded in the script. Alternatively, some aspects of block 504 include modifying an existing entity in the knowledge base library in response to the detection of one (or more) entities that include an identifier extracted by the script. The import control unit can activate an ontology entity modification unit (e.g., ontology entity modification unit 334 of FIG. 3). The entity can be modified to include values extracted by the script in data fields defined by mappings encoded in the script.

[0052] In block 508, based on the inference of the inference unit and the knowledge base library including entities, the first class of the entity to which the entity belongs is calculated. The aspect of block 508 is facilitated by the inference unit (e.g., the inference unit 338 in FIG. 3) and the knowledge base library (the knowledge base library 340 in FIG. 3). For example, the inference unit can be activated to classify an entity based on the logical consequences of the data asserted in the entity. The output of the inference unit may include at least one inferred class of the entity stored in the knowledge base library. In other words, the inference unit accepts the rules, concepts, classes, and the relationships connecting each of them defined by the data schema knowledge and the taxonomy knowledge as logical axioms that are true. The inference unit evaluates each entity in the library according to the rules and concepts and infers to which class the entity belongs.

[0053] In block 510, in response to the determination of the inferred class, classification data about the entity is returned as an input to the procedurally defined workflow. The classification data may include the first class, one or more superclasses of the first class, one or more direct superclasses of the first class, one or more findings of the values within the entity, or any combination thereof. In some aspects, block 510 is facilitated by the inference unit (e.g., the inference unit 338 in FIG. 3) and the knowledge base library (the knowledge base library 340 in FIG. 3).

[0054] In block 512, based on the classification data, workflow actions defined procedurally within a workflow are executed. In some aspects, block 512 is facilitated by a decision support application (e.g., decision support application 312 of FIG. 3), a user device (e.g., user device 310 of FIG. 3), or a combination of both. Further, some aspects of block 512 restart one or more portions of method 500 when the execution of a procedurally defined workflow reaches a non-terminal point of the procedurally defined workflow. For example, as discussed in connection with FIGS. 1 and 2, during or after execution based on the classification data of a procedurally defined workflow, the decision support application can trigger a script to determine whether the workflow has reached a terminal point. If the terminal point is not reached, the decision support application can trigger a script to extract additional data from a database record. Additional data can be populated into the class of the entity corresponding to the database record, and the class of the entity can be re-inferred by an inference unit.

[0055] Advantageously, in contrast to a conventionally procedurally defined workflow, the class of an entity depends dynamically on the values associated with the entity. Thus, also in contrast to a conventionally procedurally defined workflow, the addition or manipulation of data within a record is not merely to advance the workflow to the next procedurally defined point. Rather, aspects of the hybridized systems and methods described herein can facilitate the adaptive execution of a procedurally defined workflow based on classification data dynamically inferred based on rules, classes, and relationships defined by a knowledge base library.

[0056] Embodiments of the present disclosure may be described in the context of computer code or machine-usable instructions, such as computer-usable instructions or computer-executable instructions including program modules, executed by a computer or other machine, such as a personal data assistant, smartphone, tablet PC, or other handheld device. Generally, program modules include routines, programs, objects, components, data structures, etc., and refer to code that performs a particular task or implements a particular abstract data type. Embodiments of the present disclosure can be implemented in a variety of system configurations, including mobile devices, consumer electronics, more specialized computing devices, etc. Embodiments of the present disclosure can also be implemented in a distributed computing environment where tasks are performed by remote processing devices linked via a communication network. In a distributed computing environment, program modules can be located in both local and remote computer storage media including memory storage devices.

[0057] Referring to FIG. 6, computing device 600 includes bus 610, which directly or indirectly couples the following devices: memory 612, one or more processors 614, one or more presentation components 616, one or more input / output (I / O) ports 618, one or more I / O components 620, and exemplary power supply 622. Bus 610 represents one or more buses (e.g., an address bus, a data bus, or a combination thereof). Although the various blocks in FIG. 6 are shown with lines for clarity, in reality these blocks represent logical components and not necessarily actual components. For example, a presentation component such as a display device can be considered an I / O component. Further, the processor has memory. The inventors recognize that this is characteristic of the art, and reiterate that the diagram of FIG. 6 shows only an exemplary computing device that can be used in connection with one or more embodiments of the present disclosure. No distinction is made between categories such as "workstation," "server," "laptop," "handheld device," etc., because all are contemplated within the scope of FIG. 6 as "computing devices."

[0058] Computing device 600 typically includes various computer-readable media. Computer-readable media can be any available media accessible by computing device 600 and includes both volatile and non-volatile media, removable and non-removable media. By way of example, computer-readable media includes, but is not limited to, computer storage media and communication media. Computer storage media is implemented in any method or technology for storing information such as computer-readable instructions, data structures, program modules, or other data, including both volatile and non-volatile, removable and non-removable media. Examples of computer storage media include RAM, ROM, EEPROM, flash memory, or other memory technologies, CD-ROM, digital versatile disk (DVD), or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage, or other magnetic storage devices, or any other media that can be used to store the desired information and is accessible by computing device 600, but is not limited to these. Computer storage media does not itself comprise a transitory signal. 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 includes any information delivery distribution media. The term "modulated data signal" means a signal in which one or more of its characteristics are set or changed in such a manner as to encode information in the signal. By way of example, communication media includes, but is not limited to, wired media such as a wired network or direct wired connection, and wireless media such as acoustic, RF, infrared, and other wireless media. Any combination of the above is also included within the scope of computer-readable media.

[0059] Memory 612 includes computer storage media in the form of volatile memory and / or non-volatile memory. The memory can be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid state memory, hard drives, optical disk drives, and the like. Computing device 600 includes one or more processors 614 that read data from various entities such as memory 612 or I / O component 620. Presentation component 616 presents data displays to a user or other device. Exemplary presentation components include display devices, speakers, printing components, vibration components, and the like.

[0060] The I / O port 618 enables the computing device 600 to be logically coupled to other devices including the I / O component 620, some of which may be embedded. Exemplary components include a microphone, a joystick, a game pad, a satellite antenna, a scanner, a printer, a wireless device, etc. The I / O component 620 may provide a natural user interface (NUI) that processes air gestures, voice, or other physiological inputs generated by the user. In some cases, the input may be sent to an appropriate network element for further processing. The NUI can implement any combination of voice recognition, touch and stylus recognition, face recognition, biometric recognition, on-screen and adjacent-to-screen gesture recognition, air gestures, head and eye tracking, and touch recognition associated with the display on the computing device 600. The computing device 600 may include a depth camera, such as a stereo camera system, an infrared camera system, an RGB camera system, and combinations thereof, for gesture detection and recognition. Additionally, the computing device 600 may include an accelerometer or gyroscope that enables motion detection. The output of the accelerometer or gyroscope may be provided to the display of the computing device 600 for rendering immersive augmented reality or virtual reality.

[0061] Some embodiments of computing device 600 may include one or more radios 624 (or similar wireless communication components). The radio 624 transmits and receives wireless communication or wireless signals. Computing device 600 may be a wireless terminal adapted to communicate and receive media via various wireless networks. Computing device 600 may communicate via wireless protocols such as Long Term Evolution (“LTE”), Code Division Multiple Access (“CDMA”), Global System for Mobile Communications (“GSM®”), or Time Division Multiple Access (“TDMA”), and others, to communicate with other devices. The wireless communication may be a short-range connection, a long-range connection, or a combination of both short-range and long-range wireless electrical communication connections. When referring to “short” and “long” types of connections, it is not intended to refer to the spatial relationship between two devices. Instead, generally, short-range and long-range are referred to as different categories or types of connections (i.e., primary and secondary connections). Examples of short-range connections include, but are not limited to, Wi-Fi® connections to devices that provide access to wireless communication networks such as WLAN connections using the 802.11 protocol (e.g., mobile hotspots). A Bluetooth® connection to another computing device is a second example of a short-range or near-field communication connection. Examples of long-range connections include, but are not limited to, connections using one or more of the CDMA, LTE, GPRS, GSM, TDMA, and 802.16 protocols.

[0062] The subject matter of the technology described in this specification is specifically recited to meet legal requirements. However, this description itself is not intended to limit the scope of the patent. Rather, the inventors envision that the claimed subject matter may also be embodied in other ways, including in combination with other current or future technologies, to include other steps or combinations of steps similar to those described in this document. Further, the terms "step" and / or "block" may be used in this specification to imply different elements of a method being employed, but these terms should not be construed as suggesting any particular order among or between two or more steps disclosed in this document, except where the order of individual steps is explicitly recited. Additionally, those skilled in the art will understand that the pseudocode included in this specification is exemplary in nature and should not be construed as suggesting any particular requirements, given the variations in programming languages.

Claims

1. A method comprising: detecting a change to a field of a database record via a set of code executed procedurally that monitors an operation associated with a database that holds the database record; wherein the database record is relationally linked in a relational type to a plurality of database fields including the field of the database record; the method further comprising: extracting, via the set of code executed procedurally, a plurality of values stored in the plurality of database fields and a field address for each of the plurality of values; wherein the plurality of values includes identifiers; the method further comprising: generating an entity in a knowledge base library by executing a script that writes a formatted version of the plurality of values to a corresponding set of fields mapped to the plurality of database fields based on the field addresses; calculating a first class of the entity as the class to which the identifier belongs based on an inference of an inference unit drawn from a knowledge base library that includes the generated entity; responding to the inferred first class, and further comprising returning classification data of the entity as an input to a workflow defined procedurally; wherein the classification data includes at least a finding of a value among the plurality of values within the entity and a superclass ontologically defined by the inference inference unit drawn from a knowledge base library that includes the generated entity; the method further comprising: executing a workflow action within the workflow defined procedurally based on the classification data. A method.

2. The method of claim 1, wherein the workflow action generates a prompt to prompt for input of additional data in response to reaching a non-terminal point in the workflow defined procedurally.

3. The method of claim 2, further comprising incorporating the second plurality of values into the entity in the knowledge base library in response to extracting the second plurality of values stored in a second plurality of database fields.

4. The method according to claim 1, wherein the database is a relational database held by an electronic medical record.

5. The method according to claim 1, wherein the code executed in the procedural form is compiled from at least one file including an object-oriented programming language.

6. The method according to claim 1, wherein the script is selected from a plurality of scripts based on a workflow defined in the procedural form.

7. The method according to claim 1, wherein the change of the field is triggered by the execution of another workflow defined in a procedural form within an application executed locally.

8. At least one processor; A non-transitory computer-readable medium storing instructions that, when executed by the at least one processor, cause the at least one processor to execute a method, the method comprising: Detecting a change in a field of a database record via a set of code executed in a procedural form that monitors operations associated with a database holding the database record, the database record being relationally linked to a plurality of database fields including the field of the database record; Extracting, via the set of code executed in the procedural form, a plurality of values stored in the plurality of database fields and a field address for each of the plurality of values, the plurality of values including identifiers; Generating an entity in a knowledge base library by executing a script that writes a formatted version of the plurality of values to a corresponding set of fields mapped to the plurality of database fields based on the field addresses; Calculating, based on an inference of an inference unit drawn from a knowledge base library including the generated entity, a first class of the entity as a class to which the identifier belongs; In response to the inferred first class, returning the classification data of the entity as an input to a procedurally defined workflow, the classification data including at least findings of certain values among the plurality of values within the entity, and a superclass ontologically defined by the inference inference unit derived from a knowledge base library including the generated entity. A system including executing a workflow action within the procedurally defined workflow based on the classification data. **Claim 9** The system according to claim 8, wherein the workflow action generates a prompt to prompt for input of additional data in response to reaching a non-terminal point in the procedurally defined workflow. **Claim 10** The system according to claim 9, further including incorporating the second plurality of values into the entity in the knowledge base library in response to extracting the second plurality of values stored in a second plurality of database fields. **Claim 11** The system according to claim 8, wherein the database is a relational database held by an electronic medical record. **Claim 12** The system according to claim 8, wherein the code executed in the procedural manner is compiled from at least one file including an object-oriented programming language. **Claim 13** The system according to claim 8, wherein the script is selected from a plurality of scripts based on the procedurally defined workflow. **Claim 14** The system according to claim 8, wherein the change of the field is triggered by execution of another workflow defined in a procedural manner within an application executed locally. **Claim 15** A non-transitory computer-readable medium storing instructions that, when executed by at least one processor, cause the at least one processor to execute a method, the method including: detecting a change in a field of a database record through a set of code executed in a procedural manner that monitors an operation associated with a database holding the database record, the database record being relationally linked to a plurality of database fields including the field of the database record. extracting, via a set of code executed procedurally, a plurality of values stored in the plurality of database fields and a field address for each of the plurality of values, the plurality of values including identifiers, generating an entity in a knowledge base library by executing a script that writes a formatted version of the plurality of values to a corresponding set of fields mapped to the plurality of database fields based on the field addresses, calculating, based on an inference of an inference unit drawn from a knowledge base library including the generated entity, a first class of the entity as the class to which the identifier belongs, responding to the inferred first class, returning classification data of the entity as an input to a workflow defined procedurally, the classification data including at least findings of a certain value among the plurality of values in the entity and a superclass ontologically defined by the inference inference unit drawn from a knowledge base library including the generated entity, a non-transitory computer-readable medium including executing a workflow action in the workflow defined procedurally based on the classification data.

16. The computer-readable medium according to claim 15, wherein the workflow action generates a prompt for input of additional data in response to reaching a non-terminal point in the workflow defined procedurally.

17. The computer-readable medium according to claim 16, further including incorporating the second plurality of values into the entity in the knowledge base library in response to extracting the second plurality of values stored in a second plurality of database fields.

18. The computer-readable medium according to claim 15, wherein the database is a relational database held by an electronic medical record.

19. The computer-readable medium according to claim 15, wherein the code executed procedurally is compiled from at least one file including an object-oriented programming language.

20. The computer-readable medium according to claim 15, wherein the change to the field is triggered by the execution of another workflow defined procedurally within an application that is executed locally.

Images