How to Prepare and Submit Sensitive Data to dbGaP

Q: What happens to participants who refuse re-consent?

Their data are excluded from deposition. In one re-contact study, 5.3 percent of locatable living participants refused and 1.6 percent were too ill, and data from those individuals would not be released, while participants who agreed verbally but never returned written forms also could not be included.

By Dr. Zubair Khalid, DVM, MS, PhD · 2026-11-11

How to Prepare and Submit Sensitive Data to dbGaP

By the end of this guide you will be able to prepare a human genomic study for deposition in the database of Genotypes and Phenotypes (dbGaP), structure your phenotype and genotype files so they pass validation, map each subject to the correct consent group, and hand off a clean package to NIH reviewers. Before you start, have on hand your institutional review board (IRB) protocol and consent forms, your funded grant number, the eRA Commons credentials of the principal investigator, a de-identified phenotype dataset with a data dictionary, and your raw genotype or sequence files.

What dbGaP Is and Who Must Submit

dbGaP is a National Institutes of Health (NIH) sponsored repository that archives, curates, and distributes data from studies of the interaction between genotype and phenotype. Content is organized as a hierarchy of study, phenotype variables and datasets, molecular assay data such as SNP arrays, expression arrays, sequence data, and epigenomic marks, plus analyses and documents. Study metadata and summary-level information are freely viewable by anyone. Individual-level data sit behind a controlled-access application for scientists worldwide [1].

The submission obligation has a clear origin. Since January 2008, NIH has required investigators who receive NIH support to submit de-identified high-throughput genomic data to dbGaP [2]. In practice this means that if your NIH-funded project generated genome-wide genotypes or sequences on human participants, plan for deposition as part of the study workflow rather than as an afterthought at the grant's end. Researchers elsewhere in the life sciences have moved in the same direction on their own. An analysis of 555 bioscience papers at the University of Edinburgh found that the fraction sharing all relevant data rose from 7 percent in 2014 to 45 percent in 2023, and genomic sequence data was shared more often than image data or data on human subjects [3]. Depositing well-documented data is increasingly part of what it means to publish.

Access Tiers: What the Public Sees and What Stays Controlled

dbGaP uses a tiered model. Understanding the tiers tells you exactly what your de-identification work needs to accomplish.

Tier	What it holds	Who can see it
Open	Study description, study design, variable definitions, summary statistics, documents	Anyone, no login
Controlled access, downloadable	Individual-level genotypes, sequences, phenotypes	Approved users after Data Access Committee review
Controlled access, view-only	Individual-level data from general research use studies through the dbGaP Data Browser	Approved users, on-screen only

The dbGaP Data Browser was built because researchers wanted to inspect controlled-access data without a full download request. It provides view-only access to summary information and individual-level genotype and sequence data linked to phenotypic features in the controlled-access tier, and NIH intended it to decrease unnecessary download requests while still supporting responsible genomic data sharing [4]. For you as a submitter, the practical implication is simple. Your individual-level files will be visible to approved users, so de-identification and consent mapping must be correct before anything leaves your lab.

Before You Touch a Data File: Consent, Ethics, and Legal Groundwork

Confirm your consent language covers deposition

The single most consequential decision in a dbGaP submission is whether your participants agreed to it. If your original consent forms explicitly mentioned depositing data in a public controlled-access database, you are usually ready to proceed with documentation of that consent. If they did not, you face a re-consent decision, and participant preferences matter more than many investigators expect.

In one study of 1,340 participants asked to re-consent for dbGaP deposition, 1,159 (86 percent) agreed. Among 365 survey respondents, 69 percent said it was very important and 21 percent said it was somewhat important that they were asked for permission. Most respondents rejected lighter-touch alternatives, with 67 percent finding notification-only unacceptable and 40 percent finding opt-out unacceptable [5]. In other words, many participants view being asked as part of the deal, so a genuine re-consent effort, not a notification letter, is often the ethically stronger path.

Re-consent of an older, inactive cohort is feasible but imperfect. In three population-based lung cancer case-control studies running from 2000 through 2009, researchers identified 2,471 eligible participants. Of these, 627 were deceased and 11 had not given permission to be re-contacted. Among the 1,833 remaining, 42.3 percent provided written consent, 37.0 percent could not be located, 13.7 percent verbally agreed but never returned the written form, 5.3 percent refused, and 1.6 percent were too ill. Locating participants differed by age, race, gender, and case-control status, though once located, re-consent rates did not differ [2]. Budget time and staff for tracing, mailed forms, and phone follow-up if your study predates 2008.

Document your legal basis, especially for international collaborators

Data sharing accelerates research but carries legal obligations around privacy and confidentiality. European legislation on genomic data is often described as counterintuitive, with national rules in individual European Union countries that further specify how genomic data may be handled, and effective sharing requires compliance with European and national law, a clearly defined processing purpose, and a defined legal basis [6]. If your study includes European recruitment sites or European collaborators, work with your institutional privacy office to document the legal basis for secondary use before files are transferred. In the United States, the NIH Genomic Data Sharing policy and your IRB set the framework. When in doubt, an ethical governance perspective supports calibrated access, clear accountability, and sustained public engagement rather than blanket openness for health data [7].

How to Submit Data to dbGaP, Step by Step

The following walkthrough reflects the standard NCBI submission workflow. Exact screen labels change over time, so treat this as the durable sequence and confirm current details in the official dbGaP documentation at https://www.ncbi.nlm.nih.gov/gap.

Step 1. Register the study and establish authorized users

The principal investigator logs into the dbGaP submission portal with NIH eRA Commons credentials and creates a study registration. NIH staff affiliated with your funding institute review the registration. Have these items ready:

Grant number and funding institute
IRB protocol number and approval dates
Title, abstract, and study design description
Names of the PI and any delegated submitters who need portal access

Expected outcome: an accessioned study record with an assigned phs prefix (for example, phs001234) that you will reference in every later file.

Step 2. Define your consent groups

Every human subject in your dataset must be mapped to a consent group that describes what downstream users may do with the data. A common minimal set includes general research use (GRU) for broad approval, plus groups restricted by disease area, use limitations set by the IRB, or participant subpopulations. Build a subject consent file as a plain CSV before anything else, because nearly every later validation check depends on it.

subj_id,consent_group
SUBJ0001,GRU
SUBJ0002,GRU
SUBJ0003,DS-LUNG
SUBJ0004,GRU

Rules to enforce while building this file:

One row per subject, no duplicates.
Subject IDs must match your phenotype and genotype files exactly, including case.
Every consent group must correspond to language that actually appeared in an approved consent form.
Subjects whose consent does not permit sharing are excluded, not relabeled.

A quick integrity check from the command line:

cut -d, -f1 subject_consent.csv | tail -n +2 | sort | uniq -d

Expected output is empty. Any printed ID is a duplicate you must resolve before upload.

Step 3. Prepare phenotype data and a data dictionary

dbGaP expects phenotypes as variables organized into datasets, described by a data dictionary that defines each variable's name, permitted values, and units [1]. Export your de-identified phenotype table with one row per subject and one column per variable. Then write the dictionary, for example:

Variable: HEIGHT_CM
  Description: Measured standing height
  Type: integer
  Units: centimeters
  Permitted range: 100 to 230

Variable: SMOKING_STATUS
  Description: Cigarette smoking status at enrollment
  Type: enumerated
  Values: 1 = never, 2 = former, 3 = current, 9 = unknown

Scrub the phenotype file for identifiers. Remove names, medical record numbers, exact dates of birth, zip codes, and free-text fields that could embed identifiers. Replace service dates with age or relative time where possible. Run a search for your institution's name and common date formats before finalizing.

Step 4. Package the molecular data

Prepare your genotype calls or sequence data in the formats the dbGaP validation pipeline accepts for your assay type. Create checksums so transfer integrity can be verified later.

md5sum *.vcf.gz > md5_checksums.txt
cat md5_checksums.txt

Expected output:

d41d8cd98f00b204e9800998ecf8427e  cohort_chr1.vcf.gz
5d41402abc4b2a76b9719d911017c592  cohort_chr2.vcf.gz

Keep the checksum file with the package. If any file is corrupted during upload, checksum comparison will localize the problem immediately.

Step 5. Upload and run validation

Upload the files through the dbGaP submission portal. The validation pipeline then cross-checks your package. Typical validation findings include subject IDs present in the genotype files but missing from the consent mapping, phenotype values outside the ranges declared in the data dictionary, sex inconsistencies between reported sex and chromosome X genotype patterns, and sample swaps flagged by relationships. Fix each issue, regenerate checksums, and re-upload. Plan for at least one correction cycle. A first pass with zero validation findings is rare even for careful groups.

Step 6. Review, sign off, and release

After validation, you review a pre-release snapshot of how your study will appear. Confirm the study description, variable dictionaries, and consent group labels read correctly from a user's perspective. The PI signs the final release authorization. The controlled-access data then become available to approved researchers, and the open tier becomes publicly browsable, including through the dbGaP Data Browser for general research use studies [4]. Once released, changes are slow and formal, so the review step is your last cheap opportunity to fix metadata.

A Brief Data Repository Comparison

dbGaP is not the only option, and choosing the right venue is part of good research data sharing practice. Modern governance discussions describe health data sharing as a spectrum running from public aggregate datasets to controlled-access repositories, federated analysis, and synthetic data, with durable progress depending on calibrated access and privacy-preserving architectures rather than unrestricted openness [7]. Use this positioning to choose:

dbGaP. The right choice for NIH-supported human genotype and phenotype studies subject to the Genomic Data Sharing policy, and for any human genomic dataset where consent language calls for controlled access [2][1].
Open sequence archives. Appropriate for non-human data or human sequence data whose consent explicitly permits unrestricted release. Confirm consent before assuming this tier applies.
Synthetic or aggregate derivatives. Synthetic datasets can address privacy concerns in data sharing and model training, but quality assessments warn that fidelity and utility scores often miss weaknesses in specific patient subgroups, so validate synthetic derivatives across clinically meaningful strata before offering them as a substitute [8].
Journal-level sharing through data availability statements. Documenting where data live improves completeness. The Edinburgh analysis found that the presence of a data availability statement or preprint sharing correlated with more and better data sharing, particularly in completeness [3].

Practical Tips for a Smooth Submission

These tips come from the recurring friction points in the workflow.

Start consent review at study design, not at submission. Cohorts that planned for deposition from day one never need the tracing exercise described in the lung cancer re-consent study, where more than a third of living eligible participants could not be located [2].
Write the data dictionary while the study is running. Variable definitions written years later invite inconsistencies between the dictionary and the actual data.
Freeze a single master subject ID list. Every file you submit inherits IDs from it, and mismatches are the most common validation failure.
Keep consent group definitions short and concrete. Users see these labels when they apply for access, and vague labels generate access questions for years.
Use the dbGaP Data Browser to study how comparable studies present their metadata. Browsing released general research use studies through the view-only interface is the fastest way to calibrate your own documentation quality [4].
Build in schedule slack. Registration review, validation cycles, and release sign-off each take time, so work backward from any publication or grant milestone.

Common Mistakes and Limitations

Worked sum from 1,833 locatable living participants at a 42.3 percent written consent rate, giving the number who provided written consent.

The most common mistakes in a dbGaP submission are predictable, and each has a direct fix.

Assuming old consent covers deposition. Consent forms written before dbGaP was a household name often say nothing about data sharing. Survey evidence shows participants consider being asked important and reject notification-only approaches [5], so a silent assumption here is both an ethical and a practical error.
Treating re-consent as all-or-nothing. Expect a realistic yield. Even a well-run mailed and phone-based campaign reached written consent from only 42.3 percent of locatable living participants [2]. Design your submission plan to survive partial re-consent, releasing data only for subjects who agreed.
Inconsistent subject identifiers across files. One stray space or case difference in a subject ID creates a cascade of validation findings. The duplicate check in Step 2 and a side-by-side ID comparison between consent, phenotype, and genotype files prevent most of it.
Identifier leakage through free-text phenotype fields. Notes fields, verbatim diagnoses, and rare event combinations can identify individuals. Review every free-text variable and drop or generalize it.
Consent groups that do not match consent forms. Never assign a restriction label the IRB did not approve. Users build analysis plans around these labels, and a mislabeled group is a governance failure, not a formatting one [7].
Skipping checksums. A corrupted transfer looks like a data problem and wastes a validation cycle. The md5sum workflow in Step 4 takes minutes.
Underestimating de-identification scope. Individual-level data in dbGaP are viewable by approved users worldwide, so de-identification standards must be robust, and European-linked studies add a layer of national legal requirements on secondary use [6].
One limitation deserves plain language here. This guide covers submission mechanics and consent practice, not the clinical interpretation of any individual participant's data. Questions about a specific person's results belong with that person's physician.

Frequently Asked Questions

Do I always need to re-consent participants before submitting to dbGaP?

No, but it depends on your original consent language. If your approved consent forms explicitly described deposition of de-identified data into a controlled-access NIH database, documentation of that consent is generally sufficient. If they did not, evidence that 69 percent of re-consented participants rated being asked as very important [5] supports a genuine re-consent effort for studies where the original form is silent.

What is the difference between dbGaP's open tier and controlled access?

The open tier holds study descriptions, variable definitions, documents, and summary statistics that anyone can view. Controlled access holds individual-level genotypes, sequences, and phenotypes, released only to researchers approved through a Data Access Committee application [1].

Can researchers browse my data without downloading it?

Yes, for studies in the general research use category. The dbGaP Data Browser gives approved users view-only access to individual-level genotype and sequence data linked to phenotypes, a middle path between full downloads and summary-only public resources [4].

What kinds of molecular data can go into dbGaP?

dbGaP archives genotype and phenotype study products including SNP array data, expression array data, sequence data, and epigenomic marks, organized with phenotype variables, datasets, analyses, and documents in a study hierarchy [1].

How do I get my data into dbGaP if I am not the PI?

Submissions are managed through the study's principal investigator and the funded NIH institute. Ask your PI to register in the dbGaP submission portal with eRA Commons credentials and to add you as an authorized submitter, then coordinate on the consent mapping, data dictionary, and molecular file package described in the walkthrough.

How do other researchers apply to use the data after release?

Approved scientists submit a controlled-access request describing their proposed use, and the study's Data Access Committee reviews whether the request fits the consent groups you defined. This is why clear, concrete consent group labels during submission pay off for the entire life of the dataset [7].

What happens to participants who refuse re-consent?

Their data are excluded from deposition. In the lung cancer re-contact study, 5.3 percent of locatable living participants refused and 1.6 percent were too ill, and data from those individuals would not be released, while 13.7 percent who agreed verbally but never returned written forms also could not be included [2].

Can I submit synthetic data instead of individual-level data?

Synthetic data can be a useful privacy-preserving supplement, but treat it with care. Quality assessments show that aggregate fidelity metrics can hide subgroup-level weaknesses, so if you provide synthetic derivatives, evaluate them across clinically meaningful strata and keep them clearly labeled as synthetic rather than replacing the controlled-access real data [8].