System and method for ontological classification of records

Abstract

Systems and methods for process-based decision support using ontology-based classification of database records are described. Process-based decision support can facilitate the extraction of contextually relevant data from a database. One or more scripts can be used to format the data to be compatible with a knowledge-based database and populate it as an entity into the library. Classification of the entity can use available data to infer. One or more classifications of the entity can be returned to the process-based decision support to facilitate the computation of recommendations.

Description

TECHNICAL FIELD

[0001] Aspects herein relate to devices, systems, and methods of classifying records based on asserted ontological axioms. BACKGROUND

[0002] Traditional electronic health records (EHRs) typically use relational databases to organize and store patient records. These databases use structured and unstructured fields to hold values (e.g., numeric, descriptive, or illustrative) in any number of tables and nested tables. While relational databases facilitate the storage of large amounts of data, complex queries traditionally require each iteration of the query to be written in procedural code. For example, decision support applications (e.g., patient care workflow automation applications) traditionally use computational algorithms based on complex query patterns to operate. SUMMARY

[0003] To enable traditional computerized systems to aggregate and evaluate complex query requests (e.g., queries that include a combination of multiple inclusion criteria, exclusion criteria, or both), each iteration of the query is expressed in procedural code. The systems, methods, and devices described herein present a paradigm shift from these traditional process-based constraints. In contrast to traditional systems, those described herein facilitate hybrid program-based and ontology-based data evaluation. Among other advantages, the systems, methods, and devices described herein can, among other advantages, detect a triggering event (such as a modification to a field of a database record) via a set of procedurally executed code that monitors operations associated with a database that maintains the database record. The database record can be linked in relation to a plurality of database fields, including the field of the database record. A plurality of values stored in the plurality of database fields and a field address of each of the plurality of values can be extracted from the database record by a procedurally executed code portion (e.g., an object-oriented script). In some aspects, an identifier linking the database field to the database record can be extracted. Based on the extracted values, an entity is generated in a knowledge-based library by executing a script that writes a formatted version of the plurality of values to a corresponding field set mapped to the plurality of database fields based on the field address. A class of the entity is computed based on inferences of an inferrer extracted from the knowledge-based library including the generated entity. In response to the computation of the entity class, classification data for the entity is returned as input to a procedurally defined workflow. The classification data can include at least a discovery of a value of the plurality of values within the entity and a superclass defined by inferences of the inferrer extracted from the knowledge-based library including the generated entity. A workflow action can be executed in the procedurally defined workflow based on the classification data. BRIEF DESCRIPTION OF DRAWINGS

[0004] The application is described in detail below with reference to the attached drawing figures, wherein:

[0005] Figure 1 An example process flow depicting a computerized system including hybrid process and ontology-based data evaluation according to aspects herein is depicted;

[0006] Figure 2 An example depiction of a process-defined workflow according to aspects herein is depicted;

[0007] Figure 3 An example computing environment according to aspects herein is depicted;

[0008] Figure 4 An example ontology hierarchy according to aspects herein is depicted;

[0009] Figure 5 An example method of hybrid process and ontology-based data evaluation according to aspects herein is depicted; and

[0010] Figure 6 An example computing device according to aspects herein is depicted. DETAILED DESCRIPTION

[0011] To have a traditional computer system understand and aggregate information stored in electronic records, the traditional computer system applies rules to evaluate selected records. Separate rules are used to evaluate each possible combination of variables and values for each variable that can exist in a record. Thus, separate rules are developed to address each different combination of variable(s) and / or different value(s) for each variable. For example, to evaluate a record having one condition (e.g., variable) with multiple available states (e.g., values), a rule is developed for each different permutation of combinations that can exist in the record. As the amount of information stored in electronic records increases, the number and complexity of rules used also increases. To this end, traditional computerized systems require a large number of rules.

[0012] To illustrate, to have a traditional computerized system aggregate and evaluate whether any of the plurality of records stored in a relational database support progression from a first point to a second point in a decision support workflow, rules can be needed to evaluate every combination of individual variable(s) and / or value(s). Generally, a decision point is a step in a process programming in a workflow where a set of rules define progression along one of at least two potential paths. The paths can be simple (e.g., a closed loop or a program equivalent of waiting until a rule for the decision point is satisfied) or complex. In a traditional workflow, the two paths can include algorithmic evaluation of data held in a database. As a simplified example, a traditional decision point can include an if / else program expression. When the condition of the if expression is satisfied, the workflow can proceed along a path defined by the workflow. Otherwise, the workflow can proceed along a path defined by the else expression of the workflow.

[0013] Even if a particular decision point has only five 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, a traditional computerized system can need to access and evaluate each of the 864 available combinations by using 864 different rules. For example, a traditional patient care workflow for automated diagnosis of viral infection can include process rules for each combination of laboratory values (e.g., oxygen saturation, cell count, antibody count, PCR results, etc.) and physical manifestations (e.g., body temperature, inflammation, cough, etc.) that are defined as necessary to verify viral infection. Furthermore, rules can be needed for each combination of types of values that can be stored in a record. Also, traditional process code can include rules that point to each combination of fields potentially used in a relational database. For example, a temperature value can be stored in different locations within a database based on the source of the temperature (e.g., oral, temporal, rectal, etc.), the units used to record the temperature (e.g., Celsius or Fahrenheit).

[0014] Additionally, differences between the structure of any two relational databases can hinder interoperability of process code because the organization of a particular field in the structure of each relational database can be different. In other words, the rules of these process codes can be such that only evaluation of a single relational database structure is enabled, so a traditional computerized system cannot reuse the rules of process code for any relational database that does not follow one particular structure.

[0015] Accordingly, the rules database occupies a large amount of computer-readable memory to store the supporting rules for record evaluation involving hundreds or thousands of conditions. Moreover, conventional computerized systems utilize a large amount of processing resources to execute the rules against records involving hundreds or thousands of conditions. Additionally, each time a change is made to one of the conditions or an available state of a condition (e.g., adding a new condition, removing a condition, adding a new state to a condition, or removing a state of a condition), the procedural code of the corresponding rules is modified to keep the rules database up-to-date.

[0016] The aspects described herein represent a paradigm shift away from procedural rule dependency. More specifically, the aspects described herein can facilitate a hybrid of procedurally executed decision support and ontology-based categorical reasoning. In particular, the aspects described herein provide methods, systems, and media to facilitate automatic ingestion of variable(s) and / or value(s) related to one or more decision support workflows by a knowledge-based library. In some aspects, one or more scripts facilitate the automatic ingestion of the variable(s) and / or value(s). For example, a script can be executed that maps a location (e.g., a field address) of a database field of variable(s) and / or value(s) of a decision support workflow call to a corresponding set of fields of an entity in the knowledge-based library. A reasoner can categorize the variable(s) and / or value(s) based on asserted relationships within the knowledge-based library and can return the categorical data to facilitate a computation defined by the one or more decision support workflows. The categorical data can be a class, a direct superclass, or an indirect superclass to which a generated entity belongs.

[0017] Turning to Figure 1 According to aspects described herein, the example process flow 100 includes a procedural decision support workflow hybridized with a knowledge-based categorical system. The decision support workflow can be a diagnostic support workflow, an appointment scheduling support workflow, a billing support workflow, or any other workflow that includes a procedural programmed algorithm that includes an activation trigger (e.g., an action that initiates the workflow that is programmatically detected) and at least one decision point (e.g., a procedural programmed algorithm that evaluates data). Generally speaking, the process flow 100 facilitates progression from a first point to a second point in the decision support workflow. In some aspects, the first point can be an activation trigger of the workflow and the second point can be a terminal or non-terminal decision point in the workflow.

[0018] Some embodiments of the process flow 100 can begin with the activation of a decision support process 102. The activation of the decision support process 102 can be triggered by any programmatically detected action that initiates a decision support workflow based on a workflow supported process. For example, in some aspects, the activation of a decision support workflow can be triggered automatically in response to the programmatic detection of a modification to a database record. The modification to the database record can include the addition of data to one or more fields of a database that maintains the database record. For example, and with brief reference to Figure 3 , the activation of the decision support process can be triggered by the decision support application 312 that is monitoring the operation of the record database 320 maintained by the record repository server 316. The activation of the decision support process workflow 102 can also be triggered in response to the periodic, continuous, intermittent, or on-demand execution of the decision support workflow. For example, and with brief reference to Figure 3 , the activation of the decision support process can be triggered by the periodic, continuous, intermittent, or on-demand execution of the workflow 314 maintained by the decision support application 312.

[0019] In some embodiments of the process flow 100, data from the database record is resolved based on the activated decision support workflow at block 104. The data can be resolved from the database 128 using any suitable means. For example, in particular aspects, a script is programmatically encoded to extract values stored in database fields associated with a first decision point of the activated decision support workflow. In some embodiments, one of the extracted values corresponds to an identifier of the database record. The identifier can be an alphanumeric value associated with each field 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. Additionally, a field address corresponding to each database field that holds the extracted values can be extracted at block 104. The field address can be a value that uniquely identifies the identity or location of a field in the database. A database record in the database can include multiple values in a field associated with a particular field address (e.g., multiple fields having a field address that identifies a field holding a temperature in Celsius).

[0020] The example process flow 100 includes mapping the extracted data to an entity within the knowledge-based system at block 106. In some aspects, the extracted data is mapped by executing a script within the decision support application (e.g., the decision support application 312 of Figure 3 ). The script can include a programmatic expression that writes a formatted version of the field value to a corresponding field in the entity of the knowledge-based system, which can additionally or alternatively communicate the formatted version of the field value to an ontology-guided classification component (e.g., the ontology-guided classification component 318 of Figure 3ontology-guided classification component 302). For example, the script can determine the identity of each value extracted from the database based on the field address. In addition, the script can include expressions that link the field addresses associated with the database to field addresses of entities in the knowledge-based system library. The script can also include expressions that convert the format of the extracted values to the native format of the corresponding field within the entity. For example, the script can convert values from small integer fields to floating point numbers. As another example, the script can convert variable strings to fixed strings, decimal to floating point, or any other format conversion. In addition, the script can also include expressions that convert the values to the native units of the corresponding field within the entity. For example, a value held in a field identified as holding temperatures in Celsius can be converted to temperatures in Fahrenheit. As another example, a value held in a field identified as holding a birth date can be converted to an age in days, months, years, or any combination thereof.

[0021] In some aspects of the process flow 100, block 106 includes creating an entity within the knowledge-based system. For example, the script can include a programmatic expression that queries the knowledge-based system for an entity corresponding to the identifier extracted from the database in block 104. When the knowledge-based system includes an entity corresponding to the identifier, the script can modify the entity within the knowledge-based system with the other data extracted from the database 128. By contrast, when the knowledge-based system does not include an entity corresponding to the identifier, the script can automatically perform an operation to create a new entity within the knowledge-based system. In one aspect, the newly created entity is populated with at least one field that includes the identifier extracted from the database 128. Similarly, the script can facilitate the creation of the entity by passing the extracted data to an ontology-guided classification component (e.g., the ontology-guided classification component 302) of the knowledge-based system. Figure 3

[0022] Some aspects of the process flow 100 include initiating ontology-guided classification of the entity generated or modified at block 106 within the knowledge-based system at block 130. For example, the reasoner 108 can be activated to classify the entity based on logical consequences of the data asserted in the entity. As Figure 1 depicted in FIG. 1, the output of the reasoner 108 includes classification data 110. The classification data 110 includes at least one inferred classification of the entity stored in the knowledge-based library. In other words, and briefly turning to FIG. 2, the classification data 110 includes the classification data 210. Figure 3 ​The reasoner 108 accepts as true logical axioms rules, concepts, classes, and relationships connecting each of them defined by the data pattern knowledge 304 and taxonomy knowledge 306. The reasoner 108 evaluates each entity in the repository according to the rules and concepts and infers which class 114 the entity belongs to. For example, when the reasoner 108 infers that an entity contains data belonging to an unconfirmed diagnosis class based on the asserted axioms, the reasoner 108 assigns the entity to the unconfirmed diagnosis class in the knowledge-based repository. Similarly, the reasoner 108 assigns fields of the entity to discovery classes 112 based on the asserted axioms in some aspects. For example, a temperature field with a value of 98.6 can be classified as belonging to a "normal temperature" discovery class. In contrast, a temperature field with a value of 102.7 can be classified as belonging to an "increased temperature" discovery class. In other words, the reasoner 108 can classify entities and constituent fields of entities based on the asserted axioms.

[0023] The reasoner 108 can output additional classification data in some aspects. For example, the reasoner 108 can identify at least one super class 116 or direct super class of an entity or at least one field based on the asserted axioms. A super class refers to any class that includes the inferred class in an ontology hierarchy. A direct super class refers to any class that is immediately above the inferred class in the ontology hierarchy.

[0024] Further, the reasoner 108 can write data to a database or file. In some aspects, the reasoner 108 writes data to the database or file in response to the classification of an entity. For example, the reasoner 108 can output a class to which an entity belongs, a super class to which an entity belongs, a direct super class to which an entity belongs, a class to which a field of an entity belongs, a super class to which a field of an entity belongs, a direct super class to which a field of an entity belongs, or any combination thereof.

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

[0026] Some aspects of the process flow 100 include executing a decision support process workflow algorithm based on the classification data at block 120. In some aspects, the decision support process workflow can progress to a first decision point in the workflow based on the classification data. For example, and with reference to Figure 2According to aspects described herein, an example decision support process workflow 200 is provided that includes decision points. As depicted, the decision support process workflow 200 can facilitate a diagnostic response to Covid-19. The example decision support process workflow 200 includes a triggering event at block 202, decision points 206 and 214, and termination points 208, 210, 212, 216, 218, 220, 222, 224, and 226. The triggering event at block 202 activates a knowledge-based classification of a patient based on data saved in an electronic health record (EHR) corresponding to the patient. The classification data is returned to the decision support process workflow algorithm and analyzed at block 204. In response, the example decision support process workflow 200 proceeds to decision point 206.

[0027] At decision point 206, the classification data is analyzed based on a programmatically expressed algorithm associated with decision point 206. As illustratively depicted in Figure 2 decision point 206 includes four possible paths. Decision point 206 can evaluate a patient as Covid-19 diagnosis confirmed, Covid-19 lab result positive, Covid-19 lab result negative, or no Covid-19 diagnosis or lab result. When the analysis of the classification data corresponding to the patient entity satisfies at least one rule of decision point 206, the example decision support process workflow 200 can proceed to the next procedural processing of the workflow. For example, a patient evaluated as Covid-19 diagnosis confirmed, Covid-19 lab result positive, or Covid-19 lab result negative by decision point 206 progresses to termination point 208, 210, or 212, respectively. In contrast, a patient evaluated as no Covid-19 diagnosis or lab result by decision point 206 progresses to decision point 214.

[0028] Returning to Figure 1 and with continued reference to Figure 2 Some embodiments of process 100 include determining whether a termination point is reached in a decision support process workflow at block 122. For example, the script can determine whether the decision support process workflow 200 progresses to termination point 208, 210, 212, 216, 218, 220, 222, or 224 based on the classification data. When the decision support process workflow progresses to a termination point, process 100 executes the operation encoded at the termination point by the decision support process workflow at block 126. For example, the decision support process workflow can modify a record of the patient (e.g., a database record), refer the patient to a care provider, order a clinical intervention, or trigger an alert script when a portion of the database record is viewed via an application. Further, the decision support process workflow can automatically initiate a different workflow or generate and transmit a request for information, among other things.

[0029] Alternatively, when the decision support process workflow progresses to a decision point (e.g., decision point 214) or any other non-terminal point in the workflow, the process flow 100 proceeds to block 124. At block 124, the process flow 100 determines whether the workflow reached the same point in the database record based on the same data parsed from the database record. For example, the script can evaluate the log file to determine whether the decision support process workflow 200 has previously progressed to decision points 206 or 214 and failed to continue. Additionally, the 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) since the decision support process workflow 200 progressed to decision points 206 or 214 and failed to continue. In response to determining that new data was added or the workflow has not progressed to the same point, block 124 can return to block 104. Alternatively, in response to determining that no new data was added and the workflow has progressed to the same point, block 124 can progress to block 126.

[0030] Turning to Figure 3 , an example system 300 is described that includes procedural decision support hybridized with knowledge-based classification systems in accordance with aspects described herein. Generally, the system 300 uses classification data output from an ontology-guided processing environment 340 to facilitate execution of procedurally encoded decision support workflows (e.g., the workflow 200 of Figure 2 ). Some aspects of the system 300 include an ontology-guided classification component 302, a network 308, at least one user device 310, a decision support application 312, and a record repository server 316.

[0031] The ontology-guided classification component 302 can include hardware, software, firmware, or any combination thereof. Further, some aspects of the ontology-guided classification component 302 can be a subroutine or subcomponent of an application, cloud service, or any other computing platform. Generally, the ontology-guided classification component 302 receives queries from the decision support application 312, which hosts at least one procedurally encoded decision support workflow 314 (e.g., the workflow 200 of Figure 2 ) and at least one procedurally encoded script 318. The ontology-guided classification component 302 ingests data, generates entities, and infers classifications based on ontology concepts and rules. The ontology concepts and rules are used to generate classification data (e.g., class, superclass, direct superclass, and discovery) for the entities. Accordingly, some aspects of the ontology-guided classification component 302 include an ingestion controller 332, an ontology entity modifier 334, an ontology entity generator 336, and an inferrer 338.

[0032] The ingestion controller 332 generally identifies queries submitted by the decision support application 312. The ingestion controller 332 can identify queries in any suitable manner. For example, in some aspects, the ingestion controller 332 can continuously, periodically, or intermittently scrape the decision support application 312 for documents containing data resolved from the record repository server 316. In other aspects, the ingestion controller 332 monitors data transmitted from the decision support application 312 and analyzes the data to identify data resolved from the record repository server 316. In some aspects, the ingestion controller 332 compares an identifier included in the data to 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-based environment 340. When the ingestion controller 332 detects that the entity containing the identifier does not exist in the knowledge base, the ingestion controller 332 activates an ontology entity generator, such as the ontology entity generator 336. Additionally, or alternatively, when the ingestion controller 332 detects that the entity including the identifier in the field exists in the knowledge-based library, the ingestion controller 332 activates an ontology entity modifier, such as the ontology entity modifier 334.

[0033] The ontology entity modifier 334 generally accepts a formatted version of values from a script and outputs a machine-readable modification to a pre-existing entity within a knowledge-based library (e.g., the knowledge-based library 340). The modification can include adding a value to a data field that was not previously populated, replacing a value in a data field that was previously populated, removing a value in a data field that was previously populated, adding a value to a new instance of a data field that was previously populated, or any other computer-understandable data manipulation function. The values can be mapped to data fields of the entity based on data encoded by a script (e.g., the script 318). The ontology entity modifier 334 includes a module, software application, or set of applications (which can include programs, routines, functions, or computer-executed services) within a software application executed by a processor associated with the ontology-guided classification component 302.

[0034] The ontology entity generator 336 generally accepts a formatted version of values from a script and outputs a machine-readable entity within a knowledge-based library (e.g., the knowledge-based library 340). The values can be mapped to data fields of the entity based on data encoded by a script (e.g., the script 318). The ontology entity generator 336 includes a module, software application, or set of applications (which can include programs, routines, functions, or computer-executed services) within a software application executed by a processor associated with the ontology-guided classification component 302.

[0035] Inferencer 338 generally infers logical conclusions about asserted patient entities. The output of inferencer 338 includes a knowledge-based classification of each record (e.g., the asserted patient entity) stored in a record database (e.g., record database 320). In other words, inferencer 338 accepts rules, concepts, classes, and the relations connecting each of them as true logical axioms. (See reference...) Figure 4 As discussed in more detail, inferencer 338 evaluates the value of each entity in a knowledge-based library (e.g., knowledge-based library 340) according to rules and concepts, and infers which class the entity belongs to. For example, when inferencer 338 infers, based on the asserted axioms of the knowledge-based library, that an entity contains elements belonging to the asserted class (e.g., ...), Figure 4 When the value of a record (class 404) is obtained, the inferencer 338 assigns the record to the asserted class. Therefore, the inferencer 338's inferences about entities can rely on a knowledge-based library and the values ​​included in the entity. Modifications to values ​​within an entity can cause the inferencer 338 to reclassify the entity. Similarly, modifications to class concepts, rules, or relations, or the addition of a class, can cause the inferencer 338 to reclassify the entity. In other words, the classification of an entity dynamically depends on the values ​​associated with the entity.

[0036] Furthermore, inferencer 338 can infer the discovery of one or more values ​​within each entity. Inferencer 338 can infer discoveries based on concepts, rules, and relationships asserted in a knowledge-based library. For example, a value greater than a predetermined threshold in a field corresponding to temperature can have the discovery of "IncreasedTemperature". Similarly, a value less than or equal to a predetermined threshold can have the discovery of "NormalTemperature". In some aspects, inferencer 138 writes data to a database or file in response to determining that a patient record belongs to a predetermined class. In some aspects, the specific database record or specific file to which data is written varies depending on the class to which the patient record is assigned. Example inferencers include Cyc, KAON2, Cwm, etc. Flora-2, Jena, Prova.

[0037] In some aspects, the ontology-guided classification component 302 is communicably coupled to a knowledge-based library 340. Generally, the knowledge-based library maintains a plurality of rules, concepts, relationships, and taxonomies asserted to be true. Additionally, the knowledge-based library can maintain one or more entities. In some aspects, the entities can be populated into the knowledge-based library by the ontology-guided classification component 302, the script 318, or a combination of both. The entities included in the knowledge-based library include a plurality of data fields including an identifier corresponding to at least an identifier of a database record maintained by a records database (e.g., the records database 320). The values of the entities are asserted to be true. However, in at least one aspect, the class of the entity is not asserted to be true. Rather, the class of the entity is inferred based on the rules, concepts, relationships, and taxonomies asserted to be true in the knowledge-based library 340. The knowledge-based library can be maintained by one or more servers and one or more databases. As Figure 3 depicted in FIG. 3, the example knowledge-based library 340 includes a data schema knowledge database 304 and a taxonomy knowledge database 306.

[0038] The data schema knowledge database 304 stores and maintains one or more data schema knowledge bases. The data schema knowledge base includes a computer understandable model of all domain knowledge associated with a data schema. For example, the data schema knowledge base 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 bases. The taxonomy knowledge base includes a computer understandable model of all domain knowledge associated with a taxonomy. For example, in some aspects, the taxonomy knowledge database 306 includes a SNOMED CT library.

[0039] The network 308 generally facilitates communication between the ontology-guided classification component 302, the user device 310, the records repository server 316, other devices or servers connected to the network 308, or any combination thereof. Thus, the network 308 can include access points, routers, switches, or other generally understood network components that provide wired or wireless network connectivity. In other words, the network 308 can include a plurality of networks or networks of networks, but is depicted in simple form to avoid obscuring aspects of the disclosure. By way of example, the 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 telecommunication networks, or any combination thereof. In other words, when the network 308 includes a wireless telecommunication network, components such as base stations, communication towers, or even access points (among other components) can provide wireless connectivity. Networking environments are commonplace in enterprise-wide computer networks, intranets, and the Internet. As such, the network 308 is not described in detail herein.

[0040] The system 300 includes a user device 310. The user device 310 generally facilitates interaction of a user (i.e., a user of the device) with the output of the ontology-guided classification component 302 and the decision support application 312. In addition, the user device 310 can facilitate access to the record repository server 316. The user device 310 can facilitate such interaction by executing an application stored in a computer-readable medium that allows the user device 310 to be communicatively coupled with the ontology-guided classification component 302, the record repository server 316, or both. Alternatively, the user device 310 can locally execute some or all components of the ontology-guided classification component 302, although Figure 3 Such a configuration is not shown in FIG. 3. The application can include operational modules that can utilize a combination of hardware, firmware, and computer-executable instructions. The application can include any number of other elements that facilitate communication with the ontology-guided classification component 302, the record repository server 316, or any combination thereof, such as account login, encryption and decryption protocols, etc. For example, the application can be a locally executed EHR client, a cloud-based EHR client, a HER web portal, a mobile EHR application, or any other suitable application. Illustrative examples of EHR client applications include, but are not limited to and Some aspects of the user device 310 include contact Figure 5 Some or all components of the computing device 500 discussed.

[0041] The system 300 includes a decision support application 312 that facilitates execution of the procedural coded workflows 314. The hosted workflows 314 can be in any format suitable for storing procedural code. In particular aspects, each workflow, such as the workflow 314, contains code corresponding to a diagnostic decision support tool. As Figure 2As depicted in the middle, the example workflow can be programmatically coded to assist in the diagnosis and treatment of a viral infection, such as COVID-19. However, it will be appreciated that this is merely an example of a procedurally coded workflow. For example, the decision support application can assist in the diagnosis, treatment, scheduling, or any combination thereof, of a patient. In an aspect, executing the decision support application based on the classification data provides information related to one or more of the following: determining an effect of one or more medications, determining an effect of one or more medical interventions, supporting extubation of a patient, recommending extubation of a patient, supporting adjustment of a patient therapy, supporting adjustment of a medication, recommending adjustment of a patient therapy, supporting ventilator settings, recommending adjustment of ventilator settings, weaning a patient off ventilation, recommending weaning a patient off ventilation, assessing a patient state pre-surgery, assessing a patient state during surgery, assessing a patient state post-surgery, assessing a patient state pre-medical procedure, assessing a patient state during a medical procedure, assessing a patient state post-medical procedure, monitoring for air leaks, monitoring for inadequate ventilation, monitoring for exercise, monitoring for stress levels, monitoring for medical conditions, or monitoring for disease.

[0042] The decision support application 312 can also maintain one or more scripts 318. The scripts 318 can include programmatic code to extract values stored in database fields of records maintained by a records database (e.g., records database 320). In addition, the script(s) 318 can extract the field address associated with each value extracted from a record. Further, the script(s) 318 can include expressions that link the field addresses associated with the database to corresponding field addresses of entities in the knowledge-based system library. The script(s) 318 can also include expressions that convert the format of the extracted values to the native format of the corresponding field within the entity. For example, the script(s) 318 can convert values from small integer fields to floating point numbers. As another example, the script can convert variable strings to fixed strings, decimal to floating point, or any other format conversion. In addition, the script(s) 318 can include expressions that convert values to the native units of the corresponding field within the entity. For example, a field address identified as holding values in a field that holds temperatures in Celsius can be converted to temperatures in Fahrenheit. As another example, a field address identified as holding values in a field that holds birth dates can be converted to age in units of days, months, years, or any combination thereof. The script(s) 318 can include computer executable procedural code in any suitable format. For example, in some aspects, the script(s) 318 can include json, java, C++, C#, Python, R, PHP, Visual Basic.NET, JavaScript, Ruby, Perl, SIMSCRIPT, Object Pascal, Objective-C, Dart, Swift, Scala, Kotlin, Common Lisp, MATLAB, or Smalltalk files.

[0043] The system 300 also includes the records repository server 316 mentioned above. The records repository server 316 generally facilitates the storage and maintenance of data. Generally, data can be stored via any suitable computer readable medium that is communicatively accessible by the processing components of the records repository server 316. For example, data can be stored in a records database 320 having an intended data schema. As will be appreciated by those skilled in the art, the data schema of a records database (e.g., records database 320) can vary greatly. For example, the naming conventions, table structures, field structures, and database languages (e.g., SQL, Oracle, SQL Server, MySQL, etc.) favored by the personnel constructing and managing the database directly and indirectly affect the overall data schema.

[0044] The record repository server 316 generally maintains one or more record databases 320 for storing and organizing data records. The record repository server 316 can include hardware, software, firmware that facilitate the creation, retrieval, and modification of data records stored in the record databases 320. Each database 320 has a data schema. The data schema includes relational associations, metadata, and configurations of each field and table of the database 320. In some aspects, the record repository server 316 includes an EHR system. The EHR system includes medical records, which can be maintained in one or more databases, and can also include one or more computers or servers that facilitate the storage and retrieval of medical records associated with a patient. Each medical record contains personal medical or health data of a particular patient and any other data associated with the patient (e.g., unique identifier, demographic data, appointments, nursing home admission information, etc.). Examples of EHR systems include In some aspects, the record repository server 316 also includes an interoperability interface that is a computing interface that enables data transfer between the databases 320 and another device (e.g., the user device 310, the ontology-guided categorization component 302, the decision support application 312, or any other device). In particular, the interoperability interface can define how to make calls, encode, or request in the data schema used by the record databases 320 maintained by the record repository server 316.

[0045] It should be understood that Figure 3 The system 300 of FIG. 3 is one suitable example of an arrangement of components. In various aspects, other components not shown can be included or omitted. Further, each component can be implemented via a single device or a plurality of devices, such that Figure 3 The number shown in FIG. 3 is a non-limiting example.

[0046] In traditional computerized systems, computer programmers translate diagnostic criteria included in care guidelines, predictive models, or standard procedures into procedural codes that identify each iteration of the diagnostic criteria. As mentioned above, even relatively simple diagnostic criteria can lead to a large number of possible permutations. For example, a specific diagnostic criterion with only five incorporating 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) can have 864 available permutations (i.e., 4 x 6 x 3 x 3 x 4 = available permutations of available states). Moreover, a single misplaced comma, semicolon, (), or parenthesis in any procedural code permutation can render the procedural code inoperable or cause it to malfunction. Because each procedural code permutation includes states for each condition based on the unique criteria used for the diagnosis, traditionally reusing or repurposing procedural codes created for another clinical trial according to the standards of one clinical trial is an impractical option.

[0047] In comparison, reference Figure 4 And continue to refer to Figure 3 The use of knowledge-based libraries with ontology hierarchies (e.g., ontology hierarchy 400) and databases that significantly reduce or eliminate query records by the systems and methods described herein facilitates the need for customized procedural code for workflows maintained by decision support applications (e.g., decision support application 312). Figure 4 An example ontology hierarchy 400 according to the aspects described herein is depicted. The depicted example ontology hierarchy 400 is a representative part of a hierarchy that may be guided by ontology-based classification components (e.g., Figure 3 The ontology-guided classification component 302 is generated from a knowledge-based library (e.g., a knowledge-based library 340).

[0048] Similar to ontologies in other scientific and technical domains, an ontology hierarchy (e.g., ontology hierarchy 400) includes a “tree,” “stem,” or “hierarchy” of concepts and rules 402 in relation to classes 404. For example, the depicted concept 406 includes a set of numerical concepts, which includes a Temperature concept. Each concept 406 is linked to at least one rule 408 through a set of properties 410. A property of a concept is a characteristic of the concept. A characteristic can include a directed binary relation that specifies a rule that is true for instances of the concept, a logical feature, for example, by transitivity, symmetry, inverse, and functionality. For example, in ontology hierarchy 400, the depicted property 410 specifies that the Temperature concept can have an answer defined by a rule defined by either an IncreasedTemperature rule or a NormalTemperature rule. Additionally, a property can include an interoperability data schema association. For example, in ontology hierarchy 400, the Temperature concept has a property 410 that associates the Temperature concept with a specific code (e.g., field address, 8310-5) associated.

[0049] As mentioned above, an ontology hierarchy references rules related to concepts and classes. A rule 308 defines a directed binary relation, a logical expression, or a combination thereof that is asserted to be true for an entity. In other words, for each entity being analyzed, if the rule IncreasedTemperature is evaluated to be true using temperature data included in the entity (e.g., a value stored in a data field), then a reasoner (e.g., reasoner 338) assumes that the discovered answer for the Temperature concept is IncreasedTemperature.

[0050] As mentioned above, an ontology hierarchy references classes related to concepts and rules. A class is a logical axiom that describes an entity based on only the rules and concepts of the ontology hierarchy. An ontology hierarchy can include one or more asserted classes. Each class is defined by a relation to an applicable concept. For example, ontology hierarchy 400 includes two depicted classes 404 (i.e., Covid-19_Diagnosis_Confirmed and Covid-19_Lab_Result_Positive). If, for example, an entity includes value data that is true for the logical axiom of the class, then a reasoner will infer that the entity is a member of the Covid-19_Diagnosis_Confirmed class. Although Figure 4 Two classes are depicted, but an ontology hierarchy can include multiple classes.

[0051] Continuing, Figure 5An example method 500 for integrating knowledge-based classification data for an entity (e.g., a patient record) with a process-coded decision support workflow is depicted in accordance with aspects described herein. For example, aspects of the method 500 can facilitate the maintenance of a process-coded workflow (e.g., the workflow 200 of Figure 3 by a decision support application (e.g., the decision support application 300 of Figure 2 based on classification data generated by an ontology-guided classification component (e.g., the ontology-guided classification component 302 of Figure 3 and a knowledge-based library (e.g., the knowledge-based library 340 of Figure 3 . Aspects of the method 500 can be performed by a processor executing instructions stored in a computer-readable medium. The processor can execute the instructions using any combination of hardware, firmware, or software directly or indirectly accessible to the processor. For example, some aspects of the method 500 can be implemented by the ontology-guided classification component 302 as described with respect to Figure 3 .

[0052] Generally, the method 500 detects a triggering event (e.g., a modification of a database record or an execution of a process-coded decision support workflow). A set of values, field addresses, and identifiers are extracted for the database record. The extracted data is populated into an entity in the knowledge-based library. Rules, concepts, and relationships of the knowledge-based library are asserted by a reasoner to infer a class of the entity. Based on the inferred class, classification data for the entity and values within the entity are computed. The classification data is returned to the process-coded decision support workflow that is executed based on the classification data.

[0053] Some aspects of the method 500 begin at block 502. At block 502, a modification of a field of a database record is detected via a set of process-executed code that monitors operations associated with a database that maintains the database record. For example, in some aspects, a script (e.g., the script 318 of Figure 3 queries a record repository server (e.g., the record repository server 316 of Figure 3 ) for changes to a record database (e.g., the record database 320 of Figure 3 ). The scraping or querying can be continuous, periodic, or intermittent. Additionally or alternatively, the repository server 316 can push newly modified records to a decision support application ingestion controller.

[0054] Some aspects of the method 500 instead begin from the detection of a triggering event. For example, a process-coded workflow (e.g., the process-coded workflow 318 of Figure 3 ) can be executed by a decision support application (e.g., the decision support application 300 of Figure 3within the decision support application 312) continuously, periodically, intermittently, or on-demand. The workflows can be executed by commands issued by, for example, a user device (e.g., Figure 3 a user device 310) of the EHR application. For example, a user can access a patient record saved in a records repository via an interaction with an EHR application interface. In response, the EHR application interface can activate one or more workflows via commands transmitted to the decision support application. Execution of the workflows can activate one or more scripts that query the database records of the patient.

[0055] At block 504, a plurality of values stored in database fields are extracted from the database record. The values include at least an identifier corresponding to the database record. In addition, in some aspects, a field address of the database field associated with each of the plurality of values is extracted. For example, a script (e.g., Figure 3 The script 318 of the EHR application 300 is procedurally coded to extract values and corresponding field addresses of one or more database records maintained by a database (e.g., the records database 320).

[0056] At block 506, an entity is generated in the knowledge-based library by executing a script that writes formatted versions of the plurality of values to a corresponding set of fields mapped to the plurality of database fields based on the field addresses. Some aspects of block 506 can be facilitated by executable procedural code of a script (e.g., Figure 3 the script 318 of the EHR application 300), an ingest controller (e.g., Figure 3 the ingest controller 332 of the EHR application 300), an ontology entity generator (e.g., Figure 3 the ontology entity generator 336 of the EHR application 300), or any combination thereof. For example, in particular aspects, the script includes a computer-readable mapping of field addresses from the records database (e.g., Figure 3 the records database 320 of the EHR application 300) to corresponding sets of fields in the entity of the knowledge-based library. The script can communicate the identifier(s) extracted from the records database to the ingest controller. The ingest controller can query the entity (or entities) in the knowledge-based library that include the identifier(s) as values in data fields. In response to a negative query result (i.e., the query does not return any entities), the ingest controller activates an ontology entity generator (e.g., Figure 3 the ontology entity generator 336 of the EHR application 300). The entity can be generated by the ontology entity generator using the values extracted by the script in the data fields defined by the mapping encoded within the script. Alternatively, some aspects of block 504 include modifying an existing entity in the knowledge-based library in response to detecting an entity (or entities) that include the identifier(s) extracted by the script. The ingest controller can activate an ontology entity modifier (e.g., Figure 3by the script in a mapping encoded within the script. The entity can be modified to include values extracted by the script in data fields defined by the mapping.

[0057] At block 508, a first class to which the entity belongs is computed based on reasoning by the reasoner and a knowledge-based library that includes the entity. Aspects of block 508 are facilitated by the reasoner (e.g., Figure 3 of the reasoner 338) and the knowledge-based library (e.g., Figure 3 of the knowledge-based library 340). For example, the reasoner can be activated to classify the entity based on logical conclusions of data asserted in the entity. The output of the reasoner can include at least one inferred class of the entity stored in the knowledge-based library. In other words, the reasoner takes as true logical axioms rules, concepts, classes, and relationships connecting each of them defined by data schema knowledge and taxonomy knowledge. The reasoner evaluates each entity in the library according to the rules and concepts and infers which class the entity belongs to.

[0058] At block 510, in response to the determination of the inferred class, classification data is returned as input to the procedurally-defined workflow of the entity. The classification data can include the first class, one or more superclasses of the first class, one or more immediate superclasses of the first class, one or more findings of values within the entity, or any combination thereof. In some aspects, block 510 is facilitated by the reasoner (e.g., Figure 3 of the reasoner 338) and the knowledge-based library (e.g., Figure 1 of the knowledge-based library 340).

[0059] At block 512, a workflow action in the procedurally-defined workflow is executed based on the classification data. In some aspects, block 512 is facilitated by the decision support application (e.g., Figure 2 of the decision support application 312), the user device (e.g., Figure 6 of the user device 310), or a combination of both. Further, some aspects of block 512 reinitiate one or more portions of the method 500 where execution of the procedurally-defined workflow reaches a non-terminating point of the procedurally-defined workflow. For example, as discussed with respect to Figure 6 and Figure 6 the decision support application can trigger the script to determine whether the workflow reached a terminating point during or after execution of the procedurally-defined workflow based on the classification data. When a terminating point is not reached, the decision support application can trigger the script to extract additional data from the database record. The class of the entity corresponding to the database record can be populated with the additional data and the class of the entity can be re-inferred by the reasoner.

[0060] Advantageously, and in contrast to traditional process-defined workflows, the classes of entities are dynamically dependent on values associated with the entities. Thus, in contrast to traditional process-defined workflows, the addition or manipulation of data in a record can not simply advance the workflow to the next process-defined point. Rather, aspects of the hybrid system and method described herein can facilitate the adaptive execution of process-defined workflows based on classification data dynamically inferred from rules, classes, and relationships defined by a knowledge-based library.

[0061] Embodiments of the disclosure can be described in the general context of computer code or machine-useable instructions, including computer-executable instructions such as program modules, being executed by a computer or other machine, such as a personal data assistant, a smart phone, a tablet PC or other handheld device. Generally, program modules, including routines, programs, objects, components, data structures, and the like, refer to code that performs particular tasks or implements particular abstract data types. Embodiments of the disclosure can be practiced in a variety of system configurations, including mobile devices, consumer electronics, general- purpose computing devices or the like. Embodiments of the disclosure can also be practiced within a distributed computing environment, where tasks are performed by a remote processing device that is linked through 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.

[0062] Reference Figure 6 The computing device 600 includes a bus 610 that 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 an illustrative power supply 622. Bus 610 can represent one or more busses, such as an address bus, a data bus, or a combination thereof. While the ​ The various blocks shown in the figures can be represented by diverse blocks of diverse shapes. Similarly, the various buses, lines, etc. shown in the figures can each represent diverse lines, buses, etc. of diverse shapes, sizes, etc. For the sake of presentation, the ​ The diagram of FIG. 6 is merely illustrative of an example computing device that can be used with one or more embodiments of the disclosure. Distinction is not made between such categories as "workstation," "server," "laptop," "handheld device," etc., as all are contemplated within the scope of ​ The diagram of FIG. 6 is merely illustrative of an example computing device that can be used with one or more embodiments of the disclosure. Distinction is not made between such categories as "workstation," "server," "laptop," "handheld device," etc., as all are contemplated within the scope of

[0063] Computing device 600 typically includes a variety of computer-readable media. Computer-readable media can be any available media that is accessible by computing device 600 and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer-readable media can comprise computer storage media and communication media. Computer storage media includes both volatile and nonvolatile, 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 includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computing device 600. Computer storage media excludes transitory 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 includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics 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, RF, infrared and other wireless media. Combinations of the any of the above should also be included within the scope of computer readable media.

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

[0065] I / O port 618 allows computing device 600 to be logically coupled to other devices, including I / O components 620, some of which may be built-in. Illustrative components include microphones, joysticks, game controllers, satellite antennas, scanners, printers, wireless devices, etc. I / O components 620 can provide a Natural User Interface (NUI) for processing user-generated air gestures, voice, or other physiological input. In some cases, the input can be transmitted to appropriate network elements for further processing. The NUI can implement any combination of voice recognition, touch and stylus recognition, facial recognition, biometric recognition, on-screen and near-screen gesture recognition, air gestures, head and eye tracking, and touch recognition associated with a display on computing device 600. Computing device 600 may be equipped with depth cameras, such as stereo camera systems, infrared camera systems, RGB camera systems, and combinations thereof, for gesture detection and recognition. Furthermore, computing device 600 may be equipped with accelerometers or gyroscopes that enable motion detection. The output of the accelerometer or gyroscope can be provided to the display of computing device 600 to render immersive augmented reality or virtual reality.

[0066] Some embodiments of computing device 600 may include one or more radio transceivers 624 (or similar wireless communication components). Radio transceivers 624 transmit and receive radio or wireless communications. Computing device 600 may be a wireless terminal adapted to receive communications and media over various wireless networks. Computing device 600 may communicate with other devices 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. Radio communication may be a short-range connection, a long-range connection, or a combination of short-range and long-range wireless telecommunication connections. When we refer to “short” and “long” type connections, we are not referring to a spatial relationship between two devices. Instead, we generally refer to short-range and long-range as different categories or types of connections (i.e., primary and secondary connections). Short-range connections may include (for example, but not limited to) connections with devices that provide access to wireless communication networks (e.g., mobile hotspots). Connections, such as WLAN connections using the 802.11 protocol; connections with another computing device. A connection is a second example of a short-range connection or near-field communication connection. Long-range connections can include connections using one or more of the following protocols: CDMA, LTE, GPRS, GSM, TDMA, and 802.16, for example, but not limited to.

[0067] The subject matter of the techniques described herein is described with specificity 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, including different steps or combinations of steps in different arrangements and / or combinations with other existing or future technologies. Moreover, although the terms "step" and / or "block" might 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 unless and except when the order of individual steps is explicitly described. Additionally, the pseudocode included herein is illustrative in nature and should not be interpreted as implying any particular requirements on programming languages, as the variations in programming languages are contemplated.

Claims

1. A method comprising: detecting, via a set of procedurally executed code that monitors operations associated with a database that maintains a database record, a modification of a field in a plurality of database fields of the database record; and in response to detecting the modification of the field: extracting, via the set of procedurally executed code, a plurality of values stored in the plurality of database fields; executing a script that writes a formatted version of the plurality of values to generate an entity in a knowledge-based library; computing a first class of the entity based on an inference from an inferrer extracted from the knowledge-based library; returning classification data of the entity corresponding to the first class as an input to a procedurally defined workflow; and executing a workflow action in the procedurally defined workflow based on the classification data.

2. The method of claim 1, wherein the workflow action generates a prompt for input of additional data in response to reaching a non-terminal point in the procedurally defined workflow, and the method further comprises extracting a second plurality of values stored in a second plurality of database fields and incorporating the second plurality of values to the entity in the knowledge-based library in response to the extracting.

3. The method of claim 1, wherein the database is a relational database maintained by an electronic health record, wherein the procedurally executed code is compiled from at least one file containing at least one object-oriented programming language, and wherein the script is selected from a plurality of scripts based on the procedurally defined workflow.

4. The method of claim 1, wherein the modification of the field is triggered by executing another procedurally defined workflow within an application executing locally.

5. The method of claim 1, wherein the inferrer computes the first class of the entity based on a logical result of the plurality of values used to generate the entity.

6. The method of claim 1, wherein the plurality of values includes an identifier, and wherein the generating comprises querying a knowledge-based system based on one or more programmatic expressions of the script to retrieve an entity corresponding to the identifier to create the entity.

7. The method of claim 6, further comprising if the knowledge-based system includes a particular entity corresponding to the identifier: then, after the querying, modifying, by the script, the particular entity with information associated with the plurality of values.

8. The method of claim 6, further comprising, after the querying, automatically performing, by the script, a first set of operations that create a new entity within the knowledge-based system.

9. The method of claim 8, wherein the first set of operations are automatically performed by the script based on the knowledge-based system not including a particular entity corresponding to the identifier.

10. The method of claim 6, further comprising if the knowledge-based system does not include a particular entity corresponding to the identifier: then, after the querying, transmitting, by the script, the extracted data to an ontology-directed classification component to facilitate creation of a new entity within the knowledge-based system.

11. The method of claim 6, wherein the generating the entity comprises activating an ontology entity generator to create the entity.

12. A system having one or more processors configured to facilitate a plurality of operations, the operations comprising: detecting, via a set of procedurally executed code that monitors operations associated with a database that maintains database records, a modification of a field in a plurality of database fields of a database record; and in response to detecting the modification of the field: extracting, via the set of procedurally executed code, a plurality of values stored in the plurality of database fields; executing a script that writes a formatted version of the plurality of values to generate an entity in a knowledge-based library; computing a first class of the entity based on inferences of a reasoner extracted from the knowledge-based library; returning classification data of the entity corresponding to the first class as an input to a procedurally defined workflow; and performing a workflow action in the procedurally defined workflow based on the classification data.

13. The system of claim 12, wherein the workflow action generates a prompt for input of additional data in response to reaching a non-terminal point in the procedurally defined workflow, and wherein the operations further comprise incorporating a second plurality of values stored in a second plurality of database fields to the entity in the knowledge-based library in response to extracting the second plurality of values.

14. The system of claim 12, wherein the database is a relational database maintained by an electronic health record.

15. The system of claim 12, wherein the procedurally executed code is compiled from at least one file comprising an object-oriented programming language.

16. The system of claim 12, wherein the script is selected from a plurality of scripts based on the procedurally defined workflow.

17. The system of claim 12, wherein the modification of the field is triggered by executing another procedurally defined workflow within a locally executing application.

18. One or more non-transitory media having instructions that, when executed by one or more processors, cause the one or more processors to facilitate a plurality of operations, the operations comprising: detecting, via a set of procedurally executed code that monitors operations associated with a database that maintains database records, a modification of a field in a plurality of database fields of a database record; and in response to detecting the modification of the field: extracting, via the set of procedurally executed code, a plurality of values stored in the plurality of database fields; executing a script that writes a formatted version of the plurality of values to generate an entity in a knowledge-based library; computing a first class of the entity based on inferences of a reasoner extracted from the knowledge-based library; returning classification data of the entity corresponding to the first class as an input to a procedurally defined workflow; and performing a workflow action in the procedurally defined workflow based on the classification data.

19. The one or more non-transitory media of claim 18, wherein the workflow action generates a prompt for input of additional data in response to reaching a non-terminal point in a process-defined workflow, and wherein the operations further comprise extracting a second plurality of values stored in a second plurality of database fields, and incorporating the second plurality of values to an entity in a knowledge-based library in response to the extracting.

20. The one or more non-transitory media of claim 18, wherein the database is a relational database maintained by an electronic health record, wherein the process-executed code is compiled from at least one file comprising an object-oriented programming language, and wherein the modification of a field is triggered by executing another process-defined workflow within a locally-executed application.

Images