Patent Description:
This background section is provided for introductory purposes and to aid the reader in understanding the detailed description. The background should not be taken as an admission of any prior art to the claims.

Some computer systems limit access to electronic data assets by requiring authentication credentials, such as a username and password. Some computer systems also impose authorization restrictions that specify which user or groups of users can read, write, or modify an electronic data asset.

However, these computer systems can be insufficient for protecting and auditing access to electronic data assets. Furthermore, the use of authentication credentials and authorization restrictions, without more, can be inefficient and take large amounts of time, data, and memory to administer, especially when making large scale changes. Authentication credentials and authorization restrictions may also be insufficient for protecting private or confidential electronic data assets.

<CIT> discloses providing charter-based access to resources using an object model. Charters are defined by an administrator to have certain markings, each marking indicating a control (e.g., permission, credential, qualification, constraint, requirement, etc.) that regulates work under the charter. Users are also associated with markings. A user starts a session to access the system and is authenticated. The system determines charters having markings that the user has, and these charters are provided to the user to select from. Selecting a charter allows the user access to resources associated with the charter, under the controls indicated by the markings. Charters, controls, qualifications, resources, authorizations and links between them can be implemented using an object model. Markings can control session parameters, resource access, user credentials, qualifications, and/or data processing permissions for a group of users, simplifying project definition and revisions to controlling access under the charter.

<CIT> discloses providing an interface between repositories of disparate datasets and computing machine-based entities that seek access to the datasets, and, more specifically, to a computing and data storage platform that facilitates consolidation of one or more datasets, whereby user interfaces may be implemented as computerized tools for presenting summarization of dataset attributes to facilitate discovery, formation, and analysis of interrelated collaborative datasets.

<CIT> discloses implementing fine-grained access control (FGAC) of data stored in a dataset. In response to receiving a data query statement from a user, any representational index exclusions that are relevant to the data query statement are identified, wherein each index exclusion specifies an access restriction to the data. It is then determined whether any of the identified representational index exclusions are to be applied to the data query statement, and if 'yes' then the data query statement is modified before being processed, so that processing of the query takes place by searching the dataset under restriction of the representational index exclusions. The proposed approach allows for easy creation and modification of FGAC privacy rules without introducing performance gaps in processing the data query statements.

The systems, methods, and devices described herein each have several aspects, no single one of which is solely responsible for its desirable attributes. Without limiting the scope of this disclosure, several non-limiting features will now be described briefly.

In general, access to data assets (e.g., also referred to herein as "datasets") may be managed by assigning authentication credentials (e.g., usernames and passwords) to users. Computer administrators may further impose authorization restrictions specifying which users or groups of users can read, write, or modify a dataset. There may not be easy methods of propagating large-scale changes to the restrictions-to change these, an administrator may have to manually change each permission of each dataset. It can be difficult to track or report why users are accessing authorized datasets. It can also be difficult to track or ensure that users are qualified to access authorized datasets.

Embodiments of the present disclosure include computer systems for coordinating and/or providing purpose-based access to datasets. A purpose-based access system may provide structure to previously unstructured governance metadata using data objects (also referred to herein simply as "objects"). Advantageously, through the use of objects, governance may be integrated into an access control framework such that analyst users cannot access data without proceeding though a well-defined process that, e.g.: (<NUM>) improves data owners' visibility into how data is being used and how processing of the data may impact data subjects, (<NUM>) aids in accountability by providing well-defined roles and capturing metadata that is useful for audit, (<NUM>) enables revoking of permissions and time bounds on permissions, among other advantages. Unlike systems that implement only authentication and authorization, these purpose-based access systems can log why authenticated and authorized users access datasets, and ensure that users are authorized to access the datasets for a selected purpose, among other advantages.

The systems and methods discussed herein may provide several advantages including one or more of the following:.

These features and advantages are each discussed further herein, as well as other features and advantages not specifically listed above.

The interactive and dynamic user interfaces described herein are enabled by innovations in efficient interactions between the user interfaces and underlying systems and components. For example, disclosed herein are improved methods of receiving user inputs, translation and delivery of those inputs to various system components, automatic and dynamic execution of complex processes in response to the input delivery, automatic interaction among various components and processes of the system, and automatic and dynamic updating of the user interfaces. The interactions and presentation of data via the interactive user interfaces described herein may accordingly provide cognitive and ergonomic efficiencies and advantages over previous systems.

Various embodiments of the present disclosure provide improvements to various technologies and technological fields. For example, as described above, existing data storage and processing technology (including, e.g., in memory databases) is limited in various ways (e.g., manual data review is slow, costly, and less detailed; data is too voluminous; etc.), and various embodiments of the disclosure provide significant improvements over such technology. Additionally, various embodiments of the present disclosure are inextricably tied to computer technology. In particular, various embodiments rely on detection of user inputs via graphical user interfaces, calculation of updates to displayed electronic data based on those user inputs, automatic processing of related electronic data, and presentation of the updates to displayed information via interactive graphical user interfaces. Such features and others (e.g., processing and analysis of large amounts of electronic data) are intimately tied to, and enabled by, computer technology, and would not exist except for computer technology. For example, the interactions with displayed data described below in reference to various embodiments cannot reasonably be performed by humans alone, without the computer technology upon which they are implemented. Further, the implementation of the various embodiments of the present disclosure via computer technology enables many of the advantages described herein, including more efficient interaction with, and presentation of, various types of electronic data.

Various combinations of the above and below recited features, embodiments, and aspects are also disclosed and contemplated by the present disclosure. Additional embodiments of the disclosure are described below in reference to the appended claims, which may serve as an additional summary of the disclosure.

In various embodiments, systems and/or computer systems are disclosed that comprise a computer readable storage medium having program instructions embodied therewith, and one or more processors configured to execute the program instructions to cause the systems and/or computer systems to perform operations comprising one or more aspects of the above- and/or below-described embodiments (including one or more aspects of the appended claims).

In various embodiments, computer-implemented methods are disclosed in which, by one or more processors executing program instructions, one or more aspects of the above- and/or below-described embodiments (including one or more aspects of the appended claims) are implemented and/or performed.

In various embodiments, computer program products comprising a computer readable storage medium are disclosed, wherein the computer readable storage medium has program instructions embodied therewith, the program instructions executable by one or more processors to cause the one or more processors to perform operations comprising one or more aspects of the above- and/or below-described embodiments (including one or more aspects of the appended claims).

The following drawings and the associated descriptions are provided to illustrate embodiments of the present disclosure and do not limit the scope of the claims. Aspects and many of the attendant advantages of this disclosure will become more readily appreciated as the same become better understood by reference to the following detailed description, when taken in conjunction with the accompanying drawings, wherein:.

Although certain preferred embodiments and examples are disclosed below, inventive subject matter extends beyond the specifically disclosed embodiments to other alternative embodiments and/or uses and to modifications and equivalents thereof. Thus, the scope of the claims appended hereto is not limited by any of the particular embodiments described below. For example, in any method or process disclosed herein, the acts or operations of the method or process may be performed in any suitable sequence and are not necessarily limited to any particular disclosed sequence. Various operations may be described as multiple discrete operations in turn, in a manner that may be helpful in understanding certain embodiments; however, the order of description should not be construed to imply that these operations are order dependent. Additionally, the structures, systems, and/or devices described herein may be embodied as integrated components or as separate components. For purposes of comparing various embodiments, certain aspects and advantages of these embodiments are described. Not necessarily all such aspects or advantages are achieved by any particular embodiment. Thus, for example, various embodiments may be carried out in a manner that achieves or optimizes one advantage or group of advantages as taught herein without necessarily achieving other aspects or advantages as may also be taught or suggested herein.

Embodiments of the present disclosure include computer systems for purpose-based access to datasets, going beyond simple authentication of users, where the purpose-based access is configured such that data governance may be pushed to the forefront. The systems may provide structure to previously unstructured governance metadata using data objects (also referred to herein simply as "objects").

Advantageously, through the use of objects, governance may be integrated into an access control framework such that analyst users cannot access data without proceeding though a well-defined process that, e.g.: (<NUM>) improves data owners' visibility into how data is being used and how processing of the data may impact data subjects, (<NUM>) aids in accountability by providing well-defined roles and capturing metadata that is useful for audit, (<NUM>) enables revoking of permissions and time bounds on permissions, among other advantages. Unlike systems that implement only authentication and authorization, the systems described herein can log why authenticated and authorized users access datasets, and ensure that users are authorized to access the datasets for a selected purpose, among other advantages. This can be accomplished, for example, by capturing a contextual history of data access requests directly in objects associated with the requests.

A computer system or software framework is provided for purpose-based data permissioning within an organization. The system's data permissioning is based on a user's selected purpose, in addition to authentication and authorization. An organization may establish purposes associated with access to datasets (e.g., datasets, folders, etc.). Advantageously, the system may be configured to provide access to a subset of datasets (referred to herein as an "investigation dataset" or "slice") for a specific purpose in a self-contained, dedicated purpose directory (an "investigation workspace"). Advantageously, the investigation dataset includes only the precise portion of data that is needed for a requested purpose (e.g., certain rows and columns of tabular datasets). The system may also control if/when the investigation dataset is updated with later (e.g., updated and/or more recent) versions of data items in the investigation dataset. The investigation dataset and any results derived from the investigation dataset are reproducible (e.g., by an authorized user for that purpose).

In some embodiments, an explorer component allows users that are interested in making purpose-based access requests to datasets to view aggregated and/or summary data regarding available datasets prior to making the purpose-based access request. For example, a guided discovery wizard (or "explorer" user interface) allows a user to view summarized and/or general information regarding datasets and may provide the user options to filter the datasets based on such information and/or even based on parameters of specific data items within the datasets (without exposing the specific data items to the user). Thus, the user may filter the datasets to determine a cohort of datasets including data items that are interesting or useful for the specific purpose.

For example, researchers in many industries are subject to restrictive data access controls, such as may be present to preserve the privacy of personally identifiable information by limiting access to the data. In the pharmaceutical industry, for example, researchers may be required to justify why they need access to a collection of data, which they haven't seen yet, and commit to perform analysis on the data in isolation from other ongoing research. However, in the absence of understanding of the data that is available (e.g., specific patient data, drug trial data, etc.), selecting the appropriate group of data items for the particular research purpose is difficult. Without the data explorer features herein, a researcher may be discouraged from pursuing an investigation, and requesting access to datasets for the specific investigation purpose, due to the large amount of available data that would need to be the authorized for use by the user, much of which may not be relevant to the user's specific purpose. However, as described further below, an explorer module provides a guided data discovery user interface that allows the user to browse summary data in one or more summary datasets. This explorer access prevents the user from viewing the underlying data items (of the ontology datasets), while allowing the user to filter based on characteristics of the datasets and/or data items with the data sets to generate a cohort of datasets that are more directly relevant to their investigation. Thus, when a cohort of relevant datasets is generated with a specific investigation in mind, the purpose-based access request for that cohort of datasets is more likely to be approved by the data owner. In the context of pharmaceutical research, the explorer access may allow the user to select clinical trials based on characteristics of patients (e.g., patients with a heart condition) within those trials and view information regarding quantity of patients with the condition across multiple clinical trials (e.g., different datasets).

In some embodiments, a copy of the original data (e.g., the ontology datasets) may be stored with the research project (without being updated) so others can reproduce the research using the same starting datasets. In some embodiments, data owners may periodically provide updates to datasets via data feeds. For example, a data owner may determine if/when an updated version of the asset (e.g., the dataset with new and/or updated data items) should be made available to users with appropriate purpose-based access request.

In some embodiments, the system may include an object model and generate objects associated with various users interacting with the system in various roles, e.g.: analyst user objects, purpose sponsor objects, and dataset owner objects. The system may further include generating objects associated with purposes and datasets: e.g., purpose objects and dataset objects. The system may further include generating objects associated with access requests: e.g., purpose access request objects that link an analyst user to a purpose, and data access request objects that link datasets to a purpose. The various objects can store metadata associated with various aspects of the purpose-based data access, which may advantageously enable exploration, investigation, reproduction, and auditing. By using the object model, various users can more easily make and propagate large scale changes to the system as compared to, for example, individual editing of user's permissions or tracking access in spreadsheets.

Further, according to various embodiments, various interactive graphical user interfaces are provided for allowing various types of users interact with the systems and methods described herein to, for example, generate, review, and/or modify purpose objects, purpose access request objects, data access request objects, and/or the like.

To facilitate an understanding of the systems and methods discussed herein, several terms are described below. These terms, as well as other terms used herein, should be construed to include the provided descriptions, the ordinary and customary meanings of the terms, and/or any other implied meaning for the respective terms, wherein such construction is consistent with context of the term. Thus, the descriptions below do not limit the meaning of these terms, but only provide example descriptions.

Dataset (also referred to herein as a "data asset," "resources," or "computer resources"): Any data item or group of data items. May include data and items that can be accessed by a user through a computer system. Non-limiting examples include files, folders, computing machines, memory, processors, servers, hard drives, databases, laptops, RSA tokens, etc. Also referred to herein as "resources" or "computer resources". A dataset may include data items in several formants, such as in a tabular format that includes a number of rows and columns of data items and/or in one or more data objects.

Data Object or Object: A data container for information representing specific things that have a number of definable properties. For example, a data object can represent an entity such as a person or user, a place, a group, an organization, a resource, a dataset, a request, a purpose, or other noun. A data object can represent an event that happens at a point in time or for a duration. A data object can represent a document or other unstructured data source such as an e-mail message, a news report, or a written paper or article. Each data object may be associated with a unique identifier that uniquely identifies the data object. The object's attributes (e.g. metadata about the object) may be represented in one or more properties.

Object Type: A type of a data object (e.g., user, dataset, purpose, request, etc.). Object types may be defined by an ontology and may be modified or updated to include additional object types. An object definition (e.g., in an ontology) may include how the object is related to other objects, such as being a sub-object type of another object type (e.g. an agent may be a sub-object type of a person object type), and the properties the object type may have.

In some embodiments, a body of data is conceptually structured according to an object-centric data model represented by ontology. The conceptual data model is independent of any particular database used for durably storing one or more datasets based on the ontology. For example, each object of the conceptual data model may correspond to one or more rows in a relational database or an entry in Lightweight Directory Access Protocol (LDAP) database, or any combination of one or more databases.

The techniques for recording and transforming data in the data management system <NUM> may include maintaining an immutable history of data recording and transformation actions such as uploading a new dataset version to the data management system <NUM> and transforming one dataset version to another dataset version. The immutable history is referred to herein as "the catalog. " The catalog may be stored in a database. Preferably, reads and writes from and to the catalog are performed in the context of ACID-compliant transactions supported by a database management system. For example, the catalog may be stored in a relational database managed by a relational database management system that supports atomic, consistent, isolated, and durable (ACID) transactions.

The catalog can include versioned immutable "datasets. " More specifically, a dataset may encompass an ordered set of conceptual dataset items. The dataset items may be ordered according to their version identifiers recorded in the catalog. Thus, a dataset item may correspond to a particular version of the dataset. A dataset item may represent a snapshot of the dataset at a particular version of the dataset. As a simple example, a version identifier of '<NUM>' may be recorded in the catalog for an initial dataset item of a dataset. If data is later added to the dataset, a version identifier of '<NUM>' may be recorded in the catalog for a second dataset item that conceptually includes the data of the initial dataset item and the added data. In this example, dataset item '<NUM>' may represent the current dataset version and is ordered after dataset item '<NUM>'.

As well as being versioned, a dataset may be immutable. That is, when a new version of the dataset corresponding to a new dataset item is created for the dataset in the system, pre-existing dataset items of the dataset are not overwritten by the new dataset item. In this way, pre-existing dataset items (i.e., pre-existing versions of the dataset) are preserved when a new dataset item is added to the dataset (i.e., when a new version of the dataset is created). Note that supporting immutable datasets is not inconsistent with pruning or deleting dataset items corresponding to old dataset versions. For example, old dataset items may be deleted from the system to conserve data storage space.

A version of dataset may correspond to a successfully committed transaction against the dataset. In these embodiments, a sequence of successfully committed transactions against the dataset corresponds to a sequence of dataset versions of the dataset (i.e., a sequence of dataset items of the dataset).

A transaction against a dataset may add data to the dataset, edit existing data in the dataset, remove existing data from the dataset, or a combination of adding, editing, or removing data. A transaction against a dataset may create a new version of the dataset (i.e., a new dataset item of the dataset) without deleting, removing, or modifying pre-existing dataset items (i.e., without deleting, removing, or modifying pre-existing dataset versions). A successfully committed transaction may correspond to a set of one or more files that contain the data of the dataset item created by the successful transaction. The set of files may be stored in a file system.

In the catalog, a dataset item of a dataset may be identified by the name or identifier of the dataset and the dataset version corresponding to the dataset item. In a preferred embodiment, the dataset version corresponds an identifier assigned to the transaction that created the dataset version. The dataset item may be associated in the catalog with the set of files that contain the data of the dataset item. In a preferred embodiment, the catalog treats the set of files as opaque. That is, the catalog itself may store paths or other identifiers of the set of files but may not otherwise open, read, or write to the files.

In sum, the catalog may store information about datasets. The information may include information identifying different versions (i.e., different dataset items) of the datasets. In association with information identifying a particular version (i.e., a particular dataset item) of a dataset, there may be information identifying one or more files that contain the data of the particular dataset version (i.e., the particular dataset item).

The catalog may store information representing a non-linear history of a dataset. Specifically, the history of a dataset may have different dataset branches. Branching may be used to allow one set of changes to a dataset to be made independent and concurrently of another set of changes to the dataset. The catalog may store branch names in association with dataset version identifiers for identifying dataset items that belong to a particular dataset branch.

<FIG> is a block diagram illustrating an example computer system <NUM> being used by a user <NUM>, and a network <NUM> enabling communication between the various computer systems <NUM>, <NUM>, <NUM>, <NUM>. As shown, the access management system <NUM> and the data management system <NUM> may also be in communication with each other via the network <NUM>. In this example, the access management system <NUM> includes an authentication service <NUM> and an access service <NUM> and the data management system <NUM> includes a data interaction service <NUM> and an investigation workspace <NUM>.

In general, and as further described herein, the authentication service <NUM> may authenticate users who access the system, e.g., via a username and password, and/or other appropriate authentication mechanisms. Also, in general and as further described herein, the access service <NUM> may provide, to various users, purpose-based access to portions of the datasets <NUM> (e.g., data items, datasets, and/or the like, which may be stored in the investigation workspace <NUM> that is stored by the data management system <NUM>), and may also provide various functionalities for permissioning, generating and/or modifying objects (e.g., purpose objects, dataset objects, purpose access request objects, data access request object, various user objects, and/or the like), providing interactive user interfaces, and/or the like. Also, in general and as further described herein, the data interaction service <NUM> may provide various users, such as guided data discovery user interfaces that are part of an explorer module of the data interaction service <NUM> and provides the user an ability to view summary information regarding datasets <NUM> prior to making a purpose-based access request.

As shown in <FIG>, multiple datasets <NUM> are accessible by the data management system <NUM>. As discussed further below, each of these datasets may include a plurality of data items in a tabular (or other) format. For example, the first dataset 130A may include clinical trial data for a first set of patients and dataset 130B may include clinical trial data for a second set of patients. The datasets <NUM> may be stored at separate physical locations (e.g., servers associated with the institution sponsoring the particular clinical trial) and/or may be stored in a common data store (e.g., a hospital database that stores clinical trial data from multiple clinical trials associated with the hospital). Advantageously, and as discussed further herein, the data management system <NUM> is configured to generate an investigation workspace that stores an investigation dataset that is a limited set of data items from the datasets <NUM> (e.g., a slice of the datasets), where access to the investigation datasets is granted in response to a purpose-based access request.

In some embodiments, the access management system <NUM> and the data management system <NUM> may be implemented as a single computing system, and/or various functions or services of the two may be split up and/or arranged differently from that shown in the example computing environment <NUM> of <FIG>. The various services of the data management system <NUM> and access management system <NUM> may be combined and/or separated in additional services, and/or may be implemented in different ones of the various systems of the present disclosure. However, for the purpose of providing a concise description in the present disclosure, the various functionalities are described in reference to the example implementation shown in the computing environment <NUM> of <FIG>.

As used herein, the term "system" generally refers to one or both of the access management system <NUM> and/or data management system <NUM>, but may also include other computer systems of the present disclosure.

<FIG> is a flow diagram illustrating a conceptual overview of certain functionality provided by the access and data management systems. In other embodiments, the access and data management systems may provide fewer or additional functionalities and/or the functions discussed herein may be provided in a different manner. In the example of <FIG>, at block <NUM> (denoted by the circled numeral "one"), the access management and/or data management system <NUM>, refer to hereinafter as "the system", generates summarized datasets <NUM> based on one or more ontology datasets <NUM>. In some embodiments, the ontology datasets <NUM> may be referred to as "golden datasets," which generally represent datasets that are original, unsummarized data. For example, in the context of clinical trial analysis, such as for development of pharmaceuticals, all data items associated with a particular clinical trial may be included in an ontology dataset. These datasets may each be subject to access restrictions that limit users, organizations, devices, etc. that may access the data items of the datasets. Advantageously, the system <NUM> restricts access to the ontology datasets <NUM> by the user <NUM>, while still allowing the user <NUM> to view and interact with summarized information regarding the datasets which is stored as summarized datasets <NUM>. For example, the summarized datasets <NUM> may include counts of data items across a dataset (e.g., the total number of datasets associated with male participants and the total number of datasets associated with female participants), without including information regarding the participants, such as names, identification information, etc..

In block <NUM> of <FIG>, the user <NUM> interacts with a guided data discovery user interface to view portions of the summarized datasets <NUM> and to filter the available datasets based on the summarized datasets <NUM>. An example of filtering datasets based on summarized datasets is provided below with reference to <FIG>, <FIG>, and <FIG>. In some implementations, this "restricted view" of the summarized datasets <NUM> is provided by an explorer functionality/module of the system <NUM>. The user may then request access to the cohort of datasets.

At block <NUM>, the system <NUM> determines sensitivity and/or access restrictions associated with each of the datasets in a requested cohort of datasets. For those datasets requiring some level of authorization prior to granting access (to the user and/or other users indicated in the access request), access requests and authorizations are transmitted to the respective data owners <NUM>.

At block <NUM>, in response to receiving any required authorizations from data owners <NUM>, the system <NUM> may then provision the appropriate datasets for access by the user. In the example of <FIG>, a provisioning process is executed, such as by the system <NUM> and/or a separate provisioning module, to generate the investigation workspace <NUM>. <FIG> provides a further example provisioning process. The investigation workspace <NUM> generally includes a limited set of the ontology datasets <NUM>, such as that are filtered by the selected cohort and the indicated purpose of the investigation. Advantageously, access to the investigation workspace <NUM> does not provide access to the full ontology datasets <NUM>, but only to the particular investigation datasets <NUM> that the user has been approved to access for the indicated purpose. In the example of <FIG>, the investigation workspace <NUM> includes the investigation datasets <NUM>, as well as investigation objects <NUM> that are generated based on the investigation datasets <NUM>.

<FIG> is an example user data discovery user interface <NUM> that may be provided to a user as part of a data exploration workflow (or "data explorer project"). In some embodiments, the data discovery user interface <NUM> is provided to the user after authentication with the system, e.g., via the authorization service <NUM> of <FIG>. Then, summarized datasets (or data explorer datasets) that include summaries of datasets to which the user may be granted access (e.g., responsive to an authorized purpose-based access request) are accessed by the data discovery user interface <NUM>, rather than allowing access to the un-summarized datasets (e.g., the ontology datasets <NUM> in <FIG>). In some embodiments, a group of users is given access to the summarized datasets, such as a group of researchers that are collaborating on an investigation for which additional purpose-based access to un-summarize data items will be requested.

In the example of <FIG>, the guided data discovery user interface <NUM> includes case summary filters <NUM>, case indications filters <NUM>, and cohort statistics <NUM>. The example of <FIG> includes filtering tabs related to cases <NUM>, participants <NUM>, participant attributes <NUM>, and test data <NUM>, which may generally refer to any group of information (e.g., a case, study, trial, etc.) associated with multiple participants. For example, a case may relate to a legal, healthcare, safety, or other group of information that is associated with a common issue or goal. While some example embodiments herein are described in the context of clinical trials (where each clinical trial is generally a "case"), the systems and methods discussed herein are usable with any other types of data. In the context of pharmaceutical investigations, the "cases" in <FIG> may be replaced with "clinical trials," for example.

In the example of <FIG>, with case tab/button <NUM> selected, the user may apply desired filtering criteria to be applied to the summarized datasets. As shown in the cohort statistics <NUM>, the unfiltered available datasets (e.g., those included in a data explorer project to which the user has access to summarized datasets) include <NUM>,<NUM> participants (e.g., patients) across <NUM>,<NUM> cases (e.g., clinical trials). As the user creates filters of the available datasets, the cohort statistics <NUM> are updated, giving the user a substantially real-time indication of how many participants and cases would be included in an investigation workspace based on those current criteria. For example, <FIG> illustrates the guided data discovery user interface <NUM> with filter <NUM> selected, which filters the summarized datasets to include only those with indication <NUM> (e.g., a characteristic of participants). As shown in <FIG>, the cohort statistics 230B are updated to indicate that the number of matching cases has dropped to <NUM> of the <NUM>,<NUM> total available cases. With the decrease in number of cases based on application of "indication <NUM>" filter, the number of remaining participants in this example cohort has reduced to <NUM>,<NUM> out of the initial <NUM>,<NUM>. In response to the user selecting additional or different case level filters via the user interface <NUM>, the cohort statistics are correspondingly updated so the user can get a better sense of how much data would be included in a purpose-based access request based on the current cohort.

<FIG> is an example user interface showing the guided data discovery user interface <NUM>, now with the participants tab/button <NUM> selected for cohort filtering based on characteristics of the remaining participants (e.g., further filtering of the <NUM>,<NUM> participants remaining after the filtering indicated in <FIG>). In the example of <FIG>, filtering may be performed based on participant demographics, such as gender and age group. In other embodiments, additional and/or other demographics and/or other participant characteristics may be included in the participants tab. In the specific example shown in <FIG>, the number of participants in the cohort has been reduced to <NUM>,<NUM>, as shown in the cohort statistics <NUM>, by filtering the summarized datasets to include only female patients by selecting filter <NUM>. In this example, a demographics distribution visualization <NUM> indicating current age distribution of participants in the current cohort (of <NUM>,<NUM> participants and <NUM> cases) is shown. In other embodiments other visualizations of the current cohort may be provided to aid the user in making decisions regarding additional and or fewer filters to explore as part of the guided data discovery. Once the user is satisfied with the selected filters and cohort statistics, such as the total number of participants and/or cases included in the cohort, the user can select the save cohort button <NUM> to initiate the process of generating a purpose-based access request for the un-summarized datasets of the cohort.

<FIG> is an example user interface <NUM> that may be provided to the user upon selecting the save cohort button <NUM> an example of <FIG>. This user interface provides an overview of the sensitivity levels of datasets in the cases remaining in the cohort. Additionally, this user interface may provide an indication of the level of authorization required by the corresponding data owner, or an indication that no authorization from the data owner is needed. In this example, the number of cases in the cohort is <NUM> (of a possible <NUM> cases in the data explorer project), and as indicated in the case sensitivity area <NUM>, the <NUM> cases within the cohort that are part of case code "AB101" (e.g., associated with a particular clinical trial) have a low sensitivity, while the remaining cases that are part of the case codes "XA201" and "YY312" have a high sensitivity. The user may select which of the cases to include in the purpose-based access request. For example, the user may decide that requesting access to highly sensitive data under the case code XA201 may not be necessary, but access to the highly sensitive cases in case code YY312 may be important to the investigation. Thus, the user may select boxes 415A and 415C to include those cases in a purpose-based access request. The user may select the continue button to proceed to another user interface where information regarding the purpose of the investigation request is provided.

<FIG> is an example user-interface where the user provides a title <NUM> and a description <NUM> of the investigation. This information will be provided to any owners of data that is part of the cohort, so those data owners can provide authorization for the user to access the relevant datasets (and/or slices of those datasets) for the indicated purpose.

<FIG> is an example user-interface that displays cohorts, such as the cohort discussed above with reference to <FIG>, that may be attached to a new purpose-based access request. In this example, only a single cohort <NUM> is listed. The user can browse through other cohorts, such as may have been previously created by the user and/or by other users, and initiate the purpose-based access request of any selected cohorts.

<FIG> is an example permissions user interface <NUM> that allows the user to indicate other users and/or groups of users for which different access rights are requested. In this example, three different levels of access are shown. An investigation primary contact is selected in section <NUM>, and associated with a manager role. Optionally, users (e.g., members of an investigation team) may be selected to be associated with an editor role (section <NUM>) or a viewer role (section <NUM>). In some embodiments, the investigation primary contact is, by default, the user that generated the cohort and is making the purpose-based access request. However, the investigation primary contact may be a different individual. In other embodiments, other levels of access privileges may be provided.

<FIG> is an investigation details user-interface <NUM> that allows the user to provide further information regarding the investigation for which purpose-based access is requested. In this example, the user can provide information describing the investigation objective and outcomes in section <NUM>, describing intended usage of outcomes and actions/decisions in section <NUM>, an analysis plan <NUM> in section <NUM>, and may attach an analysis plan in section <NUM>. In other embodiments, different types of information may be provided as part of investigation objectives and outcomes.

<FIG> is a flowchart illustrating one example of a process of provisioning data for access by an authorized user (or user group) for a specific purpose-based examination. In some embodiments, the method of <FIG> is performed by the system <NUM> and/or by a separate investigation bootstrap module. Depending on the embodiment, the process of <FIG> may include fewer or additional blocks and/or may be performed in order different than is illustrated.

Starting at block <NUM>, when a purpose-based access request has been authorized (e.g., in response to a user request for a specific slice of datasets that was generated using a guided data discovery based on summarized datasets), an investigation workspace (e.g., a folder or directory) is created. In some embodiments, an investigation project object is generated and associated with the overall purpose-based investigation.

Next, at block <NUM>, references to the ontology datasets (in the cohort) are added to a temporary directory/folder, without copying the ontology datasets to the investigation workspace. Then, at block <NUM>, the datasets referenced in the temporary directory/folder are filtered based on the cohort for which purpose-based access has been authorized. Thus, the cohort filtering is applied only to the dataset references in the temporary directory/folder, rather than to the ontology datasets.

Moving to block <NUM>, the filtered datasets (e.g., the slice of datasets authorized for purpose-based access) are copied to the investigation workspace. In some embodiments, the datasets are marked with an identifier of the investigation. In some embodiments, configuration files for one or more viewers that may access the investigation workspace may also be generated.

At block <NUM>, investigation objects representative of the filtered datasets may be generated. Example, in the context of clinical trials review, data objects may be created to represent various groupings of data items within the investigation workspace, such as data objects for each clinical trial, patient, treatment type, etc. In some embodiments, each investigation object is marked with an identifier of the investigation and the object identifiers are stored and made available to one or more viewing applications configured to access object-based data.

At block number <NUM>, access to authorized users (e.g., users included in the permissions requests provide via user interface <NUM> of <FIG>) is provided to the filtered datasets stored in the workspace (without providing any access to the ontology datasets), via either a tabular format and/or object-based format. Thus, the authorized users may interact with the slice of data with multiple software applications to develop action items and outcomes associated with the investigation.

<FIG> is an example user-interface showing information regarding multiple versions of an investigation dataset. In this example, the quantity of deployments, datasets, and templates associated with each investigation dataset version are indicated. In this example, each of the investigation datasets includes data items from <NUM> datasets, but the data items within those datasets may have been updated/changed from one version to another. Thus, a user (e.g., an auditor) may regenerate the precise investigation dataset as it was at any point in time. For example, if an earlier state of the investigation dataset is needed, the user could select the create deployment action <NUM> to regenerate the investigation dataset as recorded on July <NUM>, <NUM>.

In general, the object model of the present disclosure provides a framework for purpose-based access to datasets. For example, and as noted above, a given purpose is represented by a purpose object, and is associated with a "project" of the system. Particular datasets, as represented by respective dataset objects, are associated with the purpose/"project" via one or more data access requests, as represented by data access request objects. Particular analyst users, as represented by respective analyst user objects, are associated with the purpose/"project" via one or more purpose access requests, as represented by purpose access request objects. When an analyst user is granted access to a purpose by a purpose sponsor user (e.g., an approval is provided in a purpose access request object associated with or linked to the analyst user object and the purpose object), the analyst user is then able to access all datasets associated with the purpose (e.g., where data access request objects have been approved that associate or link data access request objects to the purpose object). Additionally, purpose sponsor users, as represented by respective purpose sponsor objects, are associated with purpose objects such that the purpose sponsor user can (<NUM>) generate data access request objects that, if approved by appropriate dataset owner users associated with the dataset objects, can associated or link datasets to the purpose, and (<NUM>) review and approve or not approve purpose access request objects. Yet further, dataset owner users, as represented by respective dataset owner objects, are associated with dataset objects such that the dataset object can review and approve or not approve data access requests.

In addition to associating or linking an analyst user object with a purpose object via approval of a purpose access request object, each given purpose access request can be associated with privileges/permissions/authorizations, which may include the extent to which the given analyst user may interact (e.g., read/write/modify/execute/etc.) with the data that they are given access to in the purpose. The privileges/permissions/authorizations may be determined based on an "access type", which may be provided by the analyst user and/or the purpose sponsor user for the purpose access request.

A given analyst user object may be associated with or linked to multiple purpose access request objects and/or purpose objects. A given purpose sponsor object may be associated with or linked to multiple purpose access request objects, purpose objects, and/or data access request objects. A given dataset owner object may be associated with or linked to multiple data access request objects and/or dataset objects. A given purpose object may be associated with or linked to multiple purpose access request objects, data access request objects, dataset objects, and/or analyst user objects. A given dataset object may be associated with or linked to multiple data access request objects, and/or purpose objects. In some implementations, portions of datasets may be associated with or linked to data access request objects and/or purpose objects. As noted above, purpose sponsor users and dataset owner user may assign delegates or administrators to act on their behalf. Such delegates or administrators, in various implementations, may or may not be represented by objects in the system. Thus, in some implementations, multiple purpose sponsor objects (and/or purpose sponsor delegate user objects) may be associated with or linked to a given purpose object, purpose access request object, and/or data access request object. Similarly, in some implementations, multiple dataset owner objects (and/or dataset owner delegate user objects) may be associated with or linked to a given dataset object and/or data access request object.

The various objects of the object model can store metadata associated with various aspects of the purpose-based data access, which may advantageously enable investigation and auditing. For example, each purpose access request object may include a justification or legal basis, evidence or documentation, and/or the like, as metadata/properties of the purpose access request object. As another example, each data access request object may include a legal basis or justification, proportionality information (e.g., ensuring that the scope of the datasets is proportional to the purpose for which it is requested), and/or the like, as metadata/properties of the data access request object. The system may further advantageously use the metadata to generate and/or export various reports, which may be reviewed and edited by users. For example, metadata from a purpose access request object or a data access request object may enable the generation of a report assessing the risk of the purpose access request or dataset access request. As another example, according to various implementations, the system may use metadata from a dataset object and related purpose objects to generate a report informing a dataset owner, or a data subject outside of the organization with an interest in a specific dataset, what purposes the specific dataset is being used for. To enable the generation and/or exportation of reports, the system may provide an API for allowing a data subject to query the system as to how the data subject's data is being used. In various implementations, the API may perform a search of all dataset objects and, for any relevant dataset object found, the API may perform a search around on all relevant purpose objects. Furthermore, reports may advantageously be generated and/or exported according to any appropriate format or template, and as any appropriate filetype (e.g., as a PDF). In various implementations, the system may enable an organization to control and/or limit what purposes are included in various types of reports.

According to various implementations, the object model of the present disclosure provides a number of advantages associated with providing purpose-based access to datasets. For example, the object model can ensure that no analyst user is granted access to datasets except through a purpose, because analyst user objects are not directly linked to any dataset object. As another example, purpose sponsor users can provide oversight regarding all analyst users that can access a given purpose, because analyst users are only associated with a given purpose object via purpose sponsor user approval of particular purpose access request objects. As yet another example, purpose sponsor users can modify datasets that are available in a given purpose/"project" via removal of associations or links with data access request objects and/or dataset objects, and/or requesting additional dataset objects to be associated with or linked to a purpose object via data access request objects. As another example, dataset owner users can provide oversight regarding what purposes have access to which datasets, and whether it is appropriate to provide access to multiple datasets in a given purpose, by approving or not approving data access request objects that can associate or link datasets to particular purposes. As yet another example, and as mentioned above, auditing and review of various data accesses is facilitated by capturing relationships among the various objects, and the metadata/properties captured with the various objects. Further, by using the object model, various users can more easily make and propagate large scale changes to the system as compared to, for example, individual editing of user's permissions or tracking access in spreadsheets. For example, datasets can easily be added to or removed from a given purpose, enabling rapid re-scoping of the data available for a given purpose.

As mentioned above, in various implementations, while specified in the purpose access requests, the system, and/or other service (such as an access control list ("ACL") service) can manage permissions/privileges/authorizations of users with respect to the datasets that the analyst users can access in a given purpose. Thus, according various implementations, for example, an access management system <NUM> with an access service and object model as described herein can be built on top of an existing data management system <NUM>, enabling purpose-based access to the datasets of the data management system <NUM>. For example, in various implementations, the system described herein may be implemented on top of existing access control systems (e.g., geography or role-based restrictions). For example, in various implementations, the system may enable one or more purposes to be associated with an existing role, such that all users with the role would have access to datasets associated with the one or more purposes.

In an example, the purpose request object may be linked to an analyst user object associated with the analyst user, the purpose object may be linked to the purpose request object, the data access request object may be linked to the purpose object, and the dataset object may be linked to the data access request object. In a further example, the dataset may be associated with the purpose object by way of the purpose object being linked to the data access request object, and the data access request object being linked to the dataset object. In yet a further example, the analyst user may be associated with the purpose object by way of the purpose object being linked to the purpose access request object, and the purpose access request object being linked to the analyst user object.

In various implementations, the system may perform additional operations including: receiving an input from the purpose sponsor user requesting to view a graph view of objects associated with the analyst user, and in response to receiving the input, generating a graph view of objects associated with the analyst user. The graph view may include graphical nodes indicative of objects and graphical connectors indicative of links between the objects, wherein the objects associated with the analyst user include: an analyst user object associated with the analyst user, any purpose access request objects associated with the analyst user object, any purpose objects associated with any of the purpose access request objects, any data access request objects associated with any of the purpose objects, and any dataset objects associated with any of the data access request objects. In an example, in the graph view the purpose request object may be linked to the analyst user object, the purpose object may be linked to the purpose request object, the data access request object may be linked to the purpose object, and the dataset object may be linked to the data access request object.

Various embodiments of the present disclosure may be a system, a method, and/or a computer program product at any possible technical detail level of integration. The computer program product may include a computer readable storage medium (or mediums) having computer readable program instructions thereon for causing a processor to carry out aspects of the present disclosure.

For example, the functionality described herein may be performed as software instructions are executed by, and/or in response to software instructions being executed by, one or more hardware processors and/or any other suitable computing devices. The software instructions and/or other executable code may be read from a computer readable storage medium (or mediums).

The computer readable storage medium can be a tangible device that can retain and store data and/or instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device (including any volatile and/or non-volatile electronic storage devices), a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a solid state drive, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing.

Computer readable program instructions (as also referred to herein as, for example, "code," "instructions," "module," "application," "software application," and/or the like) for carrying out operations of the present disclosure may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuitry, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++, or the like, and procedural programming languages, such as the "C" programming language or similar programming languages. Computer readable program instructions may be callable from other instructions or from itself, and/or may be invoked in response to detected events or interrupts. Computer readable program instructions configured for execution on computing devices may be provided on a computer readable storage medium, and/or as a digital download (and may be originally stored in a compressed or installable format that requires installation, decompression or decryption prior to execution) that may then be stored on a computer readable storage medium. Such computer readable program instructions may be stored, partially or fully, on a memory device (e.g., a computer readable storage medium) of the executing computing device, for execution by the computing device. The computer readable program instructions may execute entirely on a user's computer (e.g., the executing computing device), partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present disclosure.

Alternate implementations are included within the scope of the embodiments described herein in which elements or functions may be deleted, executed out of order from that shown, or discussed, including substantially concurrently or in reverse order, depending on the functionality involved as would be understood by those skilled in the art.

These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart(s) and/or block diagram(s) block or blocks.

The remote computer may load the instructions and/or modules into its dynamic memory and send the instructions over a telephone, cable, or optical line using a modem. A modem local to a server computing system may receive the data on the telephone/cable/optical line and use a converter device including the appropriate circuitry to place the data on a bus. The bus may carry the data to a memory, from which a processor may retrieve and execute the instructions. The instructions received by the memory may optionally be stored on a storage device (e.g., a solid state drive) either before or after execution by the computer processor.

In addition, certain blocks may be omitted in some implementations. The methods and processes described herein are also not limited to any particular sequence, and the blocks or states relating thereto can be performed in other sequences that are appropriate.

For example, any of the processes, methods, algorithms, elements, blocks, applications, or other functionality (or portions of functionality) described in the preceding sections may be embodied in, and/or fully or partially automated via, electronic hardware such application-specific processors (e.g., application-specific integrated circuits (ASICs)), programmable processors (e.g., field programmable gate arrays (FPGAs)), application-specific circuitry, and/or the like (any of which may also combine custom hard-wired logic, logic circuits, ASICs, FPGAs, etc. with custom programming/execution of software instructions to accomplish the techniques).

Any of the above-mentioned processors, and/or devices incorporating any of the above-mentioned processors, may be referred to herein as, for example, "computers," "computer devices," "computing devices," "hardware computing devices," "hardware processors," "processing units," and/or the like. Computing devices of the above-embodiments may generally (but not necessarily) be controlled and/or coordinated by operating system software, such as Mac OS, iOS, Android, Chrome OS, Windows OS (e.g., Windows XP, Windows Vista, Windows <NUM>, Windows <NUM>, Windows <NUM>, Windows Server, etc.), Windows CE, Unix, Linux, SunOS, Solaris, Blackberry OS, VxWorks, or other suitable operating systems. In other embodiments, the computing devices may be controlled by a proprietary operating system. Conventional operating systems control and schedule computer processes for execution, perform memory management, provide file system, networking, I/O services, and provide a user interface functionality, such as a graphical user interface ("GUI"), among other things.

For example, <FIG> is a block diagram that illustrates a computer system <NUM> upon which various embodiments may be implemented. Computer system <NUM> includes a bus <NUM> or other communication mechanism for communicating information, and a hardware processor, or multiple processors, <NUM> coupled with bus <NUM> for processing information. Hardware processor(s) <NUM> may be, for example, one or more general purpose microprocessors.

The computer system <NUM> also includes a main memory <NUM>, such as a random access memory (RAM), cache and/or other dynamic storage devices, coupled to bus <NUM> for storing information and instructions to be executed by processor <NUM>. Such instructions, when stored in storage media accessible to processor <NUM>, render computer system <NUM> into a special-purpose machine that is customized to perform the operations specified in the instructions.

The computer system <NUM> further includes a read only memory (ROM) <NUM> or other static storage device coupled to bus <NUM> for storing static information and instructions for processor <NUM>. A storage device <NUM>, such as a magnetic disk, optical disk, or USB thumb drive (Flash drive), etc., is provided and coupled to bus <NUM> for storing information and instructions.

The computer system <NUM> may be coupled via bus <NUM> to a display <NUM>, such as a cathode ray tube (CRT) or LCD display (or touch screen), for displaying information to a computer user. In some embodiments, the same direction information and command selections as cursor control may be implemented via receiving touches on a touch screen without a cursor.

The computer system <NUM> may include a user interface module to implement a GUI that may be stored in a mass storage device as computer executable program instructions that are executed by the computing device(s). Computer system <NUM> may further, as described below, implement the techniques described herein using customized hard-wired logic, one or more ASICs or FPGAs, firmware and/or program logic which in combination with the computer system causes or programs computer system <NUM> to be a special-purpose machine. According to one embodiment, the techniques herein are performed by computer system <NUM> in response to processor(s) <NUM> executing one or more sequences of one or more computer readable program instructions contained in main memory <NUM>. Execution of the sequences of instructions contained in main memory <NUM> causes processor(s) <NUM> to perform the process steps described herein.

Various forms of computer readable storage media may be involved in carrying one or more sequences of one or more computer readable program instructions to processor <NUM> for execution.

The computer system <NUM> also includes a communication interface <NUM> coupled to bus <NUM>. As another example, communication interface <NUM> may be a local area network (LAN) card to provide a data communication connection to a compatible LAN (or WAN component to communicated with a WAN).

The network link <NUM> typically provides data communication through one or more networks to other data devices.

The computer system <NUM> can send messages and receive data, including program code, through the network(s), network link <NUM> and communication interface <NUM>.

As described above, in various embodiments certain functionality may be accessible by a user through a web-based viewer (such as a web browser), or other suitable software program). In such implementations, the user interface may be generated by a server computing system and transmitted to a web browser of the user (e.g., running on the user's computing system). Alternatively, data (e.g., user interface data) necessary for generating the user interface may be provided by the server computing system to the browser, where the user interface may be generated (e.g., the user interface data may be executed by a browser accessing a web service and may be configured to render the user interfaces based on the user interface data). The user may then interact with the user interface through the web-browser. User interfaces of certain implementations may be accessible through one or more dedicated software applications. In certain embodiments, one or more of the computing devices and/or systems of the disclosure may include mobile computing devices, and user interfaces may be accessible through such mobile computing devices (for example, smartphones and/or tablets).

Many variations and modifications may be made to the above-described embodiments, the elements of which are to be understood as being among other acceptable examples. All such modifications and variations are intended to be included herein within the scope of this disclosure. The foregoing description details certain embodiments. It will be appreciated, however, that no matter how detailed the foregoing appears in text, the systems and methods can be practiced in many ways. As is also stated above, it should be noted that the use of particular terminology when describing certain features or aspects of the systems and methods should not be taken to imply that the terminology is being redefined herein to be restricted to including any specific characteristics of the features or aspects of the systems and methods with which that terminology is associated.

Conditional language, such as, among others, "can," "could," "might," or "may," unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments include, while other embodiments do not include, certain features, elements, and/or steps. Thus, such conditional language is not generally intended to imply that features, elements and/or steps are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without user input or prompting, whether these features, elements and/or steps are included or are to be performed in any particular embodiment.

The term "substantially" when used in conjunction with the term "real-time" forms a phrase that will be readily understood by a person of ordinary skill in the art. For example, it is readily understood that such language will include speeds in which no or little delay or waiting is discernible, or where such delay is sufficiently short so as not to be disruptive, irritating, or otherwise vexing to a user.

Conjunctive language such as the phrase "at least one of X, Y, and Z," or "at least one of X, Y, or Z," unless specifically stated otherwise, is to be understood with the context as used in general to convey that an item, term, etc. may be either X, Y, or Z, or a combination thereof. For example, the term "or" is used in its inclusive sense (and not in its exclusive sense) so that when used, for example, to connect a list of elements, the term "or" means one, some, or all of the elements in the list. Thus, such conjunctive language is not generally intended to imply that certain embodiments require at least one of X, at least one of Y, and at least one of Z to each be present.

The term "a" as used herein should be given an inclusive rather than exclusive interpretation. For example, unless specifically noted, the term "a" should not be understood to mean "exactly one" or "one and only one"; instead, the term "a" means "one or more" or "at least one," whether used in the claims or elsewhere in the specification and regardless of uses of quantifiers such as "at least one," "one or more," or "a plurality" elsewhere in the claims or specification.

The term "comprising" as used herein should be given an inclusive rather than exclusive interpretation. For example, a general purpose computer comprising one or more processors should not be interpreted as excluding other computer components, and may possibly include such components as memory, input/output devices, and/or network interfaces, among others.

Claim 1:
A computer-implemented method for granting purpose-based access to electronic datasets, the computer-implemented method comprising, by one or more hardware processors executing program instructions:
receiving, from a user via a data discovery user interface (<NUM>), a request to access individual data items associated with a plurality of datasets (<NUM>), wherein the data discovery user interface displays summarized data (<NUM>) associated with the plurality of datasets and prevents access to the individual data items comprised within the datasets;
wherein each of the datasets is associated with a permission level, wherein at least a first permission level requires authorization from a first owner (<NUM>) of a first dataset associated with the first permission level before individual data items of the first dataset are accessible to the user;
iteratively receiving, from the user via the data discovery user interface, filter criteria (<NUM>, <NUM>) to be applied to the summarized datasets, the filter criteria being usable to determine a cohort of datasets from the plurality of datasets matching the filter criteria, wherein after each change to the filter criteria the data discovery user interface is updated to indicate the cohort of datasets matching the updated filter criteria while preventing access to the individual data items of the datasets matching the filter criteria;
receiving, from the user via the data discovery user interface, an investigation purpose for which access to individual data items of the cohort of datasets matching the filter criteria is requested;
for each dataset of the cohort of datasets matching the filter criteria:
determining a permission level;
determining a data owner of the dataset that is authorized to grant the user access to the dataset;
transmitting an access request to the determined data owner of the dataset requesting authorization for the user to access the dataset for the investigation purpose;
generating an investigation dataset comprising at least a portion of individual data items of datasets for which the respective data owner authorized access; and
providing the user access to the investigation dataset.