Data Types and Metadata in a Data Management Plan: What to Describe

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

By the end of this article you will be able to inventory every data type your project will produce, describe each one in funder-ready language, specify the metadata that will make your data reusable, and draft the data types and metadata sections of a data management plan (DMP) that survive reviewer scrutiny. To follow the walkthrough you need a free account on DMPTool.org or a similar DMP tool, the grant solicitation for your proposal, and a rough list of the instruments, assays, and files your study will generate.

If you are preparing for grant proposal planning or working through a research grant writing course, this section of the plan is where most reviewers stop reading carefully. They look for specifics. Vague phrases like "all data will be shared appropriately" signal that the planning has not happened. Specific phrases like "deidentified interview transcripts in plain text with an anonymization codebook" signal the opposite.

The Two Questions Every Funder Asks

A data management plan answers two questions about any dataset you create. First, what is it? That is the data type question. Second, what information travels with it so someone else can use it? That is the metadata question.

The National Institutes of Health (NIH) Data Management and Sharing (DMS) Policy, in effect since 2023, requires most grant applications to include a DMS Plan that details the data type or types to be produced, the resources such as repositories or knowledgebases that will be used for sharing, and a timeline for dissemination [1]. The plan is a planning document, not a legal contract, but reviewers and program officers use it to judge whether sharing is realistic.

Researchers consistently struggle with this section. In a survey of 155 researchers at an academic medical center, 67 percent understood the DMS policy, yet only 47 percent felt comfortable developing a DMS Plan, and only 29 percent had used DMPTool.org. Confidence was lowest for two tasks that sit directly in the data types and metadata territory: identifying an appropriate repository (40 percent) and budgeting for data management and sharing activities (38 percent) [2]. The walkthrough below addresses the first of those gaps directly, and the final step addresses the second.

What Counts as a Data Type in a Data Management Plan

A data type is a category of data with a consistent internal structure, such as whole-genome sequences, clinical laboratory measurements, survey responses, interview transcripts, images, or software. The NIH Scientific Data Sharing website publishes a list of standardized data types, and many funders expect you to name your data types using that vocabulary or explain why your data do not fit it.

The practical test is simple. Two files belong to the same data type if a person familiar with one file could open the other and immediately understand its structure. Two files with identical content but different structures, for example a tabular summary of patient visits and the raw electronic health record extracts behind it, belong to different data types and should be described separately.

Data Types Under the NIH Data Management and Sharing Policy

Under the DMS Policy you must state which of your planned data will be shared and, just as important, which will not, with a scientific justification for anything you withhold [1]. Common categories include:

1. Omics data, meaning genomics, transcriptomics, proteomics, and metabolomics outputs such as sequence reads in FASTQ format or mass spectra
2. Clinical data, including diagnoses, laboratory values, vital signs, and medication records
3. Imaging data, such as MRI volumes, microscopy images, and radiographs
4. Behavioral and survey data, including questionnaire responses and cognitive test scores
5. Qualitative data, including interview and focus group recordings, transcripts, and coding frameworks
6. Device and sensor data, including wearable outputs, electronic patient-reported outcomes, and app interaction logs
7. Administrative and derived data, including analysis code, model outputs, and data dictionaries

The landscape of repositories that accept these types is broad. A 2025 assessment compiled 303 data resources relevant to infectious, allergic, and immune-mediated disease research, 58 of which focus specifically on that domain. Within the subset examined, 64 percent held omics data, 36 percent held clinical data, and a smaller share held biological assay data [1]. That distribution tells you something useful for your plan. Repository coverage is deepest for molecular and clinical data types, and thinner for mixed or novel data types, which means your plan needs to say more about where unusual data will live.

Data Types From Real Study Designs

Abstract categories become concrete when you look at actual protocols. A mixed-methods study of a digital health app for young people with ADHD generates at least four distinct data types: app usage logs, quantitative usability and outcome measures, qualitative interview data, and implementation data collected from health and social care settings [3]. A feasibility study of digital patient-controlled follow-up in palliative cancer care generates weekly electronic symptom assessments on the revised Edmonton Symptom Assessment System, health-related quality of life measures at baseline and follow-up, appointment booking records, and self-management website interaction data [4]. A qualitative study of women with recurrent urinary tract infections generates focus group audio recordings, anonymized transcripts, topic guides co-produced with a theoretical framework, and thematic analysis outputs [5].

Notice what each of those lists does. It names the instrument, the collection frequency, and the file form. That is the level of description reviewers expect, and it is the level at which metadata decisions become possible.

What Metadata Means and Why Reviewers Care

Metadata is structured information about your data that makes it findable, understandable, and reusable by people who did not collect it. It answers questions the data file itself cannot: who collected this, when, with what instrument, under what protocol, in what units, with what permissions, and how does this file relate to the others?

The FAIR principles, which stand for Findable, Accessible, Interoperable, and Reusable, are the reference standard here. A recent template developed for the NIH HEAL Initiative explicitly organizes its guidance around implementing common data elements, standardizing metadata, protecting sensitive information, and selecting repositories that support FAIR sharing [6]. When your plan states a named metadata standard rather than a promise to "document everything," you are demonstrating FAIR compliance in advance.

Descriptive, Structural, and Administrative Metadata

Metadata falls into three working categories, and a strong plan touches all three.

Descriptive metadata describes the content for discovery. For a clinical dataset this includes study title, condition studied, eligibility criteria, and variable definitions. For a sequencing dataset it includes organism, tissue, platform, and experimental design.

Structural metadata describes the internal organization. This is the file format, the column definitions, the units, the coded values, and the relationships between tables. A data dictionary is structural metadata.

Administrative metadata describes the context of stewardship. This includes the responsible person, the license, the embargo date, access restrictions, consent terms, and provenance, meaning the record of how the data were derived.

Metadata Standards and Common Data Elements

A metadata standard is a published, agreed schema for a data type. Common data elements are agreed variable definitions, such as a standard way to record pain intensity, so that results can be combined across studies. The HEAL template work emphasizes that multisource studies need structured guidance on common data elements precisely because chronic pain and substance use research integrates clinical, behavioral, and omics data that arrive in incompatible forms [6].

Standardized documentation improves data quality in practice, not just in principle. In a dental hospital service, introducing four standardized proforma templates at the referral, assessment, treatment planning, and review stages enhanced compliance with local procedures, improved consistency in clinical documentation, and enabled more robust data collection and analysis [7]. A DMP does for your dataset what those proformas did for that clinic. It fixes the structure before collection starts, when change is cheap.

Data Types Metadata Data Management Plan Step by Step

This walkthrough produces a complete data types and metadata section. Work through the eight steps in order. Each step includes what to write and what the output should look like.

Step 1: Inventory Every File Type Your Project Will Create

List every instrument, assay, and collection activity in your protocol, then list the file each produces. Do this before opening DMPTool, because the tool asks questions your inventory already answers.

A useful inventory lives in a plain text or spreadsheet table with four columns: activity, file type, approximate volume, and who generates it. For a mixed-methods digital health study the inventory might start like this:

Activity                  File type              Volume        Generated by
Baseline questionnaire    REDCap CSV export      ~2 MB         Study coordinator
Weekly symptom scores     App backend JSON       ~50 MB total  App platform
Exit interviews           WAV audio + DOCX       ~30 GB total  Qualitative team
Usability session         Screen recording MP4   ~5 GB total   Research assistant
Analysis pipeline         Python scripts         <1 MB         Data analyst

The common error at this step is forgetting derived data. Your analysis code, model outputs, and processed datasets are data too, and the DMS Policy expects them to be addressed or their exclusion justified.

Step 2: Map Each Data Type to a Funder-Recognized Category

Take your inventory and assign each row to a recognized category from your funder's list. For NIH applications, use the NIH Scientific Data Sharing data type vocabulary. If a data type does not fit, say so plainly and describe it in your own words rather than forcing a label.

What you write in the plan looks like this:

Data types to be generated and shared:
1. Individual-level survey data (behavioral and social sciences survey data).
   Baseline and follow-up questionnaires administered in REDCap,
   exported as CSV. Shared in deidentified form.
2. Digital device-derived data (wearable and app interaction data).
   Weekly electronic symptom assessments and app usage logs exported
   as JSON. Shared in aggregated and deidentified form.
3. Qualitative interview transcripts (qualitative social and behavioral
   data). Audio recordings transcribed verbatim, transcripts shared in
   deidentified form. Audio recordings not shared, with justification
   in the sensitive data section.

Notice that item 3 names a data type and immediately flags the part that will not be shared. The DMS Policy requires a scientific justification for any planned data you do not share, so writing that justification while you draft, rather than after a reviewer asks, saves a revision cycle [1].

Step 3: Name Your Formats and Standards Explicitly

For each data type, state the file format and, where one exists, the relevant metadata or reporting standard. The minimum viable sentence in a plan follows this pattern: "X data will be collected in Y format and documented using Z standard."

Where standards exist, name them. Sequencing data pair FASTQ files with MIxS or community-specific checklists. Imaging data use DICOM or OME-TIFF conventions. Proteomics deposits follow PRIDE requirements. Survey and social science data are well served by Data Documentation Initiative (DDI) metadata. Qualitative data benefit from a shared codebook and a documented analysis framework, and studies routinely publish their frameworks, as a recent thematic study did by naming the Theoretical Domains Framework that structured its topic guides [5].

If your field has no standard, that is not a problem for your plan. It is an instruction to write more detail yourself, which Step 4 handles.

Step 4: Write the Metadata Section With a Concrete Example

The metadata section of your plan should answer five questions: what metadata will be captured, using what standard or schema, at what point in the workflow, by whom, and where it will be stored for the long term.

The strongest plans include a small worked example of the metadata record. Here is a compact JSON-style record for one row of the survey dataset in Step 2, using a README-plus-dictionary approach that works in any field:

{
  "dataset_title": "SmartCare baseline survey, cohort 1",
  "doi": "assigned on deposit",
  "creator": "Study PI and data manager, ORCID iDs listed",
  "creation_date": "2027-03-15",
  "study_design": "Prospective longitudinal cohort",
  "collection_instrument": "REDCap survey v2.1, ID 4471",
  "variables_documented_in": "data_dictionary_cohort1.csv",
  "standard_followed": "DDI Codebook 2.5 variable-level metadata",
  "access_level": "controlled, via data use agreement",
  "consent_basis": "written informed consent for broad sharing",
  "license": "CC BY 4.0",
  "related_resources": ["analysis code repository", "protocol paper"]
}

Pair that record with a data dictionary. A data dictionary is one row per variable with the variable name, the label, the allowed values, and the units. For a pain research study that adopts common data elements, the dictionary would carry the agreed definition of each pain measure rather than a local wording, which is exactly the interoperability move the HEAL template guidance promotes [6].

What the finished plan text looks like:

Metadata:
All shared datasets will be accompanied by (a) a README file in plain
text describing study context, file inventory, and provenance, and
(b) a variable-level data dictionary in CSV. Survey variables will be
mapped to common data elements adopted by the funding initiative
where available. Metadata will be created at the point of collection
by study coordinators, reviewed by the data manager at each data
lock, and deposited in the repository alongside the data in a
machine-readable format (JSON) plus a human-readable version.

The most common failure in this section is writing "metadata will follow established standards" without naming a single one. If you cannot name a standard, name the fields. A reviewer can evaluate a field list. They cannot evaluate a promise.

Step 5: Choose Repositories That Accept Your Data Type and Metadata

A repository is a curated service that accepts data deposits, assigns persistent identifiers, stores metadata, and enforces access policies. Your plan should name a specific repository for each data type and say why it fits.

The choice is where many researchers feel least confident, and the survey evidence backs that up, with only 40 percent of respondents at one academic medical center confident in identifying appropriate repositories [2]. There is a practical remedy. Discipline-specific resource lists exist for exactly this purpose. For infectious disease work, NIAID maintains a compiled list of data resources that researchers can use when preparing DMS Plans, developed through expert recommendation and structured questionnaires assessing submission support [1]. Similar community lists exist for most biomedical domains, and the DMPTool template library embeds funder-specific guidance, including templates adapted for particular initiatives such as the NIH HEAL template built from the NIH-GEN template with policy-specific guidance [6].

How to evaluate a candidate repository, in order:

1. Scope. Does the repository accept your data type at all?
2. Persistent identifiers. Does it assign DOIs or equivalent?
3. Metadata. Does it support your standard, or at minimum allow a machine-readable metadata upload?
4. Access control. Can it enforce controlled access if your data are sensitive?
5. Sustainability. Is it funded by an institution, consortium, or funder rather than a single grant?
6. Cost. Does it charge deposit fees your budget can cover?

What the plan text looks like:

Data sharing:
Deidentified survey and device data will be deposited in [named
repository], which accepts behavioral data, assigns DOIs, supports
structured metadata upload, and offers controlled access tiers.
Analysis code will be deposited in a public code repository with a
tagged release at the time of each associated publication. No
proprietary repositories will be used.

Step 6: Set the Sharing Timeline and Version Policy

The DMS Policy expects a dissemination timeline, and reviewers read this part closely [1]. State when each data type becomes available, typically on publication or at the end of the award, and how updates are handled. Versioning policy is part of metadata: name your versioning scheme, for example semantic versioning of datasets with a change log in the README, and say who maintains it.

Step 7: Address Sensitive Data and Controlled Access

Human subjects data, including anything linking participants to health conditions, require explicit handling language. The HEAL template exists partly because chronic pain and substance use research combines diverse data types with varying sharing restrictions, and its structured guidance covers standardizing metadata while protecting sensitive information [6]. Your plan should distinguish three things clearly:

1. What is shared openly, for example fully deidentified analytical datasets
2. What is shared under controlled access, for example coded data with a key held by the institution
3. What is not shared at all, for example raw audio recordings where deidentification is impossible

Deidentification is a design decision, not a cleanup step. Decide during grant proposal planning which identifier fields will be removed or recoded, and reflect those decisions in your data dictionary so the deidentified files and their metadata stay consistent.

Step 8: Budget for It and Finalize

Data management and sharing costs are allowable in NIH budgets. Cover personnel time for curation, repository fees where they apply, and secure storage for restricted data. The survey evidence shows budgeting is a weak point, with only 38 percent of researchers confident in it and 68 percent perceiving plan execution as burdensome [2]. Budgeting realistically during planning, rather than discovering costs at deposit time, is the single most effective way to reduce that burden.

Then run a final check. Read your data types section and ask, for every line, whether a stranger could locate the right file, understand its structure, and reuse it. If any line fails, add the missing format, standard, or dictionary reference.

Quick-Reference Table: Data Types, Example Formats, and Metadata Documentation

Data Types Metadata Data Management Plan Tips

These are the moves that separate strong plans from weak ones, drawn from what the guidance literature and institutional experience actually report.

Use a template with structured guidance. Templates reduce drafting time and prevent omissions. The DMPTool hosts funder-specific templates, and specialized templates now exist for complex multisource programs, which the HEAL template demonstrates by adapting a general NIH template into domain-specific guidance for diverse data types and sharing restrictions [6]. In the survey of researcher readiness, 87 percent of respondents requested tailored templates, which tells you the demand and the value are both real [2].

Adopt common data elements early. If your funder or research network maintains a set of common data elements, mapping your variables to them at design time makes cross-study comparison possible and removes a huge retrofitting burden later.

Fix the documentation structure before collection starts. The hypodontia proforma work shows the payoff of standardized documentation templates: better compliance, more consistent records, and stronger downstream analysis [7]. Apply the same idea to your data capture instruments before the first participant is enrolled.

Describe your analysis methods metadata too. For qualitative components, name the analysis approach, the framework, and the coding process in the plan. Studies do this in their protocols anyway, as when a qualitative study states its thematic analysis and its use of the Theoretical Domains Framework to structure topic guides [5], and a DMP can simply point to that structure.

Document iterative data generation explicitly. Co-design and implementation studies generate data at every cycle, not just at the end. A living lab study of a digital prescribing workflow captured workshop recordings across four thematic sprints in three regions and analyzed them with reflexive thematic analysis [8]. If your project works that way, your DMP should list the cycle artifacts, such as workshop recordings, design notes, and adapted workflows, as named data types with their own sharing decisions.

Test your plan the way methods guidance gets tested. Guidance development literature emphasizes testing draft guidance with real users before release, a step that appears repeatedly in frameworks for developing methods guidance [9]. The cheap version for a DMP is to hand your draft to a colleague outside your subfield and ask whether they could find and interpret each dataset from your description alone.

Common Mistakes and Limitations

These are the errors reviewers see most often, each with the practical fix.

Describing a topic instead of a dataset. Writing "we will collect genomic data on cancer" is a topic. Writing "whole-exome sequences from 200 tumor-normal pairs as CRAM files with variant calls as VCF" is a dataset. Reviewers reward the second.

Omitting derived data. Analysis code, processed datasets, and model outputs are data. List them or justify their exclusion.

Promising metadata without naming a standard or fields. "Established standards" is unassessable. Name the schema, or list the fields your data dictionary will carry.

Ignoring the no-share justification requirement. The DMS Policy requires a scientific justification for data you do not plan to share [1]. Leaving it out invites a revision request.

Treating deidentification as an afterthought. Decide identifier handling, coding schemes, and disclosure controls during grant proposal planning, then encode them in your metadata so files and documentation stay aligned [6].

Assuming any repository will do. Repository fit is data-type specific, and confidence in this choice is measurably low among researchers [2]. Match repository scope, metadata support, and access tiers to each data type rather than defaulting to a generalist store.

Leaving the budget empty. Curation time and repository fees are real costs, and budgeting confidence is one of the two weakest self-reported skills among researchers facing the DMS Policy [2]. Put line items in the grant budget.

Writing a plan you cannot execute. A plan is a commitment reviewers will revisit. One limitation applies to everything above: real projects generate surprises, and a plan drafted at proposal time is a best estimate, not a guarantee. Individual projects differ in their data governance requirements, and your institutional research data office or library is the right partner for plan-specific questions, a support role that institutional readiness studies identify as central to compliance [2].

Frequently Asked Questions

What is the difference between data types and metadata in a data management plan?

Data types describe what the data are, such as genomic sequences, survey responses, or interview transcripts. Metadata describes the structured information about those data, such as variable definitions, collection dates, and access terms. A complete plan needs both, because reusable data requires knowing what it is and everything needed to interpret it.

How much detail do I need about metadata in a DMP?

Enough that a stranger could locate the right file and interpret it correctly. Name the metadata standard if one exists, or list the fields your data dictionary will carry if one does not, and state who creates the metadata and when in the workflow.

Do I need to describe qualitative data like interview recordings in a DMP?

Yes. List recordings, transcripts, topic guides, and codebooks as distinct items, then state which will be shared. Many plans share deidentified transcripts while withholding audio recordings, with the withholding justified in the sensitive data section.

What metadata standard should I use if my field has none?

Use a general schema for discovery metadata, write a variable-level data dictionary in a tabular format, include a README with provenance, and deposit the metadata in a machine-readable form alongside the data. Saying this explicitly in the plan is stronger than naming nothing.

Can I change my data management plan after the grant is awarded?

Yes, plans are expectations rather than fixed contracts, and approved plans can be updated as projects evolve. Changes should be communicated to the awarding institution, and your plan should itself describe a versioning approach for datasets so updates are traceable.

How do I describe metadata for human subject data without exposing participants?

Describe the structure and variables in full, but withhold direct identifiers from the shared metadata itself. Use coded identifiers, state where the key is held, and note that the metadata record in a controlled access repository will describe the access conditions without listing identifiable fields.

Is a data management plan required for every NIH grant?

Most NIH grant applications that generate scientific data must include a DMS Plan, though the requirement does not apply to projects that do not generate data, such as some training or conference awards. Check the funding opportunity and the policy's exceptions before you draft.

What tools can help me write a data management plan?

DMPTool.org provides free funder-templated plans with embedded guidance, and institutional research data offices often offer consultation and discipline-specific templates. Adoption of structured templates is still low in many settings, so using one early puts you ahead of the typical drafting process.

Sources

1. Infectious, Allergic, and Immune-Mediated Disease Data Resources: a Landscape Overview and Subset Assessment.
2. Supporting researcher compliance: assessing institutional readiness for the 2023 NIH Data Management and Sharing Policy.
3. Co-development, initial evaluation and implementation of a digital health intervention (SmartADHD) for young people (aged 16-30) with attention deficit hyperactivity disorder, including optimisation for sustainable delivery via health and social care settings: protocol for a mixed-methods study.
4. Digital Patient-Controlled Follow-Up in Palliative Cancer Care: Protocol for a Mixed Methods Feasibility Study.
5. Women's Experiences of Recurrent UTIs: A Qualitative Study of Preventive Management and Decision Support Needs.
6. Navigating the new NIH Data Management Sharing plan: the NIH HEAL Initiative Data2Action DMPTool template.
7. Standardised proformas for the management of hypodontia patients: A new standard for clinical documentation.
8. Using a Living Lab to Refine an Electronic Prescribing Workflow: Insights From the eRIKA Project.
9. Developing methods guidance for health researchers: literature review of proposed and applied strategies.