NIH expects a short Data Management and Sharing Plan with most applications that generate scientific data. This guide walks through the six elements, gives a worked outline for a demo clinical study, and flags what reviewers and program officers tend to look for.
Free sandbox · No credit card · 21 CFR Part 11 aligned
Data type
Participant-level clinical and PRO data
Related tools, software and code
EDC, analysis scripts
Standards
Data dictionary, SDTM
Preservation, access and timelines
Repository to confirm
Access, distribution or reuse considerations
Consent language check
Oversight
Named role
The short version
The policy
The DMS Policy (notice NOT-OD-21-013, with supplemental guidance in related notices) asks NIH-funded researchers to plan, up front, how they will manage and share the scientific data their project produces. It applies broadly: not just clinical trials, but any funded research that generates scientific data. Training grants, infrastructure and other non-research activities fall outside. The policy took effect for applications with due dates on or after 25 January 2023.
The plan is submitted with the application and assessed by NIH staff, not scored by peer reviewers as part of the merit rating, as the policy is generally described. Reasonable costs of data management and sharing can usually be requested in the budget. If you are awarded, the approved plan is expected to be followed, and changes are reported. Check the current NIH notices for how plan changes, costs and reporting work for your award type.
NIH expects data to be shared as soon as possible, and no later than the time of an associated publication or the end of the award period, whichever comes first. Sharing does not mean sharing everything with everyone: human participant data may need controlled access, and the plan is where you explain how you protect participants while still making the data usable. If you are a PI planning a clinical study, our page on clinical trial software for NIH-funded investigators covers the software side of the same project.
Do not confuse them
Two documents have similar names. A clinical data management plan (see our data management plan template) is an operational document: who enters data, how queries are handled, how the database is locked. It lives inside the study and is usually long. The NIH Data Management and Sharing Plan is a funder-facing, short document that says what data will exist, what standards apply, where it will be kept, and how others will get access.
They should agree. If your NIH plan says data will be exported with a data dictionary and deposited in a named repository after database lock, your operational plan should contain the steps that make that true. Writing the NIH plan after you have sketched the operational one saves rework. For the lock step see database lock and, for the data dictionary, the codebook generator.
Element by element
| Element | Question it answers | What to be specific about |
|---|---|---|
| 1. Data type | What data will you generate and which will you share? | Categories, approximate volume, the level (participant-level, aggregated) and what you will not share and why |
| 2. Related tools, software and code | What is needed to access or use the data? | Named software, versions where relevant, and where analysis code will live |
| 3. Standards | What formats, vocabularies and metadata will you use? | Data dictionary, controlled terms, CDISC or other community standards where they exist |
| 4. Data preservation, access and timelines | Where will data be kept and when will it be available? | Named repository, how long it will be kept, the date of release relative to publication |
| 5. Access, distribution or reuse considerations | What limits apply and how are participants protected? | Consent language, de-identification, controlled access, data use agreements, regulatory limits |
| 6. Oversight of data management and sharing | Who is responsible and how is it checked? | A named role, a review cadence, and how compliance is monitored |
Element names follow the NIH policy as commonly described. Use the wording in the current NIH notices and funding opportunity when you write.
Worked outline
Below is an outline for an invented study, DEMO-WALK-01, a randomized trial of a walking programme in adults with knee osteoarthritis, 120 participants, two sites, 12-month follow-up. The numbers and names are illustrative. Replace every statement with something your team will actually do.
The study will generate participant-level clinical data (demographics, medical history, pain and function questionnaires, adverse events), study-visit measurements, and a de-identified analysis dataset. Approximately 120 participants across 12 months will produce a dataset of modest size (well under a gigabyte). We will share the final de-identified analysis dataset, the data dictionary and the protocol. We will not share direct identifiers or consent documents.
Data are collected in an electronic data capture system with a field-level audit trail. Exports are in CSV and Excel with a data dictionary. Analysis is performed in R; analysis scripts and a README will be released in a public code repository at the time of publication. No proprietary software is needed to read the shared data.
Variables are documented in a data dictionary that lists name, label, type, units, allowed values and form of origin. Adverse events use a standard coding dictionary chosen by the study team. Where applicable we will provide datasets mapped to CDISC SDTM. Metadata will follow the repository's submission template.
The de-identified dataset will be deposited in [a named generalist or domain repository chosen from NIH's list of desirable characteristics] no later than the time of publication of the primary results and in any case before the end of the award. The repository assigns a persistent identifier. The research team will retain a copy in the study data system for the period required by the sponsor and institution.
The consent form states that de-identified data may be shared with other researchers. Direct identifiers and dates are removed or shifted before deposit. Because knee-osteoarthritis data with few rare covariates carries a limited re-identification risk, access will be through the repository's standard data-use terms; if the repository supports controlled access we will use it. No additional restrictions are planned.
The principal investigator is responsible for the plan. A named data manager checks the dictionary and the de-identified dataset before deposit. The team reviews progress against the plan at each quarterly meeting and records any deviation. The institution's research data office reviews the plan on award.
Review before submission
Program staff read many of these. Plans tend to fail on vagueness, not on length.
Write the repository you will use, or the criteria you will use to choose one. "A public repository" is not specific enough.
State release "by the time of the primary publication" or a month, not "when appropriate".
Confirm the informed consent allows the sharing you describe; if it does not, say what will change.
If a standard does not exist for your data, say so and describe what you will do instead.
Oversight needs a person or office, not a committee in the abstract.
De-identification, curation and repository fees cost time and money; ask your grants office how to include them.
Variables, formats and timelines should match. See data validation plan template for the in-study side.
Aim for about two pages; check the funding opportunity and NIH guidance for limits and format.
A study set up with a data dictionary and exports from the start makes the plan easy to keep. Build yours in the free sandbox, no credit card.
Where Capture helps
Capture does not write the plan or host a public repository, and it is not a place to deposit data for outside researchers. It helps with the parts you control: clean, documented, exportable study data with a history of every change.
| SUBJ | ECGPERF_CODE | ECGPERF_LABEL |
|---|---|---|
| 01-001 | Y | Yes |
| 01-002 | ND | Not done |
Process
Questionnaires, clinic measurements, labs, wearables, biospecimens. Decide which will be shared.
Pick the repository and a data dictionary format, and write the access terms down.
Confirm what participants will be told about sharing and align the plan.
Name the person and review cadence. Add the cost lines to the budget with your grants office.
Use the worked outline above as a skeleton, then cut anything you cannot commit to.
Ask them to check against the current NIH notice and institutional policy before submission.
For applications with due dates on or after 25 January 2023. It applies to NIH-funded research that generates scientific data. Confirm current details on the NIH Grants & Funding site.
Plans are commonly written at around two pages. Check the funding opportunity and NIH guidance for any limit or format.
Six: data type; related tools, software and code; standards; data preservation, access and timelines; access, distribution or reuse considerations; and oversight of data management and sharing.
NIH generally allows reasonable costs of data management and sharing to be requested. Ask your grants office how to enter them.
No. Capture is the study data system. You export a de-identified dataset and dictionary and deposit them in a repository you choose.
No. The NIH plan is a short funder document. The clinical DMP is operational. See the data management plan template for the latter.
Keep exploring
Clinical data management plan template
The operational DMP.
Clinical trial software for NIH-funded investigators
The software side of an NIH project.
Data dictionary and codebook generator
Document your variables.
Clinical trial data ownership and portability
Getting your data out.
ClinicalTrials.gov registration guide
The other NIH-adjacent obligation.
EDC for academic clinical trials
For university teams.
Free sandbox with every feature. No credit card, and you pay only when you go live with real participants.