Systems and technologies for generating reusable processes

Abstract

In some embodiments, the method may be carried out by the processor of a computing device. The method includes generating a non-executable code template containing code that defines a set of behaviors. Additionally, the method includes accessing data relating to a particular project. Furthermore, the method includes determining a set of project variables and a set of project logic relating to a particular project. Furthermore, the method includes generating executable code by integrating the set of project variables and the set of project logic into a non-executable code template. Moreover, the method includes compiling the executable code and producing results by executing the compiled executable code.

Description

Technical Field

[0001] Cross - reference to Related Applications This application claims priority from U.S. Patent Application No. 18 / 229,979, filed on August 3, 2023, which claims the benefit of the filing date of U.S. Provisional Patent Application No. 63 / 452,886, the entire disclosure of which is incorporated herein by reference.

[0002] Field of the Invention The present disclosure generally relates to generating reusable processes, and more particularly, but not limited to, converting a set of unique processes into a single reusable process.

Background Art

[0003] Background Conventionally, code reusability is not effective for code used in non - general - purpose or dissimilar products. As such, as a result of being unable to reuse code across multiple products, hundreds (or more) of processes each having unique code can be generated by an entity. In other words, each of the hundreds of unique processes includes a self - contained codebase distinct from other codebases because the data and logic of the process are clearly different from each other. Further, each of these processes can include hundreds or thousands of lines of code that are written and tested individually.

Summary of the Invention

Problems to be Solved by the Invention

[0004] Current methodologies for generating products are complex and rely on large - scale codebases. Large - scale codebases use significant resources for both development and maintenance. Further, updates to individual products have no relation to the codebases associated with other products. Thus, all codebases that rely on similar updates need to perform a unique update process, which further consumes resources.

[0005] Current methodologies may be effective for entities with a small, simple set of projects. While designing and writing these projects remains complex, the logic is well-known and conforms to standards. For these smaller, simpler sets of projects, iterative coding and updates may suffice. However, as these sets of projects grow and become more complex with significant dependencies, the processes required to generate and maintain the project codebase become time- and resource-intensive tasks.

[0006] Brief Overview This disclosure describes a novel computing system capable of converting a set of unique processes into a single reusable process. Such a computing system reduces resource consumption when developing and deploying a set of unique processes through a single reusable process. [Means for solving the problem]

[0007] In one example, the method is carried out by one or more processors. The method includes generating a non-executable code template containing code that defines a set of behaviors. Additionally, the method includes accessing data relating to a particular project. Furthermore, the method includes determining a set of project variables and a set of project logic relating to a particular project. Furthermore, the method includes generating executable code by integrating the set of project variables and the set of project logic into a non-executable code template. Moreover, the method includes compiling the executable code and producing results by executing the compiled executable code.

[0008] In various embodiments, a system is provided which includes one or more data processors and a non-temporary computer-readable storage medium that, when executed on one or more data processors, contains instructions causing one or more data processors to perform an action. The action includes generating a non-executable code template containing code that defines a set of actions. Additionally, the action includes accessing data relating to a particular project and determining a set of project variables relating to a particular project. Furthermore, the action includes determining a set of project logic relating to a particular project. The action also includes generating executable code by integrating the set of project variables and the set of project logic into a non-executable code template and compiling the executable code. Moreover, the action includes producing a result by executing the compiled executable code.

[0009] In various embodiments, a computer program product is provided which includes instructions that are tangibly embodied in a non-temporary machine-readable storage medium and cause one or more data processors to perform an action. The action includes generating a non-executable code template containing code that defines a set of actions. Additionally, the action includes accessing data relating to a particular project and determining a set of project variables associated with that particular project. Furthermore, the action includes determining a set of project logic associated with that particular project. The action also includes generating executable code by integrating the set of project variables and the set of project logic into the non-executable code template, and compiling the executable code. Moreover, the action includes producing a result by executing the compiled executable code.

[0010] The techniques described above and below can be implemented in multiple forms and in multiple contexts. Several exemplary embodiments and contexts are provided with reference to the accompanying drawings, as will be described in more detail below. However, the embodiments and contexts described below are only a few of many. [Brief explanation of the drawing]

[0011] [Figure 1] This is a simplified block diagram of a set of exemplary projects in a particular manner. [Figure 2] This is a simplified block diagram of a process for generating variable logic in a certain manner. [Figure 3] This is a simplified block diagram of a process for generating extraction logic and outputting results in a certain manner. [Figure 4] This is a simplified block diagram of a process for implementing metadata management in a particular manner. [Figure 5] This is a flowchart of a process for generating and implementing a single, reusable process for carrying out a project in a particular manner. [Figure 6] This is a simplified diagram of a distributed system for implementing a certain configuration. [Figure 7] This is a simplified block diagram of one or more components of a system environment that can provide services provided by one or more components of an embodiment system, according to a certain aspect, as a cloud service. [Figure 8] This figure shows an exemplary computer system that can be used to carry out a certain embodiment. [Modes for carrying out the invention]

[0012] Detailed explanation In the following description, specific details are provided for illustrative purposes to provide a complete understanding of certain embodiments. However, it should be understood that various embodiments may be carried out without these specific details. The drawings and descriptions are not intended to be limiting. The term “exemplary” is used herein to mean “serving as an example, case, or illustration.” Any embodiment or design described herein as “exemplary” should not necessarily be construed as being preferable or advantageous to other embodiments or designs.

[0013] This disclosure describes a novel computing system that enables the transformation of a set of unique processes into a single reusable process. Such a computing system reduces resource consumption when developing and deploying a set of unique processes through a single reusable process. For example, this technique can dramatically simplify the code used to implement a set of unique processes by reusing logic in a unique manner from code that may consist of hundreds or thousands of lines. Since all domains can then follow a single proven method with a single reusable process, these techniques make the generation and implementation of code for processes much faster, less error-prone, and of higher quality. Thus, the subject matter of this disclosure can achieve significant time and resource savings compared to current methodologies used today.

[0014] The computing system may include a process for generating a non-executable code template containing code that defines a set of actions. The set of actions may include actions used to perform a project, such as data extraction, which can be generated by executable code subsequently generated from the non-executable code template. For example, the non-executable code template may be a template generated to perform a general-purpose or repeatable process or logic when populated with specific project-specific variables and logic to make the non-executable code executable. That is, the non-executable code template may provide a code structure that becomes executable when specific variables and logic are integrated into the non-executable code template. The specific variables and logic may be specific to a particular project and not used in any other project associated with the set of actions. The computing system may also include a process for generating a variable metadata table containing variable fields associated with the set of actions. The process may also generate a logic metadata table containing logic fields associated with the set of actions. The variables and logic populated into the non-executable code template to make it executable may be obtained from the variable metadata table and the logic metadata table. While variable metadata tables and logic metadata tables are described as tables for storing variable and logic metadata, other storage systems are also available. For example, a table may contain rows and columns in a two-dimensional space, but additional storage systems, such as multidimensional storage systems, may also be used to store variable and logic metadata.

[0015] Furthermore, the computing system may include a process for accessing data relating to a particular project, which is performed by one or more actions of a set of actions within a non-executable code template. For example, a particular project may be a specific data extraction that a user wishes to perform. For instance, a particular project may be retrieving orders relating to medical visits being tracked at a hospital. Based on the data accessed for a particular project, the process performed by the computing system may include determining a set of variables from a variable metadata table and a set of logic from a logic metadata table that are relevant to the particular project. As used herein, the term “variable” may include data that identifies a particular value. For example, a variable may represent an individual’s identity, an action taken by an individual, or any other data that may change based on specified conditions. The term “variable name” may represent an identifier of what the variable represents, and the term “variable value” may represent the actual value of the variable in a particular instance. The term “logic” may represent any actions used in a project to access or manipulate data, such as variable values, in order to generate project output.

[0016] Once a set of variables and logic associated with a particular project is identified, a computing system can perform a process to generate executable code by integrating the set of variables and logic into a non-executable code template. In other words, by integrating the variables and logic into a non-executable code template, executable code capable of performing the actions of a particular project can be generated. The process performed by the computing system may include compiling the executable code and generating results by executing the compiled executable code. This process is repeatable for multiple different projects without requiring the generation of a new codebase for each different project. Therefore, the computing system can efficiently reuse the logic within a non-executable code template to generate executable code for various projects by swapping the variables and logic that can be integrated into a non-executable code template.

[0017] Compiling executable code may be done using a compiler, which is used to translate source code of a programming language into machine code. Non-executable code described herein may be parts of code that cannot be independently executed by a computing system. Executable code described herein, which may be generated by combining the non-executable code described herein, can be executed by a computing system once the compilation operation by the compiler is complete.

[0018] FIG. 1 is a simplified block diagram of an exemplary set of projects 100 according to one aspect. The set of projects 100 can be defined by a series of operations 101a, 101b,... 101n that perform specific tasks using information obtained from a set of tables 102. The output of the series of operations 101a, 101b,... 101n can include data files 104a, 104b,... 104n generated using information extracted from multiple tables 102. For example, operation 101a may be a data extraction that includes specific logic used to retrieve an order from an order table 102 associated with a specific visit in a visit table 102. The logic used to extract data from table 102 can be unique in that different logic can be used for each of operations 101a, 101b,... 101n. As used herein, data extraction can refer to the act of collecting or retrieving various information from various sources such as table 102.

[0019] In one example, operations 101 may perform similar tasks. For example, all of operations 101 may perform data extraction from one or more of tables 102. An individual operation 101 may include specific logic for performing a specific data extraction, but the structure of the specific logic can include a significant amount of reusable code. In such an example, operation 101 may be defined by both a set of specific code associated with a specific operation 101 and a set of iterative code associated with all of the operations 101 of the set of projects 100. Thus, a reusable non-executable code template, as discussed in more detail below, may be generated to enable integration of variables and logic associated with operation 101 into non-executable code. As a result of integrating the non-executable code template, variables, and logic, executable code can be generated that is capable of performing a specific operation 101 associated with one of the projects of the set of projects 100.

[0020] Furthermore, the set of projects 100 is generally described in relation to data extraction from the set of tables 102. The methodologies described in this disclosure may be used in additional or alternative embodiments. For example, this methodology may be used to insert data into a particular table 102. If there are thousands of tables 102 that can receive data from data insertion, the insertion logic for each table may be unique due to differences in the data and logic within the table, so there may be thousands of individual code projects that perform unique data insertion into these tables 102. The general part of the insertion can be pulled into a single codebase, and the unique logic (i.e., variables and operation logic) for each table insertion can be stored in one or more metadata tables. The unique logic can be called by a single codebase to perform the unique insertion of data. Additionally, at some future point, if an enhancement is discovered to more efficiently insert data into a portion of the general tables, instead of applying code changes to each of the thousands of individual code projects, the change can be implemented by making a single code change in a single codebase.

[0021] Additional examples may include methodologies for deleting data from a particular table. If there are thousands of tables 102 from which deletion can occur, the deletion logic for each table may be unique due to the uniqueness of the data and logic within the table, so there may be thousands of individual code projects that perform unique deletions from these tables 102. The general part of the deletion can be pulled into a single codebase, and the unique logic (i.e., variables and operation logic) for each table deletion can be stored in one or more metadata tables. The unique logic can be called by a single codebase to perform the unique deletion of data. Additionally, at some future point, if a defect is discovered in the code, instead of applying code changes to each of the thousands of individual code projects, the correction can be implemented by making a single code change in a single codebase.

[0022] The set of Project 100 is merely illustrative, and other embodiments may be far more complex. Furthermore, while Figure 1 is illustrated in relation to extractions related to data stored in Table 102, such as a Structured Query Language (SQL) system, other languages ​​and database storage systems may be implemented using techniques similar to those described herein. For example, the subject matter of this disclosure may apply to any codebase having multiple unique code projects that perform the same overall functionality at a very high level. Moreover, the code can be backend code, frontend application code, cloud-based code, or any other type of code. In addition, while the set of Project 100 is shown in relation to a clinical setting (e.g., ordering and consultation), its use is not limited to the medical or healthcare administration field.

[0023] Figure 2 shows a simplified block diagram of process 200 for generating variable logic in a particular manner. The variable logic generated through process 200 may be specific to a particular project. For example, the variable logic may identify the logic that separates one project from another, if both share a single codebase. Although the project is described as a data extract in Figure 2, process 200 may be used for any code area where there are multiple specific code projects that perform the same high-level functionality at a very high level.

[0024] In block 202, process 200 includes receiving an input that identifies a particular data extract. The particular data extract may be part of a project, and process 200 may be tasked with generating the individual variable logic for that data extract. In block 204, process 200 includes a single codebase for a set of data extracts that accepts data extract identifiers from block 202. A data extract identifier may be a unique string that identifies a particular data extract that may be part of a project. Examples of data extract identifiers for project 100 in Figure 1 include “receive order”, “receive name”, or other “<data file name>” identifiers.

[0025] Furthermore, as will be discussed in detail below, blocks 206, 208, and 210 collectively represent the use of variable template code, which can define the general-purpose and iterable parts of the variable logic. In one example, the variable template code may read specific components of the variable metadata 214, and the reading of the variable metadata 214 by the variable template code may use specific logic related to the variables defined and set in block 404 of process 400, which will be described below with respect to Figure 4.

[0026] In block 206, process 200 includes defining and setting generic variables used across all extracts in a set of extracts using a single codebase. Defining and setting generic variables may mean identifying variables used across a set of extracts. In subblock 212, to define generic variables, variable metadata 214 may be read by variable template code, and the data read from variable metadata 214 may be filtered to find generic variables using identification information of a particular data extract used as input. The filtered variable metadata is used to define and set the values ​​of all generic variables. That is, the filtered variable metadata is used to define and set generic variables for a particular data extract used across all projects in the same single codebase. In other words, template code may be used for common, reusable variable logic, and the values ​​returned by the metadata may be used to create specific values ​​and assign them to all variables. Variables can be static or dynamic runtime variables. In one example, dynamic variables may include additional logic that uses the returned metadata to query the required values ​​from a given table, either at compile time or runtime.

[0027] Specific examples of common reusable variable logic may be Select_SQL commands, From_SQL commands, Where_SQL commands, or a combination thereof. These common reusable variable logic commands may be used to construct variable template code. Examples of metadata fields to be read may include a data extract identifier (e.g., unique text for a given data extract), a variable name (e.g., unique text for a given variable), a variable type (e.g., generic, customized, or extract-specific), a sequence order (e.g., the executable order in which the extract is performed), a command used to hold a unique code used to identify the selected fields used to populate a given variable (e.g., Select_SQL), a command used to hold a unique code used to identify the table used to populate a given variable (e.g., From_SQL), and a command used to hold a unique code used to apply logic for joining tables and filtering data used to populate a given variable (e.g., Where_SQL). Other metadata fields may be used, and the metadata fields may differ depending on the nature of the single codebase being executed (e.g., a data extract codebase versus a table data deletion codebase).

[0028] In block 208, process 200 includes defining and setting variables used for customizing and localizing a particular data extract. Customization and localization variables may be used to achieve specific project requirements that may differ from project to project. In subblock 216, variable metadata 214 and customization and localization metadata 218 may be read to define customization variables, and the data read from variable metadata 214 and customization and localization metadata 218 may be filtered to find customization variables associated with the identification information of a particular data extract used as input in block 202. The filtered variable metadata and filtered customization and localization metadata are used to define and set the values ​​of all customization variables. That is, the filtered variable metadata is used to define and set customization variables for a particular data extract, and the customization differs from other projects that also use a single codebase. Additional logic may be added to read or use customization and localization variables. In some examples, variables may be defined dynamically at compile time rather than runtime and may be populated with metadata input.

[0029] For example, subblock 220 may determine whether customization criteria are met or whether the user has provided instructions to perform customization on a particular data extract variable. If further customization is required or desired, override values ​​may be used in subblock 222 to populate the variables of the particular extract. For example, the override values ​​may replace or otherwise modify a particular data extract variable. An exemplary override value may include a variable assigned to capture a value used for the “Primary Nurse” variable. A particular client site may have a customized, non-standard setup used to define this particular variable. The setup may not match the logic used across most client sites for this variable. In such an example, using the standard logic may return an incorrect value for that particular client site, and it may be preferable for that client to override the standard logic with custom logic or to use hardcoded override values. For example, if standard logic returns the value "123," but the correct value for a particular client site is "456," the client could override the standard logic with local custom logic that returns the correct value "456," or it could use the override value "456." Another example might be the "client name" variable. In this example, there might not be standard logic used across clients to populate the variable with data, and all clients could use a custom override value to correctly set their own name for that variable.

[0030] If no further customization is required, in subblock 224, variables are populated with data from variable metadata 214. In such an example, a common, reusable set of variable template code uses variable metadata 214 to construct executable code constructs that, when executed, populate all variables in this section with data. These variables may be static variables, dynamic runtime variables, or dynamic compile-time variables. Static variables are set and stored individually, while dynamic variables are populated with data through logic during the variable execution phase (i.e., dynamic runtime variables) or during the compilation phase described later (i.e., dynamic compile-time variables). Executable code may be executed dynamically to produce results used to populate customized and localized variables. Examples of template code include the Select_SQL, From_SQL, and Where_SQL commands mentioned above with respect to block 206.

[0031] In subblock 226, value-added additions are made to the variable template code. For example, variable data may be validated, and common, reusable template code may be tuned to perform as well as possible. Furthermore, debugging logic may be added to the variable template code to enable easier debugging of the code. Other value-added additions may also be included.

[0032] In block 210, process 200 includes defining and setting variables used for individual extracts. To define individual variables, variable metadata 214 may be read, and variable metadata 214 may be filtered to find extract-specific variables using identification information for a particular data extract used as input. The filtered variable metadata is used to define and set the values ​​of all extract-specific variables. That is, the filtered variable metadata is used to define and set extract-specific variables for a particular data extract unique to all projects in a single codebase. A set of variables 228 for a particular data extract may be defined for generic variables, customized and localized variables, as well as for individual extract variables. Furthermore, variables may be validated using null checks, sanity values, or other validation techniques.

[0033] Subblocks 212, 216, 220, 222, 224, and 226 are described above as being specific to block 208 of process 200 for defining and setting variables used for customization and localization, but the same or similar subblock operations 212, 216, 220, 222, 224, and 226 may also be used to define and set general variables in block 206 and to define and set variables used for individual extractions in block 210. Furthermore, subblocks 212, 216, 220, 222, 224, and 226 may be used to define and set other variables not described in the example of process 200.

[0034] Figure 3 shows a simplified block diagram of a process 300 for generating extraction logic and outputting results in one embodiment. The extraction logic may be generated using customized and localized metadata 218, variables 228 generated in process 200, and extraction metadata 302. In block 306, process 300 includes dynamically collecting the extraction metadata, and in block 308, process 300 includes creating and executing the extraction logic. Blocks 306 and 308 generally represent the use of logic template code, which can define a generic and repeatable portion of the extraction logic. In one example, the logic template code may read specific components of the extraction metadata 302 or other operational metadata, and the reading of the extraction metadata 302 by the logic template code may use specific logic related to the operational logic created in block 404 of process 400, which is described below with respect to Figure 4.

[0035] In one example, in block 306, process 300 may include reading extract metadata 302 by logic template code, which is filtered for data extract identifiers in block 202 as defined in Figure 2 and sorted in section sequence order. The filtered extract metadata can be used to identify metadata used by a particular section of the extract logic. Common, reusable extract logic, unique logic returned by the filtered metadata, and template code for variable 228 can be used to dynamically create executable extract logic for performing a particular section of data extract.

[0036] Specific examples of common reusable extract logic may be Select_SQL commands, From_SQL commands, Where_SQL commands, or a combination thereof. These common reusable extract logic commands may be used to construct logic template code. Fields read from extract metadata 302 may include a data extract identifier (e.g., unique text for a given data extract), a table name creator (e.g., unique text for a given table / file to be created), a sequence order (e.g., the executable order in which the extract is performed), a command used to hold a unique code used to identify the selected fields used to populate a given extract (e.g., Select_SQL), a command used to hold a unique code used to identify a table used to populate a given extract (e.g., From_SQL), a command used to populate a given extract (e.g., Where_SQL), and a table / file definition (e.g., output field order, data types, etc., used to define the table / file being created). Other metadata fields may be used, and these metadata fields may differ depending on the nature of the single codebase being executed (e.g., data extraction codebase vs. table data deletion codebase).

[0037] The extraction logic can include table joins, table filters, fields to select (and their order / data type), data transformations, general logic used across all extractions (e.g., data range filters, client identifiers, etc.), or any other logic used to perform the data extraction. When variable metadata is populated into the executable extraction logic, dynamically compiled variables may be created. In addition, additional logic may be added as needed to read and use customized and localized data (e.g., as derived from customized and localized metadata 218).

[0038] Specific extraction logic may be stored in the extraction metadata table. A specific example of specific extraction logic for a particular data extraction might be "e.Encounter_ID, p.Person_Name" selected from "Encounter e, Person p", where "e.Person_ID = p.Person_ID and e.Update_DT_TM >= SYSDATE - 1". In other words, specific extraction logic can define how generic extraction logic (e.g., Select_SQL, Where_SQL, Where_SQL) works.

[0039] In block 308, process 300 includes constructing a specific data extract as executable code using non-executable code logic collected from the extracted metadata 302 and variable template code 309, which may be determined using process 200 as described above. For example, the non-executable code logic may be parsed to dynamically replace all variable locations within the non-executable code logic with variables 228 generated by process 200. Once the variable locations have been replaced with variables 228 and executable code has been generated, the executable code may be compiled.

[0040] In block 310, process 300 includes making value-added additions to the logic template code. For example, the logic may be validated, and common, reusable template code may be tuned to perform as well as possible. Furthermore, debugging logic may be added to the logic template code to enable easier debugging of the code. Other value-added additions may also be included.

[0041] In block 312, process 300 includes creating a file or table containing data in response to a specific data extraction. For example, process 300 may include returning information from table 102 (e.g., the Incoming Orders table and the Orders table) to generate a file or table 314 that stores incoming orders or other data in response to a specific data extraction or other specific project. In one example, the file or table 314 may be presented to a user, sent to a user, used to control data storage operations, used to control the execution of another application, or used to perform any other operations related to the information collected in the file or table 314.

[0042] Figure 4 shows a simplified block diagram of process 400 for performing metadata management as part of processes 200 and 300 described above with respect to Figures 2 and 3 in a certain embodiment. In one example, metadata management may include maintaining metadata (e.g., associated with variables and logic operations) used for a single reusable process. In block 402, process 400 includes defining and setting generic metadata management variables. The generic metadata management variables defined and set in block 402 may generally be used across metadata management processes. These generic metadata management variables are different from the generic variables described above with respect to block 206 of process 200.

[0043] In block 404, process 400 includes defining unique code for populating variable metadata tables and extract metadata tables. This may include defining and setting all variables and extract logic specific to a given project, and defining unique code for populating variable metadata tables and extract metadata tables may be repeated each time a new metadata row is populated for those tables. For example, variables and extract logic specific to a given project may include core non-executable code stored in the metadata tables. Unique code may be defined individually for each variable or logic section used in a given project, and unique code is defined once at creation and modified as needed for maintenance (e.g., bug fixes, additions of extensions, etc.). All individual parts of the unique code may be stored together in the metadata tables or other storage structures, and as a result, the individual parts can be called to be inserted into template code to generate executable code.

[0044] Additionally, dynamic runtime variables can be defined for sections of code that require dynamic data ingestion during data extraction. Dynamic compile-time variables can also be defined and infused with their values ​​each time the metadata management process runs, and a metadata table can store these values. The storage of dynamic compile-time variables and the definition of dynamic runtime variables allow for the dynamic updating of runtime values ​​that may change with each code execution, while simultaneously enabling the setting of variable values ​​that are the same for a given embodiment at the time of metadata creation.

[0045] In block 406, process 400 includes creating a subprogram in Data Manipulation Language (DML) using metadata. The subprogram may include template code that stores general-purpose logic that is reusable across all metadata to insert, update, or delete metadata tables. The subprogram may use general-purpose logic read in each of the variables and extract-specific logic components created in block 404 to easily insert, update, or delete various metadata tables. The unique inputs of each project or set of projects may be collected as unique variables, similar to process 200 using variable metadata 214. Additionally, all general-purpose iterable variables may be defined and set for a set of projects, similar to process 200 using variable metadata 214. Furthermore, template code may define common reusable logic used for data manipulation of metadata tables, similar to process 300 using extract metadata 302. The DML may be created and executed as executable code using the unique inputs, iterable variables, and template code, similar to process 300.

[0046] The creation of the subprogram in block 406 may be performed at a frequency as desired. For example, if two of the many individual variables or extract-specific logic components created or maintained in block 404 are modified, the subprogram in block 406 may perform the work of all of the many individual variables or extract-specific logic components by scanning the code in block 404 and, as desired, inserting, updating, or deleting metadata. In some examples, logic may be used to determine that all individual variables or extract-specific logic components other than the two mentioned above have not been changed. Thus, those other individual variables or extract-specific logic components may be skipped, but all individual-specific logic components may be checked. In this example, two components are described as changing, but changes to any number of components may be performed in the same manner.

[0047] In block 408, process 400 includes performing value-added additions to the executable code. For example, DML execution may be validated, and common, reusable template code may be tuned to perform as well as possible. Furthermore, debugging logic may be added to the code to enable easier debugging of the code. Other value-added additions may also be included. Using process 400, variables and extracted metadata tables, or other storage structures, may be updated, added to, and maintained so that processes 200 and 300 can easily access metadata stored in metadata tables for inserting metadata into code templates.

[0048] Figure 5 shows a flowchart of process 500 for generating and executing a single reusable process for carrying out a project according to a certain embodiment. For example, one or more process blocks in Figure 5 may be executed by a computing device.

[0049] Figure 5 shows an exemplary block of process 500, but it should be noted that in some embodiments, process 500 may include additional blocks, fewer blocks, different blocks, or blocks in different arrangement configurations compared to those shown in Figure 5. Additionally or alternatively, two or more blocks of process 500 may be performed in parallel.

[0050] In block 502, process 500 includes identifying multiple variable definitions associated with multiple variables used in a project, such as data extraction. Variables used in a project may define values ​​that may change across the project (e.g., obtainable from tables, databases, or other data sources). Variable definitions may include a logical structure for identifying the location of the variables within the data source.

[0051] In block 504, process 500 includes identifying variable iteration logic across multiple variable definitions, as described above with respect to subblock 224 of process 200. The identified iteration logic may identify generic or dynamic variables used across all projects in a set of projects.

[0052] In block 506, process 500 includes constructing variable template code using variable iteration logic, as described above with respect to subblock 224 of process 200. The variable template code may be non-executable code, and the variable template code may be used as part of a single reusable code for a set of projects.

[0053] In block 508, process 500 includes storing specific portions of multiple variable definitions in a variable metadata table. The variable metadata table may be defined to allow variable template code to dynamically recreate variable definitions using the fields in the variable metadata table. Furthermore, a single codebase may be used to insert, update, and delete specific portions of multiple variable definitions in the variable metadata table. The single codebase may be used for initial data entry and ongoing data maintenance, and may be executed whenever logic for any variable metadata is created, modified, or deleted. For example, blocks 502 and 508 may be iterated each time a new project is added to the set of projects, and blocks 504, 506, and 508 may be validated for each new code project to ensure that process 500 continues to function for the new project.

[0054] In block 510, process 500 includes identifying multiple logic segments associated with multiple tables and files used in the project, as described above with respect to block 306 of process 300. The logic segments may include code logic used to collect information from the multiple tables and files.

[0055] In block 512, process 500 includes identifying iterative logic that is repeated across all logic segments of the set of projects, as described above with respect to block 308 of process 300. The identified iterative logic may identify generic logic used across all projects in the set of projects.

[0056] In block 514, process 500 includes constructing logic template code using iterative logic, as described above with respect to block 308 of process 300. The logic template code may be non-executable code, and may be used together with variable template code as part of a single reusable code for a set of projects.

[0057] In block 516, process 500 includes storing specific portions of multiple logic segments within a logic metadata table. The logic metadata table may be defined to allow logic template code to dynamically recreate logic sections using the fields in the logic metadata table. Furthermore, a single codebase may be used to insert, update, and delete specific portions of multiple logic segments within the logic metadata table. The single codebase may be used for initial data entry and ongoing data maintenance, and may be executed whenever logic for any logic metadata is created, modified, or deleted. For example, blocks 510 and 516 may be iterated each time a new project is added to the set of projects, and blocks 512, 514, and 516 may be validated for each new code project to ensure that process 500 continues to function for the new project.

[0058] Referring to blocks 518-524, process 500 includes generating and executing executable code for a particular project. In some examples, blocks 518-524 may be executed whenever the process is run to add data to a particular project (e.g., every hour, every day). In block 518, process 500 includes identifying tasks for implementing a particular project. Identifying tasks for implementation makes it possible to identify project variables and project logic segments for implementation by a single available code for a set of projects.

[0059] In block 520, process 500 includes populating project variables for project tasks using variable template code. For example, variable template code can dynamically recreate variable definitions used in a single reusable code using a variable metadata table.

[0060] In block 522, process 500 includes populating the logic segments of the project's tasks with data using logic template code. For example, logic template code can dynamically recreate logic segments used in a single reusable code using a logic metadata table.

[0061] In block 524, process 500 includes generating project output using a single reusable code for a set of projects that are populated by project variables and project logic segments generated in blocks 520 and 522. The output may be stored in a table or a file. In some examples, the output is a specific data extract defined by a particular project. In some examples, a wrapper program can be created to enable the execution of 1 to n unique data extracts at a given point in time using a variable metadata table, a logic metadata table, and a single reusable code.

[0062] While processes 200, 300, 400, and 500 are presented in relation to a clinical setting (e.g., ordering and consultation), processes 200, 300, 400, and 500 are not limited to use in the medical or healthcare administration fields. For example, these techniques can be applied to other contexts, such as processes for collecting and processing information from various sources.

[0063] Any codebase having multiple unique code projects that perform the same overall functionality at a very high level may implement the techniques described herein. For example, this methodology may be used to insert data into a particular table 102. If there are thousands of tables 102 that can receive data from data insertions, there may be thousands of individual code projects that perform unique data insertions into these tables 102, since the insertion logic for each table may be unique due to differences in the data and logic within the table. The generic portion of the insertion may be drawn into a single codebase, and the unique logic (i.e., variables and operational logic) for each table insertion may be stored in one or more metadata tables. The unique logic may be invoked by the single codebase to perform the unique data insertion. Additionally, if at some point in the future an extension is discovered that more efficiently populates a portion of the generic table, that change can be implemented by making a single code change in the single codebase, as opposed to applying the code change to each of the thousands of individual code projects.

[0064] An additional example may include a methodology for deleting data from a specific table. If there are thousands of tables 102 from which data can be deleted, there could be thousands of individual code projects that perform these unique deletions from tables 102, since the deletion logic for each table may be unique due to the uniqueness of the data and logic within the table. The general part of the deletion can be drawn into a single codebase, and the unique logic (i.e., variables and operational logic) for each table deletion can be stored in one or more metadata tables. The unique logic can be invoked by the single codebase to perform the unique deletion of data. Additionally, if a defect is discovered in the code at some point in the future, the correction can be performed by making a single code change in the single codebase, as opposed to applying the code change to each of the thousands of individual code projects.

[0065] The process may also be applied to assembly lines within a manufacturing process, such as in an automobile factory. An assembly line may have common repeatable processes (e.g., loading raw materials, having a robot perform function n, verifying function n, repeating as desired, performing a final overall verification, and removing the finished product from the assembly line). Additionally, an assembly line may include parts specific to a given embodiment. For example, the repeatable process parts may vary depending on whether the assembly line manufactures trucks or compact cars. Thus, the process described herein may simplify the reusability of repeatable processes in an assembly line across the assembly of multiple different products.

[0066] Furthermore, the process may include an application that collects data entries. There may be very common, repeatable processes associated with collecting data entries (e.g., defining the areas from which data will be collected, defining the fields from which data will be collected, validating the data, collecting the data, storing the data, etc.). Additionally, data collection may also include sections that are highly specific to a given embodiment (e.g., collecting data about a phone book, collecting data about customers, collecting data about sales opportunities, collecting data about medical records, collecting data about sales orders, etc.). Each area may collect very different and specific data within different tables and fields, but the overall steps may be general and repeatable at a high level of abstraction. Thus, the processes described herein may simplify the reusability of the general and repeatable logic of the data collection process.

[0067] Figure 6 shows a simplified diagram of a distributed system 600 for carrying out one embodiment. In the illustrated embodiment, the distributed system 600 includes one or more client computing devices 602, 604, 606, and 608 coupled to a server 612 via one or more communication networks 610. The client computing devices 602, 604, 606, and 608 can be configured to run one or more applications.

[0068] In various embodiments, the server 612 can be adapted to run one or more services or software applications that enable techniques for processing long texts for pre-trained language models.

[0069] In some embodiments, server 612 may also provide other services or software applications, including non-virtual and virtual environments. In some embodiments, these services may be provided to users of client computing devices 602, 604, 606, and / or 608 as web-based or cloud services based on a software-as-a-service (SaaS) model, for example. Users operating client computing devices 602, 604, 606, and / or 608 can then use one or more client applications to interact with server 612 and utilize the services provided by these components.

[0070] In the configuration shown in Figure 6, server 612 may include one or more components 618, 620, and 622 that implement the functions performed by server 612. These components may include one or more processors, hardware components, or software components that may be executed by a combination thereof. It should be understood that various different system configurations are possible, which may differ from distributed system 600. Therefore, the embodiment shown in Figure 6 is an example of a distributed system for running one embodiment of the system, and is not intended to be limiting.

[0071] A user may use client computing devices 602, 604, 606, and / or 608 for the techniques for processing long texts for pre-trained language models as taught in this disclosure. The client devices may provide an interface that allows a user of the client device to interact with the client device. The client devices may also output information to the user through this interface. Figure 6 shows only four client computing devices, but any number of client computing devices may be supported.

[0072] Client devices may include various types of computing systems, such as portable handheld devices, general-purpose computers such as personal computers and laptops, workstation computers, wearable devices, gaming systems, thin clients, various messaging devices, sensors or other sensing devices. These computing devices can run various types and versions of software applications and operating systems (e.g., Microsoft Windows®, Apple Macintosh®, UNIX® or UNIX-like operating systems, Linux® or Linux-like operating systems such as Google Chrome® OS), including various mobile operating systems (e.g., Microsoft Windows Mobile®, iOS®, Windows Phone®, Android®, BlackBerry®, Palm OS®). Portable handheld devices may include mobile phones, smartphones (e.g., iPhone®), tablets (e.g., iPad®), personal digital assistants (PDAs), etc. Wearable devices may include Google Glass® head-mounted displays and other devices. The gaming system may include various handheld gaming devices, internet-enabled gaming devices (e.g., Microsoft Xbox® gaming consoles with or without Kinect® gesture input devices, Sony PlayStation® systems, various gaming systems provided by Nintendo®, etc.). Client devices may be capable of running various different applications, such as various internet-related applications and communication applications (e.g., email applications, short message service (SMS) applications), and may use various communication protocols.

[0073] Network 610 may be any type of network familiar to those skilled in the art, capable of supporting data communication using any of the various available protocols, including but not limited to TCP / IP (Transmission Control Protocol / Internet Protocol), SNA (System Network Architecture), IPX (Internet Packet Switching), AppleTalk®, etc. For example only, Network 610 may be a local area network (LAN), an Ethernet-based network, Token-Ring, a wide area network (WAN), the Internet, a virtual network, a virtual private network (VPN), an intranet, an extranet, a public switched telephone network (PSTN), an infrared network, a wireless network (e.g., a network operating on any of the Institute of Electrical and Electronics Engineers (IEEE) 1002.11 protocol suites, Bluetooth®, and / or any other wireless protocol), and / or any combination of these and / or other networks.

[0074] Server 612 may consist of one or more general-purpose computers, specialized server computers (including, for example, PC (personal computer) servers, UNIX® servers, midrange servers, mainframe computers, rack-mount servers, etc.), server farms, server clusters, or any other suitable configuration and / or combination. Server 612 may include one or more virtual machines running a virtual operating system, or other computing architectures with virtualization, such as one or more pools of flexible logical storage devices that can be virtualized to maintain virtual storage devices for the server. In various embodiments, Server 612 can be adapted to run one or more services or software applications that provide the functions described above.

[0075] The computing system within server 612 may run one or more operating systems, including any of the above-mentioned ones and any commercially available server operating system. Server 612 may also run any of a variety of additional server applications and / or middle-tier applications, including HTTP (Hypertext Transfer Protocol) servers, FTP (File Transfer Protocol) servers, CGI (Common Gateway Interface) servers, Java® servers, database servers, etc. Exemplary database servers include, but are not limited to, those commercially available from Oracle®, Microsoft®, Sybase®, IBM® (International Business Machines), and others.

[0076] In some embodiments, server 612 may include one or more applications for analyzing and integrating data feeds and / or event updates received from users of client computing devices 602, 604, 606, and 608. For example, data feeds and / or event updates may include, but are not limited to, real-time updates received from one or more third-party sources and continuous data streams, including Twitter® feeds, Facebook® updates, or real-time events relating to sensor data applications, financial tickers, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, and automotive traffic monitoring. Server 612 may also include one or more applications for displaying data feeds and / or real-time events via one or more display devices of client computing devices 602, 604, 606, and 608.

[0077] The distributed system 600 may also include one or more data repositories 614, 616. These data repositories can be used in some embodiments to store data and other information. For example, one or more of the data repositories 614, 616 may be used to store information about techniques for processing long texts for a pre-trained language model (e.g., intent scores, overall scores). The data repositories 614, 616 may reside in various locations. For example, a data repository used by server 612 may be local to server 612, or it may be remote from server 612 and communicate with server 612 via a network-based or dedicated connection. The data repositories 614, 616 may be of different types. In some embodiments, a data repository used by server 612 may be a database, such as a relational database, provided by Oracle Corporation® and other suppliers. One or more of these databases may be adapted to enable the storage, updating, and retrieval of data that interacts with the database in response to commands in Structured Query Language (SQL) format.

[0078] In one embodiment, one or more of the data repositories 614, 616 may also be used by the application to store application data. The data repositories used by the application may be of various types, such as a key-value store repository, an object store repository, or a general storage repository supported by a file system.

[0079] In one embodiment, the techniques for processing long texts for the pre-trained language model functionality described in this disclosure may be provided as a service via a cloud environment. Figure 7 is a simplified block diagram of a cloud-based system environment 700 that, in one embodiment, can provide various text processing-related services as cloud services. In the embodiment shown in Figure 7, the cloud infrastructure system 702 can provide one or more cloud services that may be requested by a user using one or more client computing devices 704, 706, and 708. The cloud infrastructure system 702 may comprise one or more computers and / or servers, which may include those described above for server 612. The computers within the cloud infrastructure system 702 may be organized as general-purpose computers, specialized server computers, server farms, server clusters, or any other suitable configuration and / or combination.

[0080] Network 710 can facilitate communication and data exchange between clients 704, 706, and 708 and the cloud infrastructure system 702. Network 710 may include one or more networks. The networks may be the same or different types. Network 710 may support one or more communication protocols, including wired and / or wireless protocols, to facilitate communication.

[0081] The embodiment shown in Figure 7 is merely one example of a cloud infrastructure system and is not intended to be limiting. It should be understood that in several other embodiments, the cloud infrastructure system 702 may have more or fewer components than those shown in Figure 7, may combine two or more components, or may have different configurations or arrangements of components. For example, while Figure 7 shows three client computing devices, in alternative embodiments, any number of client computing devices may be supported.

[0082] The term "cloud service" is generally used to refer to services that are made available to users on demand and via communication networks such as the Internet by a service provider's system (e.g., cloud infrastructure system 702). Typically, in a public cloud environment, the servers and systems that make up the cloud service provider's system are different from the customer's own on-premises servers and systems. The cloud service provider's system is managed by the cloud service provider. Therefore, customers can use the cloud services provided by the cloud service provider without having to purchase separate licenses, support, or hardware and software resources for the service. For example, the cloud service provider's system may host applications, and users can order and use those applications via the network 710 (e.g., the Internet) as needed, without having to purchase infrastructure resources for the user to run the applications. Cloud services are designed to provide easy and scalable access to applications, resources, and services. Several providers offer cloud services. For example, several cloud services such as middleware services, database services, and Java Cloud Service are offered by Oracle Corporation®, located in Redwood Shores, California.

[0083] In one embodiment, the cloud infrastructure system 702 can provide one or more cloud services using various models, including a hybrid service model, such as a software-as-a-service (SaaS) model, a platform-as-a-service (PaaS) model, or an infrastructure-as-a-service (IaaS) model. The cloud infrastructure system 702 may also include a set of applications, middleware, databases, and other resources that enable the provision of various cloud services.

[0084] The SaaS model allows applications or software to be delivered to customers as a service over a communication network such as the internet, without the customer needing to purchase hardware or software for the underlying application. For example, the SaaS model can be used to provide customers with access to on-demand applications hosted by a cloud infrastructure system. Examples of SaaS services offered by Oracle Corporation® include, but are not limited to, a variety of services for human resource / capital management, customer relationship management (CRM), enterprise resource planning (ERP), supply chain management (SCM), enterprise performance management (EPM), analytics services, and social applications.

[0085] The IaaS model is generally used to provide customers with infrastructure resources (e.g., servers, storage, hardware, and networking resources) as cloud services to offer flexible computing and storage capabilities. Various IaaS services are offered by Oracle Corporation®.

[0086] The PaaS model is generally used to provide platform and environment resources as a service, enabling customers to develop, run, and manage applications and services without having to acquire, build, or maintain such resources themselves. Examples of PaaS services offered by Oracle Corporation® include, but are not limited to, Oracle Java Cloud Service (JCS), Oracle Database Cloud Service (DBCS), data management cloud services, and various application development solution services.

[0087] Cloud services are generally provided in an on-demand, self-service manner, on a subscription basis, flexibly scalable, highly reliable, highly available, and secure manner. For example, a customer can order one or more services provided by the cloud infrastructure system 702 through a subscription order. The cloud infrastructure system 702 then performs the processing to provide the services requested in the customer's subscription order. The cloud infrastructure system 702 can be configured to provide one or more cloud services.

[0088] The cloud infrastructure system 702 can provide cloud services through several different deployment models. In the public cloud model, the cloud infrastructure system 702 may be owned by a third-party cloud service provider, and the cloud services may be provided to any public customer, where the customer may be an individual or a company. In another embodiment, under the private cloud model, the cloud infrastructure system 702 may be operated within an organization (e.g., within a corporate organization), and the services may be provided to customers within the organization. For example, the customers may be various departments of a company, such as the human resources department or payroll department, or even individuals within the company. In yet another embodiment, under the community cloud model, the cloud infrastructure system 702 and the services provided may be shared by several organizations within a relevant community. Various other models, such as hybrids of the models described above, may also be used.

[0089] The client computing devices 704, 706, and 708 may be of different types (for example, devices 602, 604, 606, and 608 shown in Figure 6) and may be capable of running one or more client applications. Users can use the client devices to interact with the cloud infrastructure system 702, for example, to request services provided by the cloud infrastructure system 702. For example, a user can use the client devices to request a chatbot service such as the one described in this disclosure.

[0090] In some embodiments, processing performed by the cloud infrastructure system 702 to provide the Chabot service may involve big data analytics. This analytics may involve using, analyzing, and manipulating large datasets to detect and visualize various trends, behaviors, relationships, etc., within the data. This analytics may be performed by one or more processors, which may, in some cases, process the data in parallel, perform simulations using the data, etc. For example, big data analytics may be performed by the cloud infrastructure system 702 to determine the intent of an utterance. The data used in this analytics may include structured data (e.g., data stored in a database or structured according to a structured model) and / or unstructured data (e.g., data blobs (binary large objects)).

[0091] As shown in the embodiment of Figure 7, the cloud infrastructure system 702 may include infrastructure resources 730 used to facilitate the provision of various cloud services supplied by the cloud infrastructure system 702. The infrastructure resources 730 may include, for example, processing resources, storage or memory resources, networking resources, etc.

[0092] In one embodiment, to facilitate the efficient provision of these resources to support various cloud services provided by the cloud infrastructure system 702 to different customers, resources can be bundled into sets of resources or resource modules (also referred to as "pods"). Each resource module or pod may contain a pre-integrated and optimized combination of one or more types of resources. In one embodiment, different pods may be pre-provided for different types of cloud services. For example, a first set of pods may be provided for database services, and a second set of pods may be provided for Java services, which may contain a different combination of resources than the pods in the first set of pods. For some services, the resources allocated to provide the services may be shared among the services.

[0093] The cloud infrastructure system 702 can internally use services 732 that are shared by different components of the cloud infrastructure system 702 and facilitate the provision of services by the cloud infrastructure system 702. These internally shared services may include, but are not limited to, security and identity services, integration services, enterprise repository services, enterprise manager services, virus scanning and whitelisting services, high availability, backup and restore services, services to enable cloud support, email services, notification services, and file transfer services.

[0094] The cloud infrastructure system 702 may include multiple subsystems. These subsystems may be implemented in software, hardware, or a combination thereof. As shown in Figure 7, the subsystem may include a user interface subsystem 712 that enables users or customers of the cloud infrastructure system 702 to interact with the cloud infrastructure system 702. The user interface subsystem 712 may include a variety of different interfaces, such as a web interface 714, an online store interface 716 where cloud services provided by the cloud infrastructure system 702 are advertised and available for purchase by consumers, and other interfaces 718. For example, a customer may use a client device to request one or more services provided by the cloud infrastructure system 702 using one or more of interfaces 714, 716, and 718 (service request 734). For example, a customer may access the online store, browse the cloud services provided by the cloud infrastructure system 702, and place a subscription order for one or more services provided by the cloud infrastructure system 702 that the customer wishes to subscribe to. The service request may include information identifying the customer and one or more services that the customer wishes to subscribe to. For example, a customer can place a subscription order for chatbot-related services provided by the cloud infrastructure system 702. As part of the order, the customer can provide information that identifies the input (e.g., speech).

[0095] In one embodiment, such as the embodiment shown in Figure 7, the cloud infrastructure system 702 may include an Order Management Subsystem (OMS) 720 configured to process new orders. As part of this process, the OMS 720 may be configured to create a customer account if not already done, receive billing and / or accounting information from the customer which will be used to bill the customer for providing the requested services, match the customer information, register the customer's order, and coordinate various workflows to prepare the order for delivery.

[0096] If properly validated, the OMS720 can then invoke the Order Delivery Subsystem (OPS)724, which is configured to provide resources for the order, including processing, memory, and networking resources. The provision may include allocating resources for the order and configuring those resources to facilitate the services requested by the customer order. The manner in which resources are provided for the order, and the types of resources provided, may depend on the type of cloud service ordered by the customer. For example, following one workflow, the OPS724 may be configured to determine a specific cloud service being requested and identify the number of pods that may be pre-configured for that specific cloud service. The number of pods allocated to the order may depend on the size / volume / level / scope of the requested service. For example, the number of pods allocated may be determined based on the number of users the service will support, the duration for which the service is requested, etc. The allocated pods may then be customized to provide the requested service for a particular requesting customer.

[0097] The cloud infrastructure system 702 may send a response or notification 744 to the requesting customer indicating when the requested service is ready for use. In some cases, the system may send information (e.g., a link) to the customer that enables the customer to begin using the requested service and taking advantage of its benefits.

[0098] The cloud infrastructure system 702 can provide services to multiple customers. For each customer, the cloud infrastructure system 702 is responsible for managing information related to one or more subscription orders received from the customer, maintaining customer data related to the orders, and providing the requested services to the customer. The cloud infrastructure system 702 can also collect usage statistics about the customer's use of the subscribed services. For example, statistics may be collected on the amount of storage used, the amount of data transferred, the number of users, and the amount of system uptime and system downtime. This usage information can be used to bill the customer. Billing may be done, for example, on a monthly cycle.

[0099] The cloud infrastructure system 702 can provide services to multiple customers in parallel. The cloud infrastructure system 702 can store information about these customers, which may include sensitive information. In one embodiment, the cloud infrastructure system 702 includes an Identity Management Subsystem (IMS) 728 configured to manage customer information and provide isolation of managed information so that information related to one customer is not accessible to another customer. The IMS 728 can be configured to provide a variety of security-related services, such as identity services, including information access management, authentication and authorization services, services for managing customer identity and roles, and related functions.

[0100] Figure 8 shows an exemplary computer system 800 that can be used to carry out a certain embodiment. For example, in some embodiments, the computer system 800 may be used to implement any operation and function of the process 400 for processing long texts for a pre-trained language model as shown in Figure 4, as well as the various servers and computer systems described above. As shown in Figure 8, the computer system 800 includes various subsystems, including a processing subsystem 804 that communicates with several other subsystems via a bus subsystem 802. These other subsystems may include a processing acceleration unit 806, an I / O subsystem 808, a storage subsystem 818, and a communication subsystem 824. The storage subsystem 818 may include a non-temporary computer-readable storage medium including a storage medium 822 and system memory 810.

[0101] The bus subsystem 802 provides a mechanism for various components and subsystems of the computer system 800 to communicate with each other as intended. Although the bus subsystem 802 is schematically shown as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. The bus subsystem 802 may be any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, and a local bus using any of various bus architectures. For example, such architectures may include industry standard architecture (ISA) buses, microchannel architecture (MCA) buses, extended ISA (EISA) buses, video electronic equipment standardization society (VESA) local buses, and peripheral component interconnect (PCI) buses, which can be implemented as Mezzanine buses manufactured according to the IEEE P1386.1 standard.

[0102] The processing subsystem 804 controls the operation of the computer system 800 and may include one or more processors, application-specific integrated circuits (ASICs), or field-programmable gate arrays (FPGAs). The processors may be single-core or multi-core processors. The processing resources of the computer system 800 can be organized into one or more processing units 832, 834, etc. A processing unit may include one or more processors, one or more cores from the same or different processors, a combination of cores and processors, or other combinations of cores and processors. In some embodiments, the processing subsystem 804 may include one or more dedicated coprocessors, such as graphics processors, digital signal processors (DSPs), etc. In some embodiments, some or all of the processing units of the processing subsystem 804 may be implemented using custom circuitry, such as application-specific integrated circuits (ASICs) or field-programmable gate arrays (FPGAs).

[0103] In some embodiments, processing units within the processing subsystem 804 can execute instructions stored in system memory 810 or on computer-readable storage medium 822. In various embodiments, processing units can execute various program or code instructions and maintain multiple concurrently running programs or processes. At any given time, some or all of the program code to be executed may reside in system memory 810 and / or possibly on computer-readable storage medium 822, which may include one or more storage devices. Through appropriate programming, the processing subsystem 804 can provide the various functions described above. In cases where computer system 800 is running one or more virtual machines, one or more processing units can be assigned to each virtual machine.

[0104] In one embodiment, the processing acceleration unit 806 may optionally be provided to perform customized processing or to offload a portion of the processing performed by the processing subsystem 804 to accelerate the overall processing performed by the computer system 800.

[0105] The I / O subsystem 808 may include devices and mechanisms for inputting information into and / or outputting information from or through the computer system 800. Generally, the use of the term input device is intended to include all possible types of devices and mechanisms for inputting information into the computer system 800. User interface input devices may include, for example, pointing devices such as keyboards, mice or trackballs, touchpads or touchscreens integrated into displays, scroll wheels, click wheels, dials, buttons, switches, keypads, acoustic input devices with voice command recognition systems, microphones, and other types of input devices. User interface input devices may also include motion sensing and / or gesture recognition devices such as Microsoft Kinect® motion sensors, Microsoft Xbox® 360 game controllers, and devices that provide interfaces for receiving input using gesture and voice commands, enabling users to control and interact with the input devices. The user interface input device may also include an eye gesture recognition device, such as the Google Glass® blink detector, which detects eye activity from the user (e.g., blinking while taking a picture and / or making a menu selection) and translates that eye gesture into input to an input device (e.g., Google Glass®). Additionally, the user interface input device may include a voice recognition detection device that enables the user to interact with a voice recognition system (e.g., Siri® Navigator) through voice commands.

[0106] Other examples of user interface input devices include, but are not limited to, three-dimensional (3D) mice, joysticks or pointing sticks, gamepads and graphic tablets, as well as acoustic / visual devices such as speakers, digital cameras, digital camcorders, portable media players, webcams, image scanners, fingerprint scanners, barcode readers, 3D scanners, 3D printers, laser rangefinders, and eye-tracking devices. Additionally, user interface input devices may also include medical imaging input devices such as computed tomography, magnetic resonance imaging, position emission tomography, and medical ultrasound devices. User interface input devices may also include acoustic input devices such as MIDI keyboards and digital musical instruments.

[0107] Generally, the use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from the computer system 800 to a user or another computer. User interface output devices may include non-visual displays such as display subsystems, indicator lights, or acoustic output devices. Display subsystems may include flat panel devices such as those using cathode ray tubes (CRTs), liquid crystal displays (LCDs), or plasma displays, projection devices, touchscreens, etc. For example, user interface output devices may include, but are not limited to, a variety of display devices that visually convey text, graphic, and acoustic / video information, such as monitors, printers, speakers, headphones, car navigation systems, plotters, audio output devices, and modems.

[0108] The storage subsystem 818 provides a repository or data store for storing information and data used by the computer system 800. The storage subsystem 818 provides a tangible, non-temporary, computer-readable storage medium for storing basic programming and data structures that provide several embodiments of functionality. The storage subsystem 818 can store software (e.g., programs, code modules, instructions) that, when executed by the processing subsystem 804, provides the functions described above. The software may be executed by one or more processing units of the processing subsystem 804. The storage subsystem 818 can also provide a repository for storing data used in accordance with the teachings of this disclosure.

[0109] The storage subsystem 818 may include one or more non-temporary memory devices, including volatile and non-volatile memory devices. As shown in Figure 8, the storage subsystem 818 includes system memory 810 and computer-readable storage medium 822. The system memory 810 may include several memories, including volatile main random access memory (RAM) for storing instructions and data during program execution, and non-volatile read-only memory (ROM) or flash memory for storing fixed instructions. In some embodiments, a basic input / output system (BIOS) containing basic routines that help transfer information between elements within the computer system 800, such as during startup, may typically be stored in ROM. The RAM typically contains data and / or program modules currently operating and being executed by the processing subsystem 804. In some embodiments, the system memory 810 may include several different types of memory, such as static random access memory (SRAM) and dynamic random access memory (DRAM).

[0110] As an example, and not an limitation, as shown in Figure 8, the system memory 810 may load running application programs 812, program data 814, and operating system 816, which may include various applications such as web browsers, middle-tier applications, and relational database management systems (RDBMS). For example, the operating system 816 may include various versions of Microsoft Windows®, Apple Macintosh®, and / or Linux operating systems, various commercially available UNIX® or UNIX-like operating systems (including, but not limited to, various GNU / Linux operating systems, Google Chrome® OS, etc.), and / or mobile operating systems such as iOS, Windows® Phone, Android® OS, BlackBerry® OS, and Palm® OS.

[0111] The computer-readable storage medium 822 can store programming and data structures that provide several embodiments of functionality. The computer-readable storage medium 822 can provide the computer system 800 with storage of computer-readable instructions, data structures, program modules, and other data. Software (programs, code modules, instructions) that, when executed by the processing subsystem 804, provides the above-described functionality may be stored in the storage subsystem 818. For example, the computer-readable storage medium 822 may include non-volatile memory such as a hard disk drive, magnetic disk drive, CD-ROM, digital video disc (DVD), Blu-ray® disc, or other optical media. The computer-readable storage medium 822 may also include, but is not limited to, a Zip® drive, flash memory card, Universal Serial Bus (USB) flash drive, Secure Digital (SD) card, DVD disc, digital videotape, and the like. Computer-readable storage media 822 may also include SSDs based on non-volatile memory such as flash memory-based solid-state drives, enterprise flash drives, and solid-state ROM; SSDs based on volatile memory such as solid-state RAM, dynamic RAM, static RAM, dynamic random-access memory (DRAM)-based SSDs, and magnetoresistive RAM (MRAM) SSDs; and hybrid SSDs that use a combination of DRAM and flash memory-based SSDs.

[0112] In one embodiment, the storage subsystem 818 may also include a computer-readable storage medium reader 820 which can be further connected to a computer-readable storage medium 822. The reader 820 can receive data from a memory device such as a disk or flash drive and can be configured to read such data.

[0113] In one embodiment, the computer system 800 may support virtualization technologies, including, but not limited to, virtualization of processing and memory resources. For example, the computer system 800 may provide support for running one or more virtual machines. In one embodiment, the computer system 800 may run programs such as hypervisors that facilitate the configuration and management of virtual machines. Each virtual machine may be allocated memory resources, computing resources (e.g., processors, cores), I / O resources, and networking resources. Each virtual machine generally operates independently of other virtual machines. A virtual machine typically runs its own operating system, which may be the same as, or different from, the operating system run by other virtual machines run by the computer system 800. Thus, multiple operating systems may potentially run simultaneously by the computer system 800.

[0114] The communication subsystem 824 provides interfaces to other computer systems and networks. It acts as an interface for receiving data from other systems and transmitting data from computer system 800 to other systems. For example, the communication subsystem 824 can enable computer system 800 to establish communication channels to one or more client devices over the internet to interact with client devices and receive and transmit information. For instance, the communication subsystem may be used to send responses to a user regarding a question directed to a chatbot.

[0115] The communication subsystem 824 can support both wired and / or wireless communication protocols. For example, in one embodiment, the communication subsystem 824 may include radio frequency (RF) transceiver components for accessing wireless voice and / or data networks (e.g., using cellular technology, 3G, 4G or EDGE (Global Evolutionary High Speed ​​Data Rate), Wi-Fi (IEEE 802.XX family standards, or other advanced data network technologies such as other mobile communication technologies, or any combination thereof), a Global Positioning System (GPS) receiver component, and / or other components. In some embodiments, the communication subsystem 824 may provide a wired network connection (e.g., Ethernet) in addition to or instead of a wireless interface.

[0116] The communication subsystem 824 can receive and transmit data in various formats. For example, in some embodiments, in addition to other formats, the communication subsystem 824 can receive input communications in the form of structured and / or unstructured data feeds 826, event streams 828, event updates 830, etc. For example, the communication subsystem 824 can be configured to receive (or transmit) data feeds 826 in real time from users of social media networks and / or other communication services, such as web feeds like Twitter® feeds, Facebook® updates, rich site summary (RSS) feeds, and / or real-time updates from one or more third-party sources.

[0117] In one embodiment, the communication subsystem 824 may be configured to receive data in the form of a continuous data stream, which may include an event stream 828 and / or event update 830 of real-time events that are continuous or unlimited and essentially have no clear end. Examples of applications that generate continuous data may include, for example, sensor data applications, financial tickers, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, and automotive traffic monitoring.

[0118] The communication subsystem 824 can also be configured to communicate data from the computer system 800 to other computer systems or networks. The data can be communicated in various different forms, such as structured and / or unstructured data feeds 826, event streams 828, event updates 830, etc., to one or more databases that can communicate with one or more streaming data source computers connected to the computer system 800.

[0119] The computer system 800 can be one of a variety of types, including handheld portable devices (e.g., iPhone® mobile phones, iPad® computing tablets, personal data assistants (PDAs)), wearable devices (e.g., Google Glass® head-mounted displays), personal computers, workstations, mainframes, kiosks, server racks, or any other data processing systems. Due to the constantly changing nature of computers and networks, the description of the computer system 800 shown in Figure 8 is intended only as a specific example. Many other configurations are possible, having more or fewer components than the system shown in Figure 8. Based on this disclosure and the teachings provided herein, those skilled in the art will understand other forms and / or methods for implementing various embodiments.

[0120] While specific embodiments have been described, various modifications, alterations, alternative configurations, and equivalents are possible. The embodiments are not limited to operation within a particular data processing environment, but can freely operate within multiple data processing environments. Additionally, while some embodiments are described using a specific sequence of transactions and steps, those skilled in the art will understand that this is not intended to be limiting. While some flowcharts describe operations as sequential processes, many operations can be performed in parallel or simultaneously. Furthermore, the order of operations may be reconfigured. Processes may have additional steps not included in the drawings. Various features and embodiments of the embodiments described above may be used individually or in conjunction.

[0121] Furthermore, while some embodiments are described using specific combinations of hardware and software, it should be recognized that other combinations of hardware and software are also possible. Some embodiments may be implemented using hardware only, software only, or a combination thereof. The various processes described herein may be implemented on the same processor or on multiple different processors in any combination.

[0122] Where a device, system, component, or module is described as being configured to perform a certain operation or function, such configuration can be achieved, for example, by designing electronic circuits to perform an operation, by programming programmable electronic circuits (such as a microprocessor) to perform an operation by executing computer instructions or code, or by a processor or core, or any combination thereof, programmed to execute code or instructions stored on a non-temporary memory medium. Processes can communicate using a variety of techniques, including, but not limited to, conventional techniques for inter-process communication, and different pairs of processes may use different techniques, or the same pair of processes may use different techniques at different points in time.

[0123] Certain details are given in this disclosure to provide a thorough understanding of the embodiments. However, the embodiments can be practiced without these specific details. For example, well-known circuits, processes, algorithms, structures, and techniques are shown without unnecessary details to avoid obscuring the embodiments. This description provides only exemplary embodiments and is not intended to limit the scope, applicability, or configuration of other embodiments. Rather, the preceding descriptions of embodiments provide explanations that enable various embodiments to be practiced. Various modifications can be made to the function and configuration of the elements.

[0124] Therefore, this specification and the drawings should be considered in an illustrative rather than restrictive sense. However, it will be apparent that additions, subtractions, deletions, and other modifications and alterations can be made thereto without departing from the broader intent and scope set forth in the claims. Thus, while certain embodiments are described, they are not intended to be restrictive. Various modifications and equivalents are within the scope of the appended claims.

Claims

1. A method carried out by one or more processors, This involves generating a non-executable code template that includes code defining a set of behaviors, Accessing data related to a specific project, Determining a set of project variables related to the aforementioned specific project, Determining the set of project logic related to the aforementioned specific project, The process involves integrating the set of project variables and the set of project logic into the non-executable code template to generate executable code. Compiling the aforementioned executable code, A method comprising generating a result by executing the compiled executable code.

2. The aforementioned method, Further includes identifying a set of operation variables associated with the set of operations, The set of operation variables includes the set of project variables, The aforementioned method, For each operating variable in the set of operating variables, identify the unique variable logic that determines the value of the operating variable. The method further includes generating a variable metadata table which includes a set of variable fields associated with the unique variable logic of each of the set of operation variables, The method according to claim 1, wherein the set of project variables related to the particular project is accessed using the variable metadata table.

3. The aforementioned method, Further includes identifying a set of operational logic related to the set of operations, The set of operational logic includes the set of project logic, The aforementioned method, For each operational logic action in the set of operational logic, identify the unique project logic that determines the value of the operational logic action. The method further includes generating a logic metadata table which includes a set of variable fields associated with the specific project logic of each operational logic action in the set of operational logic, The method according to claim 2, wherein the set of project logic associated with the particular project is accessed using the logic metadata table.

4. This involves defining unique code for populating a set of variable metadata tables and a set of extracted metadata tables with variable metadata and extracted metadata, The method according to claim 1, further comprising creating a subprogram of the specific code for inserting, updating, or deleting the variable metadata in the variable metadata table and the extracted metadata in the extracted metadata table.

5. The method according to claim 1, wherein the particular project includes extraction from at least two clinical tables associated with a certain entity.

6. The method according to claim 1, wherein at least a portion of the set of project variables includes a set of dynamic values, the set of dynamic values ​​is accessed at the time of compilation of the executable code or at the time of execution of the executable code.

7. The aforementioned method, Further includes generating a wrapper program for simultaneously running the aforementioned specific project and several additional projects of the aforementioned set of operations, The method according to claim 1, wherein generating the results includes simultaneously generating the results for the specific project and a plurality of additional results for a plurality of additional projects.

8. It is a system, One or more processors, The system comprises a memory connected to one or more processors, The memory stores a plurality of instructions that can be executed by the one or more processors, and when the plurality of instructions are executed by the one or more processors, it causes the one or more processors to perform an operation. The aforementioned operation is, This involves generating a non-executable code template that includes code defining a set of behaviors, Accessing data related to a specific project, Determining a set of project variables related to the aforementioned specific project, Determining the set of project logic related to the aforementioned specific project, The process involves integrating the set of project variables and the set of project logic into the non-executable code template to generate executable code. Compiling the aforementioned executable code, A system that includes generating results by executing the aforementioned compiled executable code.

9. The aforementioned operation is, Further includes identifying a set of operation variables associated with the set of operations, The set of operation variables includes the set of project variables, The aforementioned operation is, For each operating variable in the set of operating variables, identify the unique variable logic that determines the value of the operating variable. The method further includes generating a variable metadata table which includes a set of variable fields associated with the unique variable logic of each of the set of operation variables, The system according to claim 8, wherein the set of project variables related to the particular project is accessed using the variable metadata table.

10. The aforementioned operation is, Further includes identifying a set of operational logic related to the set of operations, The set of operational logic includes the set of project logic, The aforementioned operation is, For each operational logic action in the set of operational logic, identify the unique project logic that determines the value of the operational logic action. The method further includes generating a logic metadata table which includes a set of variable fields associated with the specific project logic of each operational logic action in the set of operational logic, The system according to claim 9, wherein the set of project logic related to the particular project is accessed using the logic metadata table.

11. The system according to claim 8, wherein the non-executable code template includes variable template code and logic template code, the variable template code includes common variable logic applicable to all projects in the set of operations, and the logic template code includes common operation logic applicable to all projects in the set of operations.

12. The system according to claim 8, wherein at least a portion of the set of project variables includes a set of dynamic values, the set of dynamic values ​​being accessed at the time of compilation of the executable code or at the time of execution of the executable code.

13. The aforementioned operation is, Further includes generating a wrapper program for simultaneously running the aforementioned specific project and several additional projects of the aforementioned set of operations, The system according to claim 8, wherein generating the results includes simultaneously generating the results for the specific project and a plurality of additional results for a plurality of additional projects.

14. The system according to claim 8, wherein the particular project includes extraction from at least two clinical tables associated with a certain entity.

15. A non-temporary computer-readable medium storing a plurality of instructions that can be executed by one or more processors, wherein the plurality of instructions cause the one or more processors to perform an operation. The aforementioned operation is, This involves generating a non-executable code template that includes code defining a set of behaviors, Accessing data related to a specific project, Determining a set of project variables related to the aforementioned specific project, Determining the set of project logic related to the aforementioned specific project, The process involves integrating the set of project variables and the set of project logic into the non-executable code template to generate executable code. Compiling the aforementioned executable code, A non-temporary computer-readable medium, which includes generating results by executing the compiled executable code.

16. The aforementioned operation is, Further includes identifying a set of operation variables associated with the set of operations, The set of operation variables includes the set of project variables, The aforementioned operation is, For each operating variable in the set of operating variables, identify the unique variable logic that determines the value of the operating variable. The method further includes generating a variable metadata table which includes a set of variable fields associated with the unique variable logic of each of the set of operation variables, The set of project variables associated with the particular project is accessed using the variable metadata table, in the non-temporary computer-readable medium according to claim 15.

17. The aforementioned operation is, Further includes identifying a set of operational logic related to the set of operations, The set of operational logic includes the set of project logic, The aforementioned operation is, For each operational logic action in the set of operational logic, identify the unique project logic that determines the value of the operational logic action. The method further includes generating a logic metadata table which includes a set of variable fields associated with the specific project logic of each operational logic action in the set of operational logic, The set of project logic related to the particular project is accessed using the logic metadata table in the non-temporary computer-readable medium according to claim 16.

18. The non-temporary computer-readable medium according to claim 15, wherein the non-executable code template includes variable template code and logic template code, the variable template code includes common variable logic applicable to all projects in the set of operations, and the logic template code includes common operation logic applicable to all projects in the set of operations.

19. The non-temporary computer-readable medium according to claim 15, wherein at least a portion of the set of project variables includes a set of dynamic values, the set of dynamic values ​​being accessed at the time of compilation of the executable code or at the time of execution of the executable code.

20. The aforementioned operation is, Further includes generating a wrapper program for simultaneously running the aforementioned specific project and several additional projects of the aforementioned set of operations, The non-temporary computer-readable medium according to claim 15, wherein generating the results includes simultaneously generating the results for the particular project and a plurality of additional results for a plurality of additional projects.

Images