# Plan a Trusted Research Environment {% hint style="info" %} Apollo and Trusted Research Environments licenses are required to use Trusted Research Environments on the DNAnexus Platform. [Contact DNAnexus Sales](mailto:sales@dnanexus.com) for more information. {% endhint %} Before you create a TRE, you need to make decisions that affect configuration choices available to you later, and prepare the inventory assets for the TRE. Some of those decisions — particularly around the review workflow structure — become permanent once you publish the TRE. ## Prerequisites ### Platform and Organization Requirements * Your organization has licenses for Apollo and TRE. * You are an org member with the **Research Environment Management** permission enabled. An Org Admin can grant this permission when inviting or editing your org membership. ### Data Preparation Requirements Before you can configure the TRE Resource Inventory, you must have four data assets ready in DNAnexus. All assets must reside in projects in the same region as the TRE and be billed to the TRE org. * **Tabular Data Inventory** — An Apollo Dataset record containing the full phenotypic or clinical data dispensed to approved researchers. Ingest this using the [Data Model Loader](/developer/ingesting-data/data-model-loader.md). * **Data Showcase** — An Apollo Dataset record containing a curated, safe-to-view subset of your data for pre-request exploration by authorized users and reviewers. This must be in a **separate DNAnexus project** from your other inventory assets. All authorized users and reviewers receive direct read access to the showcase project, not only through the restricted TRE view but also as a full DNAnexus project they can navigate to directly. Treat the project and everything in it as a semi-public resource. * **File Inventory** — A TSV file you prepare that maps every bulk file to its dispensal rules. * **Data Collections** — A JSON file you prepare that defines the selectable groups researchers see when submitting a request. {% hint style="info" %} Apollo ingestion for the Tabular Data Inventory and Data Showcase requires careful data model design to work correctly with TRE features. Contact [DNAnexus Professional Services](https://www.dnanexus.com/professional-services) for guidance on structuring and ingesting your data before configuring the TRE Resource Inventory. {% endhint %} Contact [DNAnexus Professional Services](https://www.dnanexus.com/professional-services) for assistance preparing the File Inventory and Data Collections files. ## Plan Your Review Workflow The review workflow is the multi-step approval pipeline that a data access request must pass through before a researcher is granted full access to the requested data. You configure the pipeline as a set of named review steps, each assigned to one or more reviewers. Review step configuration is the most consequential planning decision you make. Once you publish a TRE, the pipeline structure is permanently locked — you cannot add or remove steps after publishing. You can still add or remove individual reviewers from existing steps at any time, but the set of steps remains fixed. However, you can rename the steps and edit their descriptions after publishing. The TRE must have at least one review step with at least one reviewer assigned before you can publish it. When a request is submitted, all review steps run in parallel. The system resolves the overall outcome using this priority order: * If any step is rejected, the request transitions to **In Revision** state, and the request owner can revise and resubmit. * If no steps are rejected but any step is still pending, the request remains in review. * If all steps are approved, the request is approved. ### How Many Steps Do You Need? **Single-step review** works well when one team governs all access decisions. All reviewers in the step evaluate requests independently, and any reviewer's decision counts toward that step's outcome. **Multi-step review** is appropriate when separate committees govern different aspects of access governance. For example, an ethics committee and a scientific review committee, or a data governance team and a strategic review team. Both steps must approve for the access request to succeed, and either step can independently reject. ### Example: Single-Step Review ```mermaid flowchart LR A["**Data Access Request Submitted**"] --> B["Data Access Review
Governance team reviewers"] B -->|All approved| C["Access Request Approved"] B -->|Any rejected| D["In Revision"] D -->|Resubmit| B %% Styling classDef submittedNode fill:#66C9F9,stroke:#1F519D,stroke-width:2px,color:#000 classDef reviewNode fill:#1F519D,stroke:#1F519D,stroke-width:2px,color:#fff classDef approvedNode fill:#60F299,stroke:#1F519D,stroke-width:2px,color:#000 classDef revisionNode fill:#66C9F9,stroke:#1F519D,stroke-width:2px,color:#000 %% Apply classes class A submittedNode class B reviewNode class C approvedNode class D revisionNode ``` ### Example: Multi-Step Ethics and Scientific Review Two-step workflows are common when separate committees govern compliance and scientific merit independently. Both steps must approve for the access request to succeed. Either step can reject independently, and any rejection transitions the request to **In Revision** state, allowing the request owner to revise and resubmit. ```mermaid flowchart LR A["**Data Access Request Submitted**"] --> B["Step 1: Ethics Review
Regulatory reviewers"] A --> C["Step 2: Scientific Review
Scientific committee"] B --> D{Decision} C --> D D -->|All approved| E["Access Request Approved"] D -->|Any rejected| F["In Revision"] F -->|Resubmit| A %% Styling classDef submittedNode fill:#66C9F9,stroke:#1F519D,stroke-width:2px,color:#000 classDef reviewNode fill:#1F519D,stroke:#1F519D,stroke-width:2px,color:#fff classDef decisionNode fill:#66C9F9,stroke:#1F519D,stroke-width:2px,color:#000 classDef approvedNode fill:#60F299,stroke:#1F519D,stroke-width:2px,color:#000 classDef revisionNode fill:#66C9F9,stroke:#1F519D,stroke-width:2px,color:#000 %% Apply classes class A submittedNode class B,C reviewNode class D decisionNode class E approvedNode class F revisionNode ``` For step-by-step instructions on creating steps and assigning reviewers in the platform, see [adding review steps and assigning reviewers](/admin/trusted-research-environments/configuring-review-workflow.md). ## Plan Your Data Access Policies Data access policies define the security restrictions the TRE enforces on all researcher projects created from this environment. Unlike review steps, policies can be updated at any time regardless of lifecycle state, and changes take effect immediately on all existing and future projects. Each policy has three enforcement options: * **Enforce on** — The restriction is enforced on all projects, regardless of individual project settings. * **Enforce off** — The restriction is explicitly disabled for all projects. * **Defer to project settings** — Individual project owners control this setting. Choose the configuration that best matches your governance requirements and data sensitivity. {% hint style="info" %} The following policies are the default set available to most orgs. Orgs with additional licenses may see more policies in the platform UI. {% endhint %} | Policy | Description | | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Copy Access** | Control whether users can copy data out of the project. | | **Delete Access** | Define which roles have permission to delete data from the project. | | **Download Access** | Control whether users can download data from the project. | | **File Preview** | Allow users to preview and download file content up to 100 KB. | | **Programmatic Database Access** | Allow programmatic access to databases via apps, HTTPS environments, and API requests. | | **Job Outbound Internet Access** | Allow jobs running within the project to access the public internet. This policy is available at the TRE level only and does not appear in standard DNAnexus project settings. | Most of these policies correspond to the [project data access controls](/getting-started/key-concepts/projects.md#project-data-access-controls) available on any DNAnexus project. TRE policies let you enforce them uniformly across all researcher projects rather than relying on per-project configuration. For step-by-step configuration instructions, see [Step 4 in creating a TRE](/admin/trusted-research-environments/creating-a-tre.md#step-4-configure-data-access-policies) or [updating policies on an active TRE](/admin/trusted-research-environments/managing-tre-lifecycle.md#update-data-access-policies). ## Plan Your Billing Configuration The **Customized Rate Card** setting controls how compute and storage costs are billed to researchers working in TRE-provisioned researcher projects. This setting is permanent: it cannot be changed after the TRE leaves **Draft** state, so decide before you start setup. **Customized Rate Card: No (default)** — Researchers must select their own existing org as the billing account when creating a project from an approved data access request. Standard DNAnexus pricing applies based on the billing org they choose. **Customized Rate Card: Yes** — When a data access request is approved, the platform automatically creates a dedicated org to use as the billing account (also known as a wallet) for the approved request. Pricing for this org is inherited from the pricing model of the TRE org. When the request owner or authorized collaborators create projects associated with the approved data access request, the platform automatically pre-populates the new project's `billTo` field with this org. This means that all projects created under that data access request bill to the same request-specific wallet. {% hint style="warning" %} To publish a TRE with Customized Rate Card set to **Yes**, the organization billing the TRE must have its pricing model established. Contact your DNAnexus account team to confirm before selecting this option. {% endhint %} For the field location in the setup UI, see [Step 1: Create the Research Environment](/admin/trusted-research-environments/creating-a-tre.md#step-1-create-the-research-environment). ## Plan Membership and Visibility TRE membership controls who can discover the environment and who can administer it. Unlike review step structure and billing configuration, these settings can be updated at any time regardless of lifecycle state. **TRE visibility** — A TRE can be restricted to a defined list of Authorized Users, or it can be set to public so that any platform user can discover it. Public TREs are uncommon in practice. Most organizations maintain a restricted list and add users individually or by organization. {% hint style="warning" %} Switching a TRE from restricted to public immediately removes all current Authorized Users from the list. If you later restrict access again, you must re-add users individually. {% endhint %} **TRE Admins vs. Authorized Users** — Being a TRE Admin does not grant Authorized User access. If TRE Admins also need to explore the Data Showcase or submit data access requests, you must add them explicitly as Authorized Users. For step-by-step instructions on adding members, see [managing TRE membership](/admin/trusted-research-environments/configuring-tre-membership.md). --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://documentation.dnanexus.com/admin/trusted-research-environments/planning-a-tre.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.