STATUS: READY FOR REVIEW
The use of Common Data Elements (CDEs) can facilitate cross study comparisons, data aggregation and meta-analyses, simplify training and operations, improve overall efficiency, promote interoperability between different systems, and improve the quality of data collection. Sheehan et al., 2016
Common data elements (CDEs) are standardised data elements, such as variables and measurements, paired with defined rules for how values should be recorded. They are developed to promote consistency and reuse in data collection across different settings, enabling seamless integration and comparison. This step encourages you to search for relevant CDEs and offers guidance on what to do if no suitable CDE is available.
Short description
As explained in Common Data Elements: Lessons from NIH Experience, a Common Data Element (CDE) is a standardised representation of a variable used in clinical or analytical projects. It includes a clearly defined question and a specified format or set of acceptable responses. Ideally, the CDE should be interpretable by both humans and machines without ambiguity.
To see whether an item can be considered a CDE, the following checklist can be applied:
| # | Question | Explanation | Must be "Yes" for CDE? |
|---|---|---|---|
| 1 | Is it used across studies or datasets? | A CDE should be designed for reuse and interoperability. | ✓ |
| 2 | Does it define a specific variable (e.g. age, blood pressure)? | Not just general data structure, but actual data content. | ✓ |
| 3 | Does it specify how the variable is measured or captured (e.g. question text, field type)? | Helps ensure consistent data entry. | ✓ |
| 4 | Is it documented with metadata (e.g. definition, units, permissible values)? | Enables data reuse and harmonisation. | ✓ |
| 5 | In case of permissible values, does it include standard response values or value sets (e.g. yes/no, coded options)? | Ensures semantic consistency. | ✓ |
| 6 | (Optional but ideal*) Is it linked to an ontology or controlled vocabulary (e.g. SNOMED, LOINC)? | Enhances machine readability. | * |
To illustrate how CDEs can be used, consider the example for the CMS Discharge Disposition element (table below) from the NIH CDE repository. The CDE’s data label is shown in purple, possible response values, such as Home, Hospice or Long-term care are shown in red, and their concept identifiers in yellow. The concept identifiers help annotate (or map) the corresponding response values to ensure (semantic) interoperability and machine-readability. Typically, these machine-readable terms are represented with codes or URL links. For example, the concept “Home” is referred by the NCIT code C18002, which is also represented by a URL. Moreover, this annotation is crucial for integrating CDEs from different sources and allows computers to determine whether elements that appear similar are indeed ontologically matched (conceptually equivalent).
| Data element label | CMS Discharge Disposition | ||
|---|---|---|---|
| Question Text | What was the patient's CMS discharge status code? | ||
| Definition | The CMS code specifying the status of the patient after being discharged from the hospital. | ||
| Data Type | Value List | ||
| PV Labels | PV Definitions | PV Concept Identifiers | PV Terminology Sources |
| Home | A person's permanent place of residence. C18002 | C18002 | NCI Thesaurus |
| Hospice | An establishment that provides palliative and supportive care for terminally ill patients and their families via physical, psychological, social and other forms of care. C53532 | C53532 | NCI Thesaurus |
| Long-term care | A healthcare facility that provides rehabilitative, restorative, and/or ongoing skilled nursing care to patients or residents in need of assistance with activities of daily living. C53530 | C53530 | NCI Thesaurus |
| Left against advice | A designation that a patient has chosen not to heed the directions that medical staff has advised, and has chosen to leave the facility. C99969 | C99969 | NCI Thesaurus |
| ... | ... | ... | ... |
On this page we provide you with resources to help you find CDEs and provide guidance on how to proceed if no CDEs are available. Once you have identified the relevant CDEs for your research you can use them as a starting point to build, for example, your electronic Case Reports Forms (see Metroline step: Design eCRF).
Why is this step important
Benefits of using Common Data Elements are highlighted below.
- Saves time and effort. Reusing well-defined CDEs eliminates the need to create variables from scratch, speeding up study design and eCRF development, and ultimately enabling reuse of eCRFs with incorporated CDEs.
- Facilitates data sharing and pooling. When multiple datasets use the same CDEs, they can be aggregated, compared or analysed together more easily, especially in multi-centre studies or registries.
- Improves data quality. Standardised definitions reduce ambiguity and variation in data entry, helping to minimise errors and increase consistency across sources.
- Supports interoperability. CDEs annotated with ontologies enable semantic alignment between systems, making it easier to integrate and interpret data automatically.
- Aids in meeting potential requirements. CDEs focus on improving interoperability and reusability, key requirements for funding, publishing and regulatory compliance, such as CDISC’s CDASH for clinical trials.
- Leverages community expertise. Many CDEs are developed by domain experts, reviewed by peers and tested in real-world settings, offering reliable, consensus-based definitions.
How to
To promote standardisation, data sharing and interoperability, researchers should start with reusing existing CDEs whenever possible. Follow the steps below to identify and apply suitable CDEs for your study or data collection effort.
Step 1 - Consider your research context
Before searching for CDEs, clarify the following:
- What research domain are you working in (e.g. oncology, neurology, rare diseases)?
- Are you working with a specific disease or population?
- Are you collecting clinical, epidemiological, omics or imaging data?
- Are there any specific measures or methods you’re planning to investigate or implement (e.g. vital signs, COVID-19 Complication Type, Morris Water Maze)
This will help you target the most relevant repositories in the next step.
Setting up a Rare Disease Patient Registry to keep clinical information about patients within a specific disease group (neuromuscular, vascular, etc…) to enable research for new diagnosis, natural history and evaluate effect of treatment strategies.
Step 2 - Finding CDEs
- First, check if there are regulatory or domain specific CDE requirements/recommendations. For example:
- The European Commission’s Common Data elements for Rare Diseases Registration
- The CRDC Standard Data Elements for oncology
- NINDS Common Data Elements for neuroscience
- CDISC’s CDASH for clinical trials
- Second, if no domain specific requirements/recommendations are available or you need additional elements, consider searching for CDEs in a general repository such as the NIH CDE Repository. This repository includes endorsed elements that have been reviewed by the NIH CDE Governance Committee and comply with FAIR principles.
- Third, if you can’t find any CDEs for reuse, ask an expert in the field to help you find appropriate standards or try looking for a well-accepted codebook in, for example, ART-DECOR.
The decision is made to collect data for the patient registry following the Common Data Elements (CDEs) for Rare Diseases, as required by the European Commission.
Step 3 - Reuse, adapt and build upon the CDEs
Once you’ve identified relevant Common Data Elements (CDEs), you can:
- Reuse directly. If the CDE fully meets your needs (it has a clear definition, appropriate value set and proper ontology mappings) use the CDE as-is. This is the most robust path to semantic interoperability and consistency.
- Adapt with care. If a CDE is structurally useful but needs minor changes, for example additional categories or translation, document all modifications clearly in for instance a data dictionary or codebook. Be aware that any adaptations may reduce comparability with other datasets.
Your dataset will likely include CDEs alongside context-specific variables. Augment the CDEs with variables you are missing. Ensure your codebook distinguishes between reused, adapted and new elements.
Whenever possible, reuse or preserve the ontology codes that come with a CDE (e.g. SNOMED CT, LOINC, HPO). This enables machine-readable alignment and integration.
If a CDE does not yet include annotations, such as concept identifiers, as shown in the yellow box in the figure in the Short description, aim to add these annotations yourself. Ensure you document your annotations and adaptations explicitly, and consider sharing your contributions and modifications with the original source of the CDE to support future updates. Failure to properly document such changes can lead to semantic divergence when used by other teams, even if the CDE appears identical at first glance. To learn more about codebooks, see Analyse data semantics.
In addition to the set of common data elements for rare diseases registration, study and disease specific data elements were identified and agreed upon through collaboration among various European Reference Networks (ERNs). These additional elements were determined on a study-to-study basis and included patient-reported outcomes, such as those captured by the OVAMA Questionnaire.
The initial data elements provided by the European Commision Joint Research Centre were not annotated with ontology codes. As part of a European Project, a group of Rare Disease and Data Experts collaboratively made decisions on how to annotate these elements while developing a structured data model. For example, the data element sex was annotated using the NCIT ontology. The label of this element is represented in the table below as NCIT:Sex Code, and its possible values are listed after.
| NCIT:Sex Code: http://purl.obolibrary.org/obo/NCIT_C160908 |
| NCIT:Female: http://purl.obolibrary.org/obo/NCIT_C16576 |
| NCIT:Male: http://purl.obolibrary.org/obo/NCIT_C20197 |
| NCIT:Undetermined: http://purl.obolibrary.org/obo/NCIT_C124294 |
| NCIT:Unknown: http://purl.obolibrary.org/obo/NCIT_C17998 |
Expertise requirements for this step
Experts that may need to be involved, as described in Metroline Step: Build the Team, are described below.
- Researcher. Understands the scientific context of the data being collected.
- Data steward. Ensures the technical accuracy and consistency of how CDEs are applied.
Practical examples from the community
Patient Registries on Rare Diseases
The Joint Research Centre has defined Common Data Elements to be collected by all Rare Disease (RD) registries and collecting them will improve interoperability with other ERN registries that are obligated to collect these data items. So far, 16 minimal Rare Disease data elements have been identified as essential for further research in the field. This list includes the variables to be collected and how they should be annotated.
Training
Relevant training will be added soon.
Suggestions
This page is under construction. Learn more about the contributors here and explore the development process here. If you have any suggestions, visit our How to contribute page to get in touch.