What are Common Data Elements?
A Common Data Element (CDE) is a data element, a question, measurement, or variable, that has been precisely defined with:
- A standard definition of what is being measured
- A standard set of permissible values or units
- A standard name and code
- Documentation of how it is collected
CDEs allow researchers to combine and compare data across registries, studies, and institutions. Without them, a "disease severity" question in your registry may measure something completely different from the same question in a collaborator's study, making the datasets impossible to pool.
Why CDEs matter for your registry
Data pooling: If your registry uses the same CDEs as other registries in your disease space, your combined dataset is dramatically more powerful than either dataset alone.
Regulatory acceptance: FDA increasingly requires or strongly prefers CDEs from registries used to support drug development. The FDA's own CDE repository is the gold standard.
Industry partnerships: Pharmaceutical companies evaluating your registry for trial support will check whether your data elements align with established standards. Proprietary data schemas are a barrier to partnership.
Publication: Journal reviewers evaluate data element choices. Using established, validated CDEs strengthens the methodology section of any paper.
The CDE ecosystem
NIH Common Data Element Repository
The FDA and NIH jointly maintain the CDE Repository, the most important source for CDEs in US-based registries.
cde.nlm.nih.gov, Search by disease, research domain, or data element name. Includes CDEs used in FDA-cleared instruments and NIH funded studies.
NINDS CDE Project
The National Institute of Neurological Disorders and Stroke developed a comprehensive CDE framework now widely used across neurological disease registries. Even if your disease isn't neurological, the NINDS CDE methodology is instructive.
Common Data Elements: Standards and Tools
PhenX Toolkit
PhenX provides standardized measures for phenotypes and exposures. Particularly strong for epidemiological and population health measures.
PROMIS (Patient-Reported Outcomes Measurement Information System)
PROMIS is an NIH-developed library of validated patient-reported outcome measures covering physical, mental, and social health. Use PROMIS instruments rather than writing your own quality-of-life questions.
Key PROMIS domains for rare disease registries:
- Physical Function
- Fatigue
- Pain Interference and Pain Intensity
- Sleep Disturbance
- Anxiety and Depression
- Social Participation
Structuring your data element set
Core (required) vs. supplemental (optional)
Divide your data elements into:
- Core elements: Required for all participants at enrollment and each follow up. Keep this list short, every additional required element reduces completion rates.
- Supplemental elements: Collected when available, or for specific subpopulations (e.g., genetic data only for participants who consent to genotyping).
- Time-stamped longitudinal elements: Collected at defined intervals to track disease progression.
The minimum dataset problem
A common mistake: collecting too many data elements. A 200-question enrollment form drives away participants and produces a dataset with massive missingness.
Design principle: What is the minimum set of data elements that answers your core scientific questions? Start there.
A well-designed rare disease registry often has:
- 15 to 30 core enrollment elements
- 5 to 10 core follow up elements (collected every 6 to 12 months)
- 20 to 50 supplemental elements (collected once or as available)
Disease specific CDEs
For many rare diseases, disease specific CDE sets already exist. Before designing your own, search:
- NORD Registry Database
- Orphanet
- NCI Thesaurus, Standardized cancer and biomedical terminology
- ClinicalTrials.gov, Review outcome measures used in trials in your disease
Data element documentation
For each data element in your registry, document:
| Field | Description |
|---|---|
| Element name | Short, unique identifier |
| Definition | Precise definition of what is being measured |
| Data type | String, integer, date, coded value, etc. |
| Permissible values | For coded fields: the complete value set |
| Unit of measure | For numeric fields |
| Collection method | Self reported, clinician-assessed, EHR-extracted, etc. |
| Source/reference | CDE ID from NIH repository, validated instrument, etc. |
| Collection timepoint | Enrollment, 6-month follow up, etc. |
Checklist
- [ ] Searched NIH CDE Repository for disease specific CDEs
- [ ] Reviewed PROMIS for patient-reported outcome measures
- [ ] Checked PhenX Toolkit for epidemiological measures
- [ ] Identified existing disease specific registries and their data elements
- [ ] Divided elements into core vs. supplemental
- [ ] SAB has reviewed and approved data element set
- [ ] Each element is documented with definition, type, permissible values, and source
- [ ] Pilot-tested questionnaire for completion time and participant comprehension