Title of Invention: PREDICTIVE SYSTEM FOR GENERATING CLINICAL QUERIES Abstract: Methods, systems, and apparatus, including computer programs encoded on a computer storage medium, for generating a predictive system that obtains and processes data describing terms for different medical concepts to generate commands from a user query. An entity module of the system determines whether a term describes a medical entity associated with a healthcare condition affecting an individual. When the term describes the medical entity an encoding module links the medical entity with a specified category based on an encoding scheme. The system receives the user query. A parsing engine of the system uses the received query to generate a machine-readable command by parsing the query against terms that describe the medical entity and based on the encoding scheme for linking the medical entity to the specified category. The system uses the command to query different databases to obtain data for generating a response to the received query. Detailed Description: CROSS-REFERENCE TO RELATED APPLICATIONS This application is a Continuation of U.S. application Ser. No. 16/375,403, filed Apr. 4, 2019, the disclosure of which is incorporated herein by reference. FIELD This specification relates to predictive computing systems. BACKGROUND As part of the healthcare process, physicians or other medical care providers may perform clinical trials, programs, and other activities to evaluate subject safety and efficacy of a pharmaceutical drug or other medical treatment option. The use of health-related trial programs can help to identify novel treatment options for improving overall patient health and reducing health system costs. A clinical trial or program can be a single research study or multiple research studies that prospectively assigns human participants/subjects or groups of human subjects to one or more health-related interventions to evaluate the effects on health outcomes. SUMMARY As part of the healthcare process, physicians or other medical care providers may perform trials, programs, and other activities to evaluate the efficacy of a particular pharmaceutical drug or other medical treatment option. Conducting health-related clinical trials can help to identify medical treatment options for improving overall patient health and reducing health system costs. Clinical trials and other controlled programs are generally conducted by one or more investigators at medical facilities in different geographic locations that interact with study subjects to evaluate the efficacy of a drug treatment option. In some instances a physician for a patient can be associated with a clinical trial and the physician can refer a patient as a candidate for participation in a trial based on a diagnosed condition of the patient. An investigator, a geographic location, or both, can form an entity that executes a program. Based on the above context, this document describes a computing system that uses specific computing rules or instructions (e.g., a unique algorithm) to predict or generate commands based on a received user input. To generate the commands, the system is configured to train a predictive model using one or more learning algorithms (e.g., deep learning algorithms). The predictive model is used to process terms that are recognized and extracted using a natural language processor (NLP) in an entity module of the system. The predictive model can be trained to semantically understand relevant terms (e.g., medical and clinical terms) and their relations to other medical terms. Terms can be extracted from information sources such as textbooks and online resources, or from unstructured datasets such as electronic medical data for multiple healthcare patients. An encoding module uses one or more neural network models to encode and link the extracted terms to a particular medical entity, such as a disease entity, a drug entity, a medical procedure entity, or various other types of entities. The system leverages the predictive model's learned inferences about the encoded medical terms to generate a command based on a received query from a user. For example, a parsing engine can automatically translate the extracted terms into a machine-readable command that is processed against a medical database to obtain an accurate response to the user query. Hence, at least one goal of the predictive system is to accurately interpret, in a manner that is computationally efficient, a user query that includes health-related information about a patient or set of patients. For example, the user query represents user input, to the predictive system, that specifies a list(s) of patient attributes. The query/user input can be in a human-readable format. The described techniques enable the system to quickly and efficiently generate a corresponding command in a computer-readable format. The computer-readable command is then used to query different electronic health records (EHR) to identify patients (e.g., trial subjects) that satisfy a given condition(s) based on the attributes specified in the list. For example, the command can be used to query historical medical records to derive insights and information without manual intervention (e.g., from a human-operator). The derived insights can include accurate estimation of an eligible patient population for clinical trial participation and estimation of a propensity for adverse events). One aspect of the subject matter described in this specification can be embodied in a computer-implemented method that includes: obtaining a first set of data including multiple terms; determining that a term of the multiple terms describes a medical entity; responsive to determining that the term describes the medical entity, linking the medical entity with a category based on an encoding scheme for the category; responsive to receiving a query, generating a machine-readable command by parsing the query against terms in the first set of data that describe the medical entity and based on the encoding scheme; using the machine-readable command to query multiple databases; obtaining a second set of data responsive to the received query when the machine-readable command is used to query the multiple databases; and providing the second set of data as an output for display at a user device. These and other implementations can each optionally include one or more of the following features. For example, in some implementations, determining whether a term describes the medical entity includes: generating a confidence score based on inferences of similarity between terms described in the first set of data and the medical entity; and determining the confidence score exceeds a threshold confidence score. In some implementations, linking the medical entity with the category includes: obtaining a listing of category codes for the category; determining a match between the term and corresponding category codes in the listing of category codes; and linking the medical entity with the specified category based on the match between the term that describes the medical entity and the corresponding category codes. In some implementations, linking the medical entity with the category includes: encoding the medical entity with corresponding category codes based on the encoding scheme for the specified category; and the encoding scheme for the specified category is a hierarchical encoding scheme including a hierarchy of levels. In some implementations, encoding the medical entity with corresponding category codes includes: quantifying content including the medical entity to be encoded; determining depths of levels in the hierarchy of levels for mapping the content; and associating the medical entity included in the content with the corresponding category codes for a particular depth level in the hierarchy of levels. In some implementations, the medical entity is a disease, and determining the match includes: generating a respective match score for each level in the hierarchy of levels; and determining that the respective match score exceeds a threshold match score. In some implementations, determining that the term describes the medical entity includes: performing a lookup of the term against information in an entity-specific dataset; and determining that the term describes the medical entity based on a match between the term and a first entry in the entity-specific dataset. In some implementations, the medical entity is associated with a healthcare condition that affects an individual, and the medical entity includes at least one of: one or more medical diseases; medical drugs for treating the one or more medical diseases; medical procedures associated with the one or more medical diseases; or data describing multiple medical findings that correspond to a healthcare condition of the individual. In some implementations, the entity specific dataset is generated based on data including at least one of: i) a predefined set of information describing multiple diseases; ii) a predefined set of information describing multiple drugs; iii) a predefined set of information describing multiple medical procedures; or iv) electronic medical data for multiple healthcare patients. In some implementations, obtaining the data that describes the terms relating to the multiple medical concepts includes: obtaining multiple unstructured data; and structuring the unstructured data to enable processing of the query against information in the multiple databases. Other implementations of this and other aspects include corresponding systems, apparatus, and computer programs, configured to perform the actions of the methods, encoded on computer storage devices. A computing system of one or more computers or hardware circuits can be so configured by virtue of software, firmware, hardware, or a combination of them installed on the system that in operation cause the system to perform the actions. One or more computer programs can be so configured by virtue of having instructions that, when executed by data processing apparatus, cause the apparatus to perform the actions. The subject matter described in this specification can be implemented to realize one or more of the following advantages. The described techniques provide a scalable computing system that is a fully automated end-to-end predictive solution for analyzing and parsing structured and unstructured datasets. Using the analyzing and parsing functions, a predictive model of the system is configured such that information in the datasets can be queried using a machine-readable command that is generated based on data inferences learned by the predictive model. The predictive system is configured to quickly and efficiently analyze multiple datasets that describe a variety of diseases and indications, drugs/treatment options, and medical procedures. For example, the efficiency of the system is evidenced by the use of three steps to generate the command: (1) extraction of entities that describe patient attributes; (2) mapping a condition to a standardized scientific entity name; and (3) interpreting relationships between different healthcare conditions, including whether the conditions are negated or not. Hence, the system provides a solution that specializes in recognizing and encoding medical language terms and requires little (or no) manual data curation to achieve a desired level of accuracy in the commands or machine-readable queries that are generated and processed to obtain a response to user input. The predictive system uses learning algorithms (e.g., deep learning algorithms) to determine relationships between relevant categories of information and uses the relations between the information categories to directly query medical and research databases. The details of one or more implementations of the subject matter described in this specification are set forth in the accompanying drawings and the description below. Other potential features, aspects, and advantages of the subject matter will become apparent from the description, the drawings, and the claims. BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 shows a block diagram of an example computing system for generating machine-readable commands. FIG. 2 shows a block diagram of example data processing modules of the computing system of FIG. 1. FIG. 3 is an example process for generating machine-readable commands using a predictive model of the computing system of FIG. 1. FIG. 4 shows an example data flow for processing unstructured medical data to generate machine-understandable queries. FIG. 5 shows a block diagram of a computing system that can be used in connection with methods described in this document. Like reference numbers and designations in the various drawings indicate like elements. DETAILED DESCRIPTION Current systems store medical information in an unstructured data format and the information may be dispersed across several systems, which makes it difficult for the information to be queried and linked to other data sources. Many sources of this medical information are text based sources and the information can be formed from different elements. However, there is no international or existing categorization of these different elements that is widely followed. When querying information from these medical sources, domain expertise is often required to recognize relevant terms, categorize the terms, and convert the terms to a suitable format that can be used to query data. The ability to model and structure this medical information enable users to derive certain insights that can improve health conditions for a set of patients. For example, at least one use can involve querying a patient database to accurately calculate a patient pool with health attributes that meet the protocols and criteria for participation in a new clinical trial. In this context, techniques are described for generating a predictive model that extracts and semantically understands relevant clinical terms and a relationship between the terms. A computing system is used to extract the clinical terms from structured and unstructured datasets, e.g., using natural language processing (NLP) and deep learning algorithms. The techniques use data processing modules to recognize, extract, and categorize medical entities (e.g., indications, drugs, procedures, etc.) as well as determine relationships between the medical entities with reference to the terms that describe the entities. The information obtained from these processes is used to generate a machine-readable command for querying different databases to derive various insights and information about a set of patients without manual user intervention. For example, the command can be used to query databases of historical medical records to obtain an estimate of eligible patient populations for participation in clinical trials or to obtain an estimate of a propensity for the occurrence of adverse events in connection with a clinical trial. FIG. 1 shows a block diagram of an example computing system 100 for detecting undiagnosed conditions. System 100 can be a predictive computing system configured to process input data to train a predictive model. As described herein, the predictive model is trained to perform various functions related to processing and semantically understanding relevant clinical and medical terms. System 100 includes an entity module 120, an encoding module 140, a predictive model 160, and a parsing engine 170. During an example training phase 155, the entity module 120 and encoding module 140 are used to process input data 110 to compute learned inferences for generating a trained predictive model 160. Hence, the training phase 155 is associated with an example predictive model and is performed at system 100 to train and generate the predictive model 160. As described herein, the trained predictive model 160 is configured to extract and semantically understands relevant clinical terms and their relations from a variety of input text. The predictive model is used to process terms that are recognized and extracted using a natural language processor (NLP) in an entity module of the system. System 100 leverages the predictive model's learned inferences about the encoded medical terms to generate a command based on a received query from a user. In general, system 100 obtains or receives input data 110 for processing at the system. The input data 110 can include structured and unstructured data. The structured data can include various types of publications and health-related text, such as medical textbooks, online publications relating to healthcare, medical journals, electronic publications, medical treatises, web-based articles, medical websites, or various resources of information that is inherently formatted for data extraction and processing by a computer system. The unstructured data may include different datasets relating to medical activities, patient medical records, or healthcare transactions, and is described in detail below with reference to at least FIG. 2. Entity module 120 is configured to receive or obtain the input data 110 and process the data for training one or more predictive models of system 100. In some implementations, entity module 120 is a name entity recognition (NER) module that executes a high-level general-purpose programming language to recognize and extract data elements from input data 110. For example, entity module 120 can be a python module that uses coded instructions to identify terms and words (data elements) that describe medical entities for different medical concepts in a document. The document can be an electronic document, such as a digital version of a medical text book, and the terms or words can describe medical entities, such as disease names, drug therapies, drug compound, or medical procedures. As described in more detail below with reference to FIG. 2, entity module 120 includes various data searching/lookup and a machine-learning functions. These functions can be used to perform a dictionary look-up of each word or term in a medical document or structured data source included in the input data 110. In some implementations, the lookup functions and machine-learning functions are independent computing functions of the entity module 120. As described in more detail below, each computing function can be used to determine whether terms or data elements in the input data 110 describe particular medical entities. For example, each word or term in a medical document of the input data 110 is searched against a curated data source, such as a dictionary of entity-specific medical terms. In some implementations, performing the dictionary lookup includes extracting one or more n-grams from the medical document that are recognized as matching one or more terms in the curated data source. The extracted n-grams can include contiguous data items or elements, e.g., letters or words, which match terms in the curated data source. For example, the medical document can have letters that form words that describe a particular medical condition, such as cancer. The extracted n-grams can include contiguous letters or words that match terms in the curated data source that also describe different medical concepts related to cancer. Encoding module 140 is configured to receive or obtain data associated with medical entities, where the data includes corresponding terms that describe the medical entities. The encoding module 140 encodes the data associated with the medical entities and the encoded data is used for training one or more predictive models of system 100. In some implementations, encoding module 140 is a multi-purpose encoding module that executes a high-level general-purpose programming language to encode the data associated with the medical entities. In some cases, much like entity module 120, encoding module 140 can also be a python module that uses coded instructions to perform various functions. Encoding module 140 can use the instructions to link, associate, or otherwise encode medical entities with a specified category code 145 in response to the entity module 120 determining that a term describes the medical entity. For example, encoding module 140 encodes medical entities into a specified entity organization, where i) diseases can be encoded based on ICD-10 codes, ii) drugs can be encoded based on GPI codes, and iii) procedures can be encoded based on PRC_CD codes. The ICD-10 codes, GPI codes, and PRC_CD codes are each associated with a respective encoding scheme for health-related diseases, pharmaceutical drugs, and medical procedures. As described in more detail below, medical entities are linked or encoded with a specified category code 145 based on an encoding scheme for the specified category. In some implementations, each identified or extracted medical entity is encoded to a particular nomenclature (e.g., official disease name and corresponding category code). In some cases, one or more medical entities are encoded to more than one nomenclature. For example, drugs can be encoded at least to a particular GPI code, to a particular ATC code, or to both. Encoding module 140 can include discrete computing elements that are each used to perform the respective encoding operation for either diseases, drugs, or procedures. In some implementations, at least with reference to encoding medical entities for health-related diseases, the encoding scheme for the category codes 145 is a hierarchical encoding scheme that is based on a hierarchy of levels (or depth levels). In this manner, encoding a medical entity for health-related diseases with a corresponding category code 145 includes determining depths of levels in the hierarchy of levels and determining the appropriate level for mapping certain information content that includes the data associated with the medical entity. One or more neural networks 150 can be used to determine the depths of levels in the hierarchy of levels and to determine the corresponding level for mapping the data associated with the medical entity. The encoding module 140 can use an output (e.g., a computed inference or confidence score) of the neural networks 150 to associate the medical entity included in the information content with the corresponding category code 145 for a particular depth level in the hierarchy of levels. For example, one or more scores that each represent an inference output of each respective neural network 150 may be used to associate the medical entity with a particular depth level in the hierarchy of levels and a corresponding one or more category codes 145 at that particular depth level. Parsing engine 170 is a semantic query parser that is configured to convert user input 125 to a machine-readable command. For example, user input 125 can represent a human-understandable query and a command generator 175 is configured to generate the machine-readable command based on one or more query parsing operations that are performed on the user input 125. The parsing engine 170 uses the command generator 175 to generate the machine-readable command in response to converting the user input 125 to machine-commands based on results of the one or more query parsing operations. The generated commands can represent machine-understandable queries that are configured for processing against different medical or informational databases 190. Parsing engine 170 performs the query parsing operations to translate recognized entity relations into commands. In addition to recognizing entities, parsing engine 170 can perform the query parsing operations to determine types of relationships between terms based on certain keywords in the user input 125, a certain position of words in the text of the user input 125, or semantic attributes of terms that form the user input 125. The commands are associated with logic operations that are understandable and executable by computers. The commands and logic operations can cause the computers to query a particular dataset of databases 190, which may include executing filters or joins on tables of a relational database to obtain data elements for generating a response 195. In some implementations, the generated commands can have a machine-readable format, such as a query format that is based on the structured query language (SQL). In some implementations, a command may be formatted as an SQL query and used to obtain or manage data stored in an example relational database 190, or for streaming data processing in a relational data stream management system. An example use case for system 100 includes receiving entity module 120 receiving data specifying a protocol for a new clinical trial. Entity module 120 is used to recognize all relevant medical entities included in the protocol based on identifying and extracting one or more terms that describe entities. The encoding module 140 categorizes each of the recognized medical entities using the one or more extracted terms for each entity. For example, the parsing engine module 170 can categorize the entities as inclusion or exclusion criteria for obtaining subjects that can participate in the new clinical trial. The command generator 175 of the parsing engine 170 writes or generates a command (e.g., a query) that integrates the entities. The machine-readable command can also account for how each medical entity, and their associated terms, are related. The command is run or processed against a given dataset in a database, e.g., a medical transactions database. System 100 generates a result in response to processing the command against the database. The result can be a number of patients or potential trial subjects with medical attributes that satisfy the inclusion and exclusion criteria for the new clinical trial. As used in this document, a subject or trial subject may be a candidate for participation in a clinical trial, a participant in a clinical trial, or an existing patient (of a healthcare provider) that may be identified for participation in a clinical trial. System 100 can be configured to improve or enhance accuracy of the output determinations that are generated using at least the predictive model 160. For example, system 100 includes a feedback loop 180 that enables certain output determinations to be fed back as inputs to system 100. The feedback loop 180 can ensure full capture of discrete parameters in a set of input data 110 processed by at least the entity module 120 and encoding module 140. By feeding back data parameters of an output, such as a generated command or computed inference determination, the feedback loop 180 can be used to improve or enhance an accuracy of the predictive model 160. For example, using the feedback loop 180, system 100 can iteratively enhance its prediction capabilities by detecting new relationships and commonalities that may exist among a more granular set of parameters in an output. In some cases, system 100 obtains this iterative enhancement in accuracy in response to reevaluating output data that may include certain determinations about relationships among terms or data elements that describe different medical entities. System 100 can use the feedback loop 180 along with the entity module 120 and encoding module 140 to jointly and iteratively process various types of input data 110, including the feedback data, with reduced computation cost and better accuracy relative to conventional systems. In some implementations, an example training phase 155 of system 100 can be based on the feedback loop 180, in which embedded vectors (outputs) are fed back to the system 100 as inputs to the system that are then analyzed to iteratively enhance the accuracy of the outputs and determinations generated by the predictive model 160. In other implementations, in addition to the feedback loop 180, system 100 is configured to expand a current list of different medical entities that can be recognized using the computing rules (e.g., algorithms) executed by the modules and computing elements of the system. FIG. 2 shows a block diagram of example data processing modules 200 that correspond to the modules of system 100 described above with reference to FIG. 1. As shown at the implementation of FIG. 2, the data processing modules 200 of system 100 can include additional computing elements. These additional computing elements can represent sub-systems of the respective modules 120, 140, and 170 that are described above. For example, the additional elements can perform computing functions for processing input data during an example training phase of system 100 to generate the trained predictive model 160. As indicated above, the input data 110 processed during training phase 155 includes structured and unstructured data. For example, unstructured data 202 can include information describing health and medical attributes for a large set of patients or subjects. Unstructured data 202 can also include information describing sponsorship and execution details for a set of clinical trials. The execution details can specify information such as the medical facility, geographic location, and investigator(s) for each trial, as well as the inclusion and exclusion criteria for each trial in a set of clinical trials. In some cases, unstructured data 202 includes multiple respective datasets of healthcare transaction information and multiple respective datasets of demographic information for individual patients or prospective subjects. The healthcare transaction information can be obtained from data describing interactions between physicians and patients, data derived from a subject's physical or electronic medical records (EMR), data derived from prescription records/medical claims (“Rx/Dx data”), data relating to prescriptions or treatment options used by a patient or subject, or from other data sources relating to healthcare transactions and healthcare activities. The demographic information may include a patient identification number, a subject's age, a subject's gender and/or preferred pronoun, a subject's geographic region or address location, as well as other identifying data about a person. Entity module 120 uses coded instructions, e.g., instructions based on the python programming language, to identify medical concepts in a document and perform named entity recognition. As noted above, entity module 120 includes various data searching/lookup and a machine-learning functions. In particular, entity module 120 includes a data lookup engine 210 and a machine-learning engine 220. In some implementations, the lookup engine 210 and machine-learning engine 220 are independent computing elements of the entity module 120. Each of engines 212, 220 are configured to recognize certain data elements in the input data 110 and extract or label the data elements as describing, or being associated with, particular medical entities. Lookup engine 210 is configured to perform dictionary lookups of each term or word in the input data 110. The lookup engine 210 performs the lookup task against one or more curated entity-specific dictionaries. The entity-specific dictionaries can be curated from multiple data sources. The data sources may be internal (internal sources) to system 100 or external (external sources) to system 100, or both. The internal sources include data obtained from an electronic medical record (EMR), a disease dictionary, a drug dictionary, a procedure dictionary, or a combination of each. External sources can include websites or information databases managed by government agencies and health organizations, including domestic and international organizations such as the World Health Organization. The data obtained from the EMR includes information describing healthcare and medical conditions of multiple patients and can be structured data or unstructured data. The disease dictionary can correspond to an ICD-10 disease database, where ICD-10 is a revision of a document that defines the encoding and classification scheme for the International Statistical Classification of Diseases and Related Health Problems (ICD). The procedure dictionary can correspond to a procedure code mapping database for mapping procedure names to respective procedure codes. The drug dictionary can correspond to a GPI code mapping database for mapping drug names to respective GPI codes. A generic product identifier (GPI) is a 14-character hierarchical classification system that identifies drugs from at least their primary therapeutic use. The drug dictionary can correspond to an ATC code mapping database for mapping pharmaceutical drugs to respective ATC codes of an Anatomical Therapeutic Chemical (ATC) Classification System. The ATC codes are used for the classification of active ingredients of drugs, e.g., according to the organ or system on which they act and their therapeutic, pharmacological, and chemical properties. Machine-learning (ML) engine 220 is configured to analyze a given portion of text from input data 110 and identify or recognize whether each word or term in the text corresponds to a medical entity. The ML engine can include one or more trained neural networks. The ML engine 220 performs the analysis and term recognition functions using specific computing rules (e.g., ML algorithms) that are derived from neural networks that are trained based on a particular algorithm. An architecture of the neural networks can be a bi-directional LSTM-CRF (Long Short-Term Memory-Conditional Random Fields). Specific computing rules are derived or learned by the neural networks in response to training the neural networks using one or more datasets, such as “gold-quality” and “silver-quality” datasets. In some implementations, the gold-quality datasets are obtained from one or more of the external data sources described above. The silver quality datasets are generated using the curated entity-specific dictionaries that are also described above. During an implementation phase of system 100, performance of an example data model associated with the ML engine 220 can be further improved using transfer learning. For example, deep learning models may be pre-trained on a different task where a large amount of training data is available or trained in an unsupervised fashion which does not require manually generated training data. Pre-trained models can be fine-tuned (i.e., adapted) to a specific task, based on transfer learning, to improve performance of the models and with a reduced amount of training data. In this manner, models trained to a first task can be more efficiently re-purposed to learning a second-related task based on the inferences learned when processing data related to the first task. Referring now to encoding module 140, as described above, medical entities are linked or encoded with a specified category based on an encoding scheme for the specified category. Encoding module 140 can include discrete computing elements that are each used to perform the respective encoding operation for either diseases, drugs, or procedures. For example, as nicholas94@example.net. 2, encoding module 140 includes a disease encoder 230, a drug encoder 235, and a procedure encoder 240. Disease encoder 230 is a discrete computing element used to perform the specific encoding operations for encoding medical entities associated with health-related diseases. Disease encoder 230 is configured to map a given disease name (e.g., a medical entity) into an ICD-10 code. ICD-10 codes provide a standardized nomenclature of disease names and conditions. Category codes 145 for ICD-10 disease encoding is based on an encoding scheme that is hierarchically organized. For example, in the hierarchy of levels, a top level is level 1, a second level is level 2, a third level is level 3, a fourth level is level 4, and a fifth level is level 5. Disease encoder 230 is configured to map or encode medical entities for disease names up to level 5. Disease encoder 230 includes various data searching/look-up and a machine-learning functions. In particular, entity module 120 includes a data lookup engine 232 and a ML engine 234. In some implementations, the lookup engine 232 and ML engine 234 are independent computing elements of the disease encoder 230. Lookup engine 232 performs a dictionary lookup on medical entities relating to disease names in a curated entity-specific disease dictionary. Lookup engine 232 is configured to retrieve one or more corresponding ICD-10 codes for a given medical entity that matches a particular disease name. In some cases, the entity-specific disease dictionary is curated from data derived from one or more electronic medical records (EMR). ML engine 234 includes one or more neural networks 150. As indicated above, ML engine 234 can use the neural network(s) 150 to determine a corresponding level for mapping or encoding the data associated with the medical entity. The ML engine 234 determines the corresponding level with reference to the depths of levels (level 1-level 5) in the hierarchy of levels. In some implementations, ML engine 234 includes one neural network model 150 to perform encoding operations for each level (e.g., level 1-5) of ICD-10 nomenclature. A computed inference output (e.g., a similarity score) of the neural network model can be used to associate a medical entity with a particular depth level in the hierarchy of levels and a corresponding category (or subcategory) code 145 for that depth level. For example, ML engine 234 can generate a score for each node (or level) in a disease category tree with respect to a given user query. The category tree can include a parent level and at least one sub-category that corresponds to a child level. For a given user query ML engine 234 uses the scores to decide whether a certain parent category should be included. For example, for a given disease category ‘A’ with sub-categories ‘A1’, ‘A2’, and ‘A3’ and user query ‘Q’, ML engine 234 first generates three respective similarity scores with respect to ‘Q’: score S1, score S2, and score S3. Each of these scores can correspond to ‘A’ subcategories. The system 100 determines whether any of the scores is lower than a pre-defined threshold. If at least one score is lower than a pre-defined threshold, the system predicts the sub-categories (A1, A2, etc.) of category ‘A’ as outputs, whereas if all the scores, S1, S2, etc., are higher than the pre-defined threshold, then the system predicts category ‘A’ as the output. Algorithm can be trained to predict high similarity scores not only for a query-disease category, but also to all query-disease sub-category levels. Hence, using these methods, system 100 can identify the level as well as a correct code at that level. In other implementations, ML engine 234 includes five neural network models, where the five neural network models corresponds to neural networks 150. In this implementation, ML engine 234 uses a respective neural network model to perform encoding operations for a particular level (e.g., level 1-5) of ICD-10 nomenclature. A computed inference output of each respective neural network model can be used to associate a medical entity with a particular depth level in the hierarchy of levels and a corresponding category code 145 for that depth level. For example, each neural network model can compute a confidence score (e.g., an output) that is used to determine best matches for an official disease name and for a specific level in the ICD-10 nomenclature for a given disease name. As an example, for a medical entity “lung cancer,” a confidence score from a particular neural network model can indicate that a best matching level 1 ICD-10 official disease name is “Neoplasms,” or that best matching level 2 ICD-10 official disease name is “Malignant neoplasms of respiratory and intrathoracic organs.” For example, if a confidence score for “Neoplasms” exceeds a confidence score for another disease name (or a threshold score), then the disease encoder 230 determines that the best matching level 1 ICD-10 official disease name is “Neoplasms.” In some implementations, the neural network models have the same architecture. For example, the architecture can be based on a siamese recurrent neural network (RNN) with a single output that generates a single confidence/similarity score. In some implementations, each neural network model is trained on one or more existing mappings from a set of EMRs. Drug encoder 235 is a discrete computing element used to perform the specific encoding operations for encoding medical entities associated with pharmaceutical drugs. Drug encoder 235 can be configured to retrieve matching GPI-10 codes for a given medical entity that matches a generic or drug product name. Drug encoder 235 can also be configured to retrieve matching ATC codes for a given medical entity that matches a generic or drug product name. In some implementations, the mapping or encoding is performed based on an exact and fuzzy search against data entries of a curated entity-specific drug dictionary. The drug dictionary can include a listing of GPI-10 codes, drug product names, generic drug product names, and ATC codes, including data relating to active ingredients and chemical properties of different pharmaceutical drugs. In some cases, the drug dictionary is curated using an example internal GPI-10-generic name mapping dictionary or ATC code mapping dictionary. Procedure encoder 240 is a discrete computing element used to perform the specific encoding operations for encoding medical entities associated with medical procedures. Procedure encoder 240 is configured to retrieve matching PRC_CD codes for a given medical entity that matches a particular procedure name (e.g., a medical procedure). In some implementations, the mapping or encoding is performed based on an exact and fuzzy search against data entries of a curated entity-specific procedure dictionary. The procedure dictionary can include a listing of procedure codes (PRC_CD) and procedure names. In some cases, the procedure dictionary is curated using an example internal PRC_CD—Procedure name mapping dictionary. Encoding module 140 can also include one or more additional encoders 245. For example, the additional encoders 245 can be used to encode data describing medical findings that are associated with patient signs and symptoms, a patient's vitals, a patient's lab test results (e.g., BMI or cholesterol numbers). In some implementations, the additional encoders 245 can be used to encode data describing temporal entities that may be associated with the medical findings. For example, the temporal entities can indicate whether a medical finding was obtained or determined within the last month, the last year, or two years ago. In other implementations, the additional encoders 245 can be used to encode data as identifying an age group to which a patient belongs, e.g., adult, neonate, greater than 18 years old, or as identifying a genetic marker, e.g., cancer or another abnormality due to specific genetic mutation. As indicated above, encoding module 120 and encoding module 140 interact to execute a variety of data processing and signal processing functions that define a training phase 155 of system 100. Execution of these functions enable completion of the training phase 155 such that system 100 can generate a trained predictive model 160. During the training phase 155, lookup engine 210 performs a search of data elements in the input data 110 against the curated entity-specific dictionaries. For example, lookup engine 210 is configured to extract one or more single words (e.g., unigrams), extract two consecutive words (e.g., bigrams), or extract three consecutive words (e.g., trigrams). In some implementations, the lookup engine 210 extracts the unigrams, bigrams, and trigrams in sequential order so that the unigrams are extracted first, the bigrams are extracted second, and the trigrams are extracted third. In other implementations, the lookup engine 210 extracts the unigrams, bigrams, and trigrams (collectively “n-grams”) in no particular order. The extracted n-grams are matched against the curated entity-specific dictionaries in an exact match mode or fuzzy mode. During an implementation phase of the system 100, e.g., that uses a trained predictive model 160, extracted n-grams are matched against the curated entity-specific dictionaries in a fuzzy mode. In some implementations, the fuzzy mode matching is based on an example minimum-edit-distance algorithm. For example, if the lookup engine 210 detects a match between an input term/word or phrase and an entity in a specific dictionary, then the particular matching word or phrase is labelled with the corresponding matching medical entity. Parsing engine 170 is a semantic query parser that is configured to convert user input 125 to a machine-readable command. As described in more detail below, based on a received query, the parsing engine 170 is generally configured: i) to perform named entity recognition to extract patient attributes from the query; ii) encode one or more patient attributes into a standard format; iii) if multiple patient attributes are mentioned, then determine how one or more of the attributes should be combined; iv) determine if any of the patient attribute criteria should be negated; and v) based on the outcome of one or more of the preceding steps i)-iv), build a computer understandable query searching a medical database 190. Parsing engine 170 includes name entity recognition (NER) and encoding engine 250, entity negation engine 255, and conjunction engine 260. For a given query input, NER and encoding engine 250 is configured to identify all patient attributes that are related to one or more medical concepts, patient diagnosis, patient prescription history, and medical procedures that previously provided to the patient. Entity negation engine 255 can include software instructions for a negation identifier that identifies whether to include or exclude certain patient attributes. Conjunction engine 260 can include software instructions for identifying conjunction patterns in a query input. For example, when multiple patient attributes are queried, conjunction engine 260 can identify one or more conjunction patterns in an example user input. As an example, conjunction engine 260 is configured to differentiate between the following two queries: i) “patients with fever AND pain” vs. ii) “patients with fever OR pain.” Conjunction engine 260 is configured to differentiate between the first and second queries based on an identified conjunction pattern of each query. For example, in the first query i), both “fever” and “pain” attributes must be present, whereas in the second query ii), the existence of either attribute is sufficient. FIG. 3 is an example process 300 for generating a machine-readable command based on the described techniques. Process 300 can be implemented using one or more computing elements of system 100 described above as well as other components and instructions described in this document. Referring now to process 300, system 100 obtains data that describes terms relating to multiple different medical concepts (302). In some implementations, the obtained data is structured or unstructured data included in the input data 110. For example, the unstructured data 202 includes healthcare transaction information obtained from data describing interactions between physicians and patients, data derived from a subject's physical or electronic medical records (EMR), data derived from prescription records/medical claims (“Rx/Dx data”), or data relating to prescriptions or treatment options used by a patient or subject. The system 100 uses an entity module to determine whether a term describes a medical entity (304). The medical entity can be associated with a healthcare condition that affects an individual. For example, during a training phase 155 of system 100, entity module 120 performs a dictionary look-up of each word or term in a medical document or unstructured data source, such as a patient EMR. The medical document can have letters that form words that describe a particular medical condition, such as cancer (e.g., a medical entity). The terms or words that describe, or are associated with, a medical entity are extracted when the entity module 120 detects that the words match terms in the curated data source that also describe medical concepts related to cancer. During an implementation phase of system 100, determining whether a term describes a medical entity can include the predictive model 160 computing inferences for determining a confidence that a term, e.g., in user input 125, is relevant to describing a medical entity, such as cancer. The predictive model 160 cam generate a confidence score that represents a confidence that the term describes the medical entity. For example, a query can be “show a listing of patients that are in chemotherapy?” The predictive model 160 can determine that the term “chemotherapy” describes the medical entity, cancer, based on a confidence score that exceeds a threshold confidence score. The system 100 uses an encoding module to link the medical entity with a specified category (306). For example, during at least the training phase 155, when the term recognized in the input data 110 describes the medical entity the encoding module 140 is used to link the medical entity with the specified category. The medical entity is linked or encoded with the specified category based on an encoding scheme for the specified category. For example, the encoding module 140 obtains a listing of category codes 145 for the specified category and determines a match between the term that describes the medical entity and corresponding one or more category codes in the listing of category codes. The encoding module 140 then links the medical entity with the specified category based on the determined match between the term that describes the medical entity and the corresponding category codes. In some implementations, the encoding scheme for the specified category is a hierarchical encoding scheme that includes a hierarchy of levels. In this implementation, encoding the medical entity with the corresponding category codes includes: i) quantifying information content that includes the medical entity to be encoded; ii) determining depths of levels in the hierarchy of levels for mapping the information content; and iii) associating the medical entity included in the information content with the corresponding category codes for a particular depth level in the hierarchy of levels. Quantifying information content can include the task of identifying a correct category level for a given query. For example, in the case of disease encoding, the term “infection” may not contain sufficient information to map a medical entity to a specific type of infection, such as mapping it to “tuberculosis of lungs.” So, in this case, the system 100 can map “infection” to a highest category of diseases that contain all “infections,” as described above with reference to computing similarity scores for a given category tree. The predictive computing system 100 receives a query that seeks a response (308). For example, the query can be a request for a list of subjects that are suitable candidates for participation in a clinical trial that evaluates the efficacy of a new cancer treatment drug. The parsing engine 170 of system 100 uses the received query to generate a machine-readable command (310). In some implementations, the command is generated in response to the parsing engine 170 parsing the query against terms that describe the medical entity and based on the encoding scheme for linking the medical entity to the specified category. The parsing engine 170 can perform the query parsing operations to determine types of relationships between terms based on certain keywords in the user input 125, a certain position of words in the text of the user input 125, or semantic attributes of terms that form the user input 125. In some implementations, the parsing engine 170 uses one or more semantic parsing functions to determine the semantic attributes of the terms in the user input 125. The semantic parsing functions can include extracting a sentence syntax from the user input 125, e.g., by applying specific computing rules derived from a machine-learning solution that may be pre-trained to detect sentence syntax of an input phrase or query. The system 100 uses the command to query one or more databases to obtain data for generating a response to the received query (312). For example, the trained predictive model 160 can interact with the entity module 120 and the encoding module 140 to identify one or more patient attributes as conditions, e.g., health-related or medical conditions. The semantic parsing functions of the parsing engine 170 can be used to determine: (1) whether each condition is negated; and (2) when more than one
{'application_number': '<application-reference appl-type="utility">\n<document-id>\n<country>US</country>\n<doc-number>17532577</doc-number>\n<date>20211122</date>\n</document-id>\n</application-reference>', 'publication_number': '<publication-reference>\n<document-id>\n<country>US</country>\n<doc-number>20220083605</doc-number>\n<kind>A1</kind>\n<date>20220317</date>\n</document-id>\n</publication-reference>', 'source_file': './application/2022/ipa220317.xml', 'source_data': 'USPTO-Application'}