Plan a Trusted Research Environment
Understand the prerequisites and planning decisions required before creating a Trusted Research Environment on the DNAnexus Platform.
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 a TRE license and an Apollo license if your TRE includes a Data Showcase or Tabular Data Inventory.
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, prepare the data assets for the inventory mode you plan to support. All assets must reside in projects in the same region as the TRE and be billed to the TRE org.
Prepare the following assets as needed:
File Inventory - Required, A TSV file that maps every bulk file to its dispensal rules. This asset is required for every TRE inventory.
Data Collections - Required, A JSON file that defines the selectable groups researchers see when submitting a request. This asset is required for every TRE inventory.
Tabular Data Inventory - Optional, An Apollo Dataset record containing the full phenotypic or clinical data dispensed to approved researchers. Ingest this using the Data Model Loader.
Data Showcase - Optional, An Apollo Dataset record containing a curated, safe-to-view subset of your data for pre-request exploration by authorized users and reviewers.
Contact DNAnexus 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
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.
For step-by-step instructions on creating steps and assigning reviewers in the platform, see adding review steps and assigning reviewers.
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.
Copy Access
Control whether users can copy data out of the project.
Delete Access
Control which roles have permission to delete data from the project.
Download Access
Control whether users can download data from the project.
File Preview
Control whether users can 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 only at the TRE level and does not appear in standard DNAnexus project settings.
Most of these policies correspond to the project data access controls available on any DNAnexus project. Use TRE policies to enforce them uniformly across all researcher projects instead of relying on per-project configuration. For step-by-step configuration instructions, see Step 4 in creating a TRE or updating policies on an active TRE.
Plan Your TRE Features
TRE features are optional behavioral controls that go beyond access policies and affect how researchers interact with the TRE.
Enforce Full Set Selection
When enabled, this feature requires every data access request submitted to the TRE to include all participants — cohort filtering is disabled. Researchers cannot apply participant filters or access the Data Showcase for cohort preview. Data collection selection remains available, but the participant population cannot be narrowed.
This setting is appropriate when your governance policy mandates that researchers receive full-cohort data without the ability to filter by participant characteristics — for example, when data use agreements require complete coverage, or when statistical integrity depends on an unfiltered population.
This setting is permanent. It can only be configured while the TRE is in Draft state and cannot be changed or disabled after the TRE is published. Make this decision before you start setup.
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.
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.
For the field location in the setup UI, see 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.
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.
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.
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.
Last updated
Was this helpful?