SELF-SERVICE COHORT SELECTION FOR LARGE-SCALE OBSERVATIONAL STUDIES

A method for self-service cohort selection may include receiving one or more user inputs specifying one or more cohort selection criteria. A script for accessing a first data store storing a first dataset may be generated based on the one or more cohort selection criteria. The script may be executed to retrieve, from the first dataset in the first data store, a subset of data. A second dataset corresponding to the first subset of data retrieved from the first data store may be generated for storage at the second data store. A visual representation of at least a portion of the second dataset may be generated for display at the client device. Related systems and computer program products are also provided.

TECHNICAL FIELD

The subject matter described herein relates generally to database processing and more specifically to self-service cohort selection for large-scale observational studies and disease registries.

INTRODUCTION

Real-world data enables essential research on health and disease among communities. Large cohorts of research volunteers are designed to support a wide range of research projects. Cohort selection is the process of selecting a project-specific subset of data from a larger cohort. The huge volume of potential project-specific combinations of exposure data, endpoint data, and analytic designs makes cohort selection a challenge for providers and researchers.

SUMMARY

Systems, methods, and articles of manufacture, including computer program products, are provided for self-service cohort selection. In one aspect, there is provided a system that includes at least one processor and at least one memory. The at least one memory may include program code that provides operations when executed by the at least one processor. The operations may include: receiving, from a first client device, a first user input specifying one or more cohort selection criteria; generating, based at least on the one or more cohort selection criteria, a script for accessing a first data store storing a first dataset; executing the script to retrieve, from the first dataset in the first data store, a first subset of data; generating, for storage at a second data store, a second dataset corresponding to the first subset of data retrieved from the first data store; and generating, for display at the first client device, a visual representation of at least a portion of the second dataset.

In another aspect, there is provided a method for self-service cohort selection. The method may include: receiving, from a first client device, a first user input specifying one or more cohort selection criteria; generating, based at least on the one or more cohort selection criteria, a script for accessing a first data store storing a first dataset; executing the script to retrieve, from the first dataset in the first data store, a first subset of data; generating, for storage at a second data store, a second dataset corresponding to the first subset of data retrieved from the first data store; and generating, for display at the first client device, a visual representation of at least a portion of the second dataset.

In another aspect, there is provided a computer program product including a non-transitory computer readable medium storing instructions. The instructions may cause operations when executed by at least one data processor. The operations may include: receiving, from a first client device, a first user input specifying one or more cohort selection criteria; generating, based at least on the one or more cohort selection criteria, a script for accessing a first data store storing a first dataset; executing the script to retrieve, from the first dataset in the first data store, a first subset of data; generating, for storage at a second data store, a second dataset corresponding to the first subset of data retrieved from the first data store; and generating, for display at the first client device, a visual representation of at least a portion of the second dataset.

In some variations of the methods, systems, and computer program products, one or more of the following features can optionally be included in any feasible combination.

In some variations, the first dataset may include a plurality of records. Each of the plurality of records may be associated with a participant.

In some variations, each of the plurality of records may be associated with a plurality of attributes corresponding to one or more exposures, genomic biomarkers, and/or clinical phenotypes of the participant.

In some variations, the plurality of attributes may include a date of birth, a race, an ethnicity, and a vital status of the participant.

In some variations, the plurality of attributes may include a first date when follow-up began, a second date when follow-up ended, and a third date of each follow-up survey.

In some variations, the plurality of attributes may include a site, a stage, a grade, and a diagnosis date for a disease associated with the participant.

In some variations, the script may be executed to identify, based on one or more of the plurality of attributes, one or more records matching the one or more cohort selection criteria.

In some variations, the script may be executed to identify, based on a combination of a first attribute and a second attribute from the plurality of attributes, one or more records matching the one or more cohort selection criteria.

In some variations, the combination of the first attribute and the second attribute may include a maximum, a minimum, a mean, a mode, a median, and/or a range of a respective values of the first attribute and the second attribute.

In some variations, the plurality of records may include a first record for a first disease associated with the participant and a second record for a second disease associated with the participant.

In some variations, the first dataset at the first data store may be preprocessed by at least identifying a first record and a second record of a same disease associated with the participant, and performing a deduplication that includes (i) removing the first record or the second record based on the first record and the second record being identical or (ii) combining the first record and the second record to generate a third record replacing the first record and the second record based on the first record and the second record each containing some but not all of the plurality of attributes.

In some variations, a user interface may be generated for receiving the first user input specifying the one or more cohort selection criteria, the user interface including a first input control for a first cohort selection criterion determined based on at least a portion of the plurality of attributes.

In some variations, the first input control may provide a selection between at least a first value and a second value for the first cohort selection criteria. The first value and the second value may be determined on at least the portion of the plurality of attributes.

In some variations, the user interface may further include a second input control for a second cohort selection criterion determined based on at least the portion of the plurality of attributes.

In some variations, the visual representation of at least the portion of the second dataset may include at least one of a heat map, a bar graph, a pie chart, and a line graph.

In some variations, the one or more cohort selection criteria may include an endpoint definition comprising one or more of a disease diagnosis, hospitalization, and mortality.

In some variations, the one or more cohort selection criteria may include one or more inclusion criteria or exclusion criteria.

In some variations, a second user input modifying the one or more cohort selection criteria may be received from the client device. The script for accessing the first data store storing the first dataset may be modified based at least on the one or more modified cohort selection criteria. The updated script may be executed to retrieve, from the first dataset in the first data store, a second subset of data. The second data store may be updated to include the second subset of data retrieved from the first data store.

In some variations, the second data store may be updated to include the first subset of data as a first version of the second dataset and the second subset of data as a second version of the second dataset.

In some variations, the second data store may be updated by at least replacing the first subset of data with the second subset of data as the second dataset.

In some variations, the first dataset may be generated by at least querying a third data store to retrieve at least a portion of a third dataset stored therein. The first data store may be updated to include the first dataset.

In some variations, the third data store may be a relational database and the first data store may be a non-relational database.

In some variations, the generating of the first dataset may include transforming at least a portion of the third dataset retrieved from the third data store from a predefined schema of the relational database to a dynamic schema of the non-relational database.

In some variations, the generating of the first dataset may include performing a domain based filtering of the third dataset.

In some variations, the generating of the first dataset may include joining at least the portion of the third dataset.

In some variations, the first user input specifying a first cohort selection criteria may be received from the first client device. A second user input modifying the first cohort selection criteria and/or specifying a second cohort selection criteria may be received from a second client device.

In some variation, in response to the first user input specifying a first value for a cohort selection criterion, the second dataset may be generated to correspond to the first dataset retrieved from the first data store. In response to the first user input specifying a second value for the cohort selection criterion, a further subset of the first subset of the first dataset may be generated to correspond to the second value of the cohort selection criterion and the second dataset may be generated to correspond to the further subset of the first subset of the first dataset.

In some variations, a user associated with the first client device may be authenticated by at least sending, to a project and user management system, a user credential information from an active directory of a secure environment and receiving, from the project and user management system, one or more client devices with access to a project associated with the first dataset.

DETAILED DESCRIPTION

Observational research using real-world data makes vital and important contributions to research into various diseases such as cancer. Well-designed and rigorous cohort studies that enroll volunteers who agree to have their health data tracked and aggregated for future research are especially important for observational research. These cohorts transcend individual investigators or projects and become community resources that add value and economies of scale by enabling entire research communities to utilize a cohort's data and resources for hypothesis-driven research. The largest cohorts can include hundreds of thousands of participant partners (e.g., volunteers) and are designed to last for decades and support a wide range of future research.

Prospective cohorts collect exposure (e.g., surveys of patient-reported outcomes or lifestyle factors) and clinical phenotype (e.g., via linkage with electronic health records or administrative claims data) data that can be used in various analytic designs, including time-to-event analyses, nested case-control studies, or cross-sectional comparisons. Even with modest sample sizes, the number of potential projects (e.g., all possible combinations of analytic designs, exposures, and phenotypes) in a typical cohort is enormous. Adding genomic or other biomarker data creates even more potential possibilities. For example, the 500,000-participant UK Biobank, a relatively new cohort, can already support tens of millions of potential projects.

Projects rarely if ever require all the data a cohort possesses, and cohorts never provide all of their data to individual researchers or research projects. Instead, researchers need project-specific subsets of a cohort's data. In this context, the term “cohort selection” refers to the process of selecting and providing custom data for every research project. Cohorts approach cohort selection in different ways, but the process typically involves applying inclusion & exclusion criteria, defining the parameters of a specific analysis, and choosing the specific covariates and endpoint data needed for that analysis.

Cohort selection is often a bottlenecking event. For cohorts that keep their data on premise (e.g., behind institutional firewalls), cohort selection can require extensive back-and-forth conversations between investigators and cohorts with the cohort team then applying those decisions to generate custom datasets that are made available to investigators. Newer cohorts and networks, such as the UK Biobank and CRDN, use cloud resources to make their data available, but cohort selection can still take weeks or months and require significant resources from both cohorts and investigators. In some example embodiments, a cohort selection engine may improve cohort-selection by supporting a direct configuration of project specific design and data. The cohort selection engine may include a self-service cohort-selection tool capable of accommodating an extensive range of potential combinations of design and data within a large prospective cohort.

In some example embodiments, the cohort selection engine may receive, from a client device, a user input specifying one or more cohort selection criteria. The cohort selection engine may generate, based at least on the one or more cohort selection criteria, a script for accessing a first data store storing a first dataset. The cohort selection engine may execute the script to retrieve, from the first dataset in the first data store, a first subset of data before generating, for storage at a second data store, a second dataset (e.g., a custom dataset) corresponding to the first subset of data retrieved from the first data store. Moreover, in some cases, the cohort selection engine may generate one or more custom documentation and scripts that enable the consumption of the second dataset stored at the second data store. While no two cohorts are identical, large-scale cohorts do share common design and data features that make cohort-selection a universal challenge. The cohort selection engine described herein may improve cohort-selection particularly within large-scale research resources that share their data.

In some example embodiments, the cohort selection engine may generate the first dataset by querying a third data store to retrieve at least a portion of a third dataset stored therein before updating the first data store to include the first dataset. For example, in some cases, the cohort selection engine may generate the first dataset by performing a domain based filtering of the third dataset stored in the third data store. Alternatively and/or additionally, the cohort selection engine may generate the first dataset by joining at least a portion of the third dataset. In some cases, the first data store may be a non-relational (or NoSQL) database whereas the third data store may be a relational (or SQL) database. Accordingly, the generating of the first dataset may include transforming at least a portion of the third dataset retrieved from the third data store from a predefined schema of the relational database to a dynamic schema of the non-relational database.

FIG.1depicts a system diagram illustrating an example of a cohort selection system100, in accordance with some example embodiments. Referring toFIG.1, the cohort selection system100may include a cohort selection engine110, one or more data stores120, and one or more client devices130. As shown inFIG.1, the cohort selection engine110, the one or more data stores120, and the one or more client devices130may be communicatively coupled via a network140. The one or more client devices130may be a processor-based device including, for example, a workstation, a desktop computer, a laptop computer, a smartphone, a tablet computer, a wearable apparatus, and/or the like. The network140may be a wired network and/or a wireless network including, for example, a local area network (LAN), a virtual local area network (VLAN), a wide area network (WAN), a public land mobile network (PLMN), the Internet, and/or the like.

Referring toFIG.1, the one or more client devices130may include a user interface135configured to receive one or more user inputs from a user150at the one or more client devices130. For example, in some cases, the user interface135may be a part of a web-based application associated with the cohort selection engine110. As shown inFIG.1, the cohort selection engine110may receive, from a first client device130a, a first user input specifying a first cohort selection criteria. Moreover, in some cases, the cohort selection engine110may support collaboration across multiple client devices130. Accordingly, in addition to the first user input received from the first client device130a, the cohort selection engine110may also receive, from a second client device130b, a second user input modifying the first cohort selection criteria and/or specifying a second cohort selection criteria. The cohort selection engine110may generate, based at least on the one or more cohort selection criteria, a script115for accessing a first data store120astoring a first dataset125a. The cohort selection engine110may execute the script115to retrieve, from the first dataset125ain the first data store120a, a first subset of data before generating, for storage at a second data store120b, a second dataset125bcorresponding to the first subset of data retrieved from the first data store120a. In some example embodiments, the cohort selection engine110may generate the user interface135to display, at the client device130, a visual representation of at least a portion of the second dataset125bstored at the second data store120b. As shown inFIG.2, examples of the visual representation in this context may include a heatmap, a bar graph, a pie chart, a line graph, and/or the like. Moreover, in some cases, the cohort selection engine110may generate one or more custom documentation and additional scripts that enable the consumption of the second dataset125bstored at the second data store120b.

For example, in some cases, once the cohort-selection process is complete, the cohort selection engine110may save the user inputs received from the one or more client devices130. Moreover, the cohort selection engine110may generate a variety of deliverables including 1) a custom dataset in a *.csv format, for consumption by open-source software; 2) an identical version of that dataset but formatted for use in an analysis system such as STATISTICAL ANALYSIS SYSTEM (SAS), which is the primary software used in the cancer epidemiology cohort (CEC) community; 3) an analysis system-specific formats file to accompany the analysis system dataset; 4) a custom data dictionary, based on the presentation database master dictionary, that includes all of the covariates selected (and omits all covariates that were not selected); and 5) a summary of all of the cohort-selection design choices, such as start-of-follow-up, end-of-follow-up, and specific cancer sites and histologic codes that were included in the cancer outcome. The cohort selection engine110may write deliverables automatically to a read-only project-specific directory within, for example, a remote desktop environment at the one or more client devices130. Doing so may provide the user150with the data and documentation necessary for downstream analyses. New code and/or scripts may be created within user-specific project folders within the remote desktop environment. Writing the data to a read-only drive may facilitate data governance and enable version control. In addition, this strategy may preserve data fidelity from these output datasets back to the second data store120b(e.g., the presentation database) and ultimately the first data store120aand/or the third data store120c. The cohort selection engine110may be capable of generating output files in very little time, providing essentially immediate access to any necessary data, tools, and documentation.

In some example embodiments, the cohort selection engine110may receive, from the client device130, a second user input modifying the one or more cohort selection criteria. The cohort selection engine110may respond to the receiving the second user input by at least updating, based at least on the one or more modified cohort selection criteria, the script115for accessing the first data store120astoring the first dataset125a. The cohort selection engine110may execute the updated script115to retrieve from the first dataset125astored at the first data store120a, a second subset of data before updating the second data store120bto include the second subset of data retrieved from the first data store120a. For example, in some cases, the second data store120bmay be updated to include the first subset of data as a first version of the second dataset125band the second subset of data as a second version of the second dataset125b. Alternatively, the second data store120bmay be updated by replacing the first subset of data with the second subset of data as the second dataset125b.

In some example embodiments, the cohort selection engine110may generate the first dataset125aby at least querying a third data store120cto retrieve at least a portion of a third dataset125cstored therein before updating the first data store120ato include the first dataset125a. For example, in some cases, the query selection engine110may generate the first dataset125aby performing a domain based filtering of the third dataset125cstored at the third data store120c. Alternatively and/or additionally, the cohort selection engine110may generate the first dataset125aby joining at least the portion of the third dataset125cstored at the third data store120c. In some cases, the first data store120amay be a non-relational (or NoSQL) database whereas the third data store120cmay be a relational (or SQL) database. Accordingly, in some instances, the generating of the first dataset125amay further include transforming at least a portion of the third dataset125cretrieved from the third data store120cfrom a predefined schema of the relational database to a dynamic schema of the non-relational database.

Follow-up data updating the third dataset125cat the third data store120c, and consequently the first dataset125aat the first data store120aand the second dataset125bat the second data store120bmay undergo regular updates (e.g., annual updates). Accordingly, in some example embodiments, the second data store120bmay be a versioned presentation database and the second dataset125ba portion of the first dataset125aextracted from the first data store120a. The second data store120bmay therefore serve as an intermediary between the one or more client devices130and the underlying first data store120aand the third data store120csuch that neither the first dataset125anor the third dataset125care directly accessible.

In some cases, the third dataset125cmay include so-called missing-by-design data. Nevertheless, as large prospective studies follow their participants for years and decades, the combination of study censoring (e.g., participants who die do not complete subsequent follow-up surveys) and rare but important outcomes (e.g., small percentages of participants have second, third, and fourth primary cancers) create valuable data in subsets of the study population. As such, while the third data store120cis implemented as a relational (or SQL) database, the second data store120bmay be implemented as a non-relational (or NoSQL) database. Serving as the presentation database for data selected from the third data store120c, implementing the second data store120bas a non-relational (or NoSQL) database may increase the flexibility, scalability, and speed of the cohort selection engine110.

As the presentation database, the second data store120cmay be populated with key data from three main domains including participant, outcome, and exposure. Participant data may include various characteristics (e.g., date of birth, race/ethnicity, vital status, and/or the like) as well as follow-up information (e.g., date follow-up began, date follow-up ended, dates of follow-up surveys, and/or the like). In the case of cancer, outcome data may include detailed disease information (e.g., site, stage, grade, diagnosis date, and/or the like) for all cancers during follow-up. Exposure data may include approximately6000covariates (i.e., columns) from the baseline as well as follow-up surveys. These data included at least one column for every question that was asked, plus numerous existing covariates derived from those responses (e.g., calculated body mass index (BMI) based on self-reported height and weight). The questionnaire covariates may be tagged to facilitate identification by question number, questionnaire section, or questionnaire number.

In some example embodiments, the first dataset125astored at the first data store120amay include a plurality of records, each of which being associated with a participant. For example, in some cases, each record in the first dataset125amay include a plurality of attributes of the corresponding participant. Examples of attributes in this context may include one or more exposures, genomic biomarkers, clinical phenotypes, a date of birth, a race, an ethnicity, a vital status, a first date when follow-up began, a second date when follow-up ended, a third date of each follow-up survey, a site of a disease, a stage of a disease, a grade of a disease, and a diagnosis date of a disease. In some cases, the records in the first dataset125amay include analytic outcomes (e.g., International Classification of Diseases (ICD) based outcomes such as cancer, mortality, or hospitalization) as well as various types of exposure data (e.g., self-report from surveys, geospatial, or biospecimens). It should be appreciated that exposures and outcomes tend to be covariates with exposures being independent variables and analytic outcomes being dependent variables. The cohort selection engine110described herein may be configured to support cohort designs with any combination of analytic outcomes and exposure data (e.g., cancer as the analytic outcome and self-reported survey data as the exposures), including combinations of multiple outcomes and multiple exposures. For example, in some cases, the covariates may be selected individually or by hierarchical categories. Moreover, the cohort selection engine110may generate the first subset of the first dataset125a by applying different start-of-follow-up, end-of-follow-up, and analytic censoring rules.

In some example embodiments, the cohort selection engine110may execute the script115to identify, based on a combination of a first attribute and a second attribute from the aforementioned plurality of attributes, one or more records in the first dataset125amatching the one or more cohort selection criteria. In some cases, the combination of the first attribute and the second attribute may include a maximum, a minimum, a mean, a mode, a median, and/or a range of a respective values of the first attribute and the second attribute. Moreover, in some cases, the plurality of records included in the first dataset125amay include, for a single participle, multiple records of associated with a same disease or different diseases. For example, the plurality of records included in the first dataset125amay include a first record for a first disease associated with a participant and a second record for the first disease or a second disease associated with the same participant. Accordingly, in some instances, the cohort selection engine110may preprocess the first dataset125aat the first data store120aby at least identifying a first record and a second record of a same disease associated with the participant, and performing a deduplication that includes (i) removing the first record or the second record based on the first record and the second record being identical or (ii) combining the first record and the second record to generate a third record replacing the first record and the second record based on the first record and the second record each containing some but not all of the plurality of attributes.

As noted, in some cases, the user interface135at the client device130may be configured to receive one or more user inputs from the user150at the one or more client devices130. A screenshot depicting an example of the user interface135is shown inFIG.2. In some example embodiments, the cohort selection engine110may generate the user interface135to include one or more input controls including, for example, a first input control for a first cohort selection criterion, a second input control for a second cohort selection criterion, and/or the like. In some cases, the user interface135may include a series of drop-down menus and search functions to facilitate a selection amongst, for example, different cancer sites, cancer histologies, or related survey covariates within a particular survey. The cohort selection engine110may be configured to interim progress (e.g., locally at the one or more client devices130, remotely at the cohort selection engine110, and/or the like), thus subsequent edits, including back-and-forth navigation across different cohort selection criteria, and collaboration across multiple users150and/or multiple client devices130.

The first cohort selection criterion and the second cohort selection criterion may each be determined based on at least a portion of the aforementioned plurality of attributes. Examples of the cohort selection criteria may include various inclusion criteria and/or exclusion criteria. For instance, in some cases, the first cohort selection criterion and/or the second cohort selection criterion may include an endpoint definition such as one or more of a disease diagnosis, hospitalization, and mortality. In some cases, the input control associated with a particular cohort selection criterion may provide a selection between multiple values such as a first value, a second value, and/or the like. In some cases, the selection of values associated with a cohort selection criterion may also be determined based on at least the portion of the plurality of attributes.

In some example embodiments, the cohort selection engine110may generate a further subset of the first dataset125awhen generating the second dataset125bwhen a first value associated with a cohort selection criterion is selected instead of a second value associated with the cohort selection criterion. For example, for a cohort selection criterion that includes an endpoint definition, the cohort selection engine110may generate the second dataset125bto correspond to the first subset of the first dataset125awhen a particular disease diagnosis (e.g., cancer) is selected as the endpoint definition. In doing so, the second dataset125bmay include records of participants who are documented as having been diagnosed with the particular disease (e.g., cancer). Alternatively, where hospitalization or mortality is selected as the endpoint definition, the cohort selection engine110may generate the second dataset125to correspond to a further subset of the first dataset125a(e.g., a subset of the first subset of the first dataset125a) such that the second dataset125includes records of participants who have been diagnosed with the particular disease (e.g., cancer) but who have further undergone hospitalization or have passed away.

Referring again toFIG.1, in some cases, the cohort selection engine110may be linked via an integration to a project & user management system160. In some cases, the link between the cohort selection engine110and the project and user management system160may be bidirectional. Accordingly, when the user150at the one or more client devices130attempts a login, the cohort selection engine110may send, to the project and user management system160, user credential information from an active directory of a secure environment associated with the cohort selection engine110. In response, the project and user management system160may return, to the cohort selection engine110, information about a corresponding cohort selection project including, for example, the disease endpoints, the clients with access to the cohort selection project, and/or the like.

In cases where a project requires additional data joins of the underlying first dataset125a(at the first data store120a) and/or the third dataset125c(at the third data store120c) that are not in the second data store120b(e.g., the presentation database), existing templates may be modified to deposit those data excerpts into a project team specific read-only directory. In some cases, the data joins may be achieved through a universal data key, thus providing essentially immediate access to these additional or custom data.

To facilitate cohort selection, the cohort selection engine110may automatically provide one or more covariates that are essential (e.g., dates of birth, death, and baseline survey) or have been observed in a more than a threshold quantity of analyses (e.g., body mass index (BMI), smoking status, and/or the like). Instead of requiring every decision to be made from scratch, the cohort selection engine110may generate the user interface135to provide certain default choices on key analytic decisions, such as excluding participants with prevalent cancers, while also allowing researchers to make alternative choices.

FIG.4depicts a flowchart illustrating an example of a process400for cohort selection, in accordance with some example embodiments. Referring toFIGS.1and4, the process400may be performed by the cohort selection engine110in order to populate the second data store120b(e.g., the presentation database) with the second dataset125b, which corresponds to at least a portion of the first dataset125aat the first data store120a.

At402, the cohort selection engine110may receive one or more user inputs specifying one or more cohort selection criteria. In some example embodiments, the cohort selection engine110may receive, from the first client device130a, a first user input specifying a first cohort selection criteria. In some cases, the cohort selection engine110may further receive, from the second client device130b, a second user input modifying the first cohort selection criteria and/or specifying a second cohort selection criteria. In some cases, the cohort selection engine110may generate the user interface135, which may be displayed at the first client device130aand/or the second client device130bto receive the one or more user inputs. For example, in some cases, the cohort selection engine110may generate the user interface135to include a first input control for receiving the first user input specifying the first cohort selection criterion and a second input control for receiving the second user input specifying the second cohort selection criterion. In some cases, the first input control and/or the second input control may provide a selection between multiple values including, for example, a first value, a second value, and/or the like. In some cases, the cohort selection criteria included in the user interface135and the selection of values associated with each cohort selection criteria may be determined based on a plurality of attributes associated with each of the records included in the first dataset125a. As noted, examples of attributes may include one or more exposures, genomic biomarkers, clinical phenotypes, a date of birth, a race, an ethnicity, a vital status, a first date when follow-up began, a second date when follow-up ended, a third date of each follow-up survey, a site of a disease, a stage of a disease, a grade of a disease, and a diagnosis date of a disease.

At404, the cohort selection engine110may generate, based at least on the one or more cohort selection criteria, a script for accessing a first data store storing a first dataset. In some example embodiments, the cohort selection engine110may generate, based at least on the one or more cohort selection criteria, the script115. In some cases, the script115may be configured to retrieve, from the first dataset125ain the first data store120a, a first subset of data that is consistent with the first cohort selection criterion and/or the second cohort selection criterion specified by the one or more user inputs received from the one or more client devices130. In some cases, in addition to the script115, the cohort selection engine110may also generate one or more custom documentation and additional scripts that enable the consumption of the second dataset125bstored at the second data store120b.

At406, the cohort selection engine110may execute the script to retrieve, from the first dataset at the first data store, a subset of data. For example, in some example embodiments, the cohort selection engine110may execute the script115to retrieve, from the first dataset125aat the first data store120a, a first subset of data. In some cases, depending on the values selected for the first cohort selection criterion and/or the second cohort selection criterion, a further subset of the first subset of data may be retrieved from the first dataset125aat the first data store120a. For instance, for a cohort selection criterion that includes an endpoint definition, the cohort selection engine110may execute the script115to retrieve the first subset of data from the first dataset125astored at the first data store120awhere a first value is selected for the cohort selection criterion (e.g., cancer instead of mortality or hospitalization). Alternatively, where a second value is selected for the cohort selection criterion (e.g., mortality or hospitalization instead of cancer), the cohort selection engine110may execute the script115to retrieve a further subset of the first subset of data from the first dataset125a.

At408, the cohort selection engine110may generate, for storage at a second data store, a second dataset corresponding to the subset of data. In some example embodiments, the cohort selection engine110may generate, for storage at the second data store120b, the second dataset125bto correspond to either the first subset of data (or the further subset of the first subset of data) from the first dataset125astored at the first data store120a. In some cases, after the second dataset125bhas been generated for storage at the second data store120b, the cohort selection engine110may receive, from the one or more client devices130, a third user input modifying the one or more cohort selection criteria. Accordingly, the cohort selection engine110may update, based at least on the one or more modified cohort selection criteria, the script115for accessing the first data store120astoring the first dataset125a. Moreover, the cohort selection engine110may execute the updated script115to retrieve, from the first dataset125astored at the first data store120a, a second subset of data. In some cases, the cohort selection engine110may update the second data store120bto include the first subset of data as a first version of the second dataset125band the second subset of data as a second version of the second dataset125b. Alternatively, the second data store120bmay be updated by replacing the first subset of data with the second subset of data as the second dataset125b.

At410, the cohort selection engine110may generate, for display at the client device, a visual representation of at least a portion of the second dataset. In some example embodiments, the cohort selection engine110may generate (or update) the user interface135to display, at the one or more client device130, a visual representation of at least a portion of the second dataset125bstored at the second data store120b. As shown inFIG.3, in some cases, the visual representation of at least the portion of the second dataset125bmay include one or more of a heatmap, a bar graph, a pie chart, a line graph, and/or the like.

FIG.5depicts a block diagram illustrating an example of computing system500, in accordance with some example embodiments. Referring toFIGS.1and5, the computing system500may be used to implement the cohort selection engine110, the one or more client devices130, the project and user management system160, and/or any components therein.

As shown inFIG.5, the computing system500can include a processor510, a memory520, a storage device530, and input/output devices540. The processor510, the memory520, the storage device530, and the input/output devices540can be interconnected via a system bus550. The processor510is capable of processing instructions for execution within the computing system500. Such executed instructions can implement one or more components of, for example, the cohort selection engine110, the one or more client devices130, the project and user management system160, and/or the like. In some example embodiments, the processor510can be a single-threaded processor. Alternately, the processor510can be a multi-threaded processor. The processor510is capable of processing instructions stored in the memory520and/or on the storage device530to display graphical information for a user interface provided via the input/output device540.

The memory520is a computer readable medium such as volatile or non-volatile that stores information within the computing system500. The memory520can store data structures representing configuration object databases, for example. The storage device530is capable of providing persistent storage for the computing system500. The storage device530can be a floppy disk device, a hard disk device, an optical disk device, or a tape device, or other suitable persistent storage means. The input/output device540provides input/output operations for the computing system500. In some example embodiments, the input/output device540includes a keyboard and/or pointing device. In various implementations, the input/output device540includes a display unit for displaying graphical user interfaces.