How to Write a Data Management Plan for Clinical Data

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

By the end of this guide you will be able to draft a complete data management plan (DMP) for a clinical study: you will inventory your data sources, estimate storage needs, choose a clinical data repository or comparable sharing venue, write a de-identification and access policy, and put all of it into a versioned document your team and reviewer can actually use.

Have these on hand before you start:

• Your funder's DMP template or policy (NIH, NSF, and most foundations publish one)
• Your IRB protocol number and approval or waiver status
• A draft variable list and case report forms
• Any existing data sharing agreement or data transfer agreement between your sites
• A plain-text editor and a spreadsheet program

What a Clinical Data Repository Is and Why It Shapes Your Plan

A clinical data repository is a centralized database that stores patient-level clinical information, such as diagnoses, medications, laboratory results, procedures, and clinical documents, gathered from one or more sources so the data can be reused for research and quality improvement. In a hospital setting, a repository typically extracts data from administrative systems and the electronic medical record, including demographics, medications, laboratory results, diagnoses, and procedure codes [1]. Integrated health systems have built research-oriented repositories specifically to house large numbers of clinical documents for secondary use [2].

Repositories vary enormously in scope, and your plan must match the kind you intend to build or use:

• Single-institution research repositories serve one health system and its academic partners. Fairview Health Services and the University of Minnesota built a secure research-oriented clinical data repository covering legacy and current electronic health record systems across community and academic sites [2].
• Multisite and national repositories pool data across institutions. A Veterans Affairs repository combines longitudinal clinical data, tumor sequencing, and imaging for oncology research nationwide [3]. A national Veterans Affairs data warehouse supported a cohort study of more than 7,800 hospitalized patients with COVID-19, demonstrating how a large existing repository enables rapid secondary analysis [4].
• Disease-specific registries recruit patients through advocacy organizations. A national deidentified database for Dup15q syndrome was built through collaboration across multiple institutions because the rarity of the condition made any single-site repository impractical [5].
• Regional and biobank-linked repositories combine clinical records with other data types. A St. Louis regional repository aggregated visits for violent injury across four level I trauma hospitals under a formal data sharing agreement between two health systems [6]. OncoLifeS in Groningen links routine clinical data with preserved biological specimens and quality of life assessments within routine cancer care [7].
• Open-access domain repositories publish curated datasets publicly. DRAMP 4.0, an open-access repository for antimicrobial peptides, holds over 30,000 entries with annotations on stability, hemolytic activity, and cytotoxicity, and provides download links for bulk retrieval [8].
• Multicentre research repositories such as MAGIC, a European collaboration of seven stroke centers, consolidate clinical and radiological data under signed data transfer agreements with centralized de-identification [9].

The architecture of the repository itself belongs in your plan. The Polish national clinical data repository work showed that cloud-enabled architectures, combined with standardized medical information exchange, improve security, availability, and sustainability compared with locally deployed systems [10]. Data modeling approaches such as openEHR, which separates clinical content models from technical architecture, are one documented route from data modeling to a working repository [11].

What a Data Management Plan for Clinical Data Must Cover

Most funders and institutions expect the same core sections. Write each one for your specific study, not in general terms.

1. Data description. What data will you collect or reuse, from which sources, in what file formats and volumes? Distinguish structured data (laboratory results, medication orders, diagnosis codes) from unstructured data (clinical notes, imaging, pathology slides).
2. Standards and metadata. Which terminologies, ontologies, and data models will you use? Standardization of clinical document names and attributes is essential for exchange and secondary use, and the HL7/LOINC Document Ontology is one documented framework, though real repositories find that some attributes do not map cleanly and need extended value sets [2]. Standardized collection instruments also matter. The Dup15q repository produced standardized instruments reusable for other developmental disorder studies [5].
3. Collection and provenance. How will data arrive (direct electronic transfer, manual abstraction, patient self-report), who enters it, and when? The Dup15q repository used self-report population alongside institutional contributions [5].
4. Quality control. How will you verify accuracy? Error is well documented in clinical repositories, so name your verification method explicitly.
5. Storage, backup, and security. Where will data live during the project, who holds the encryption keys, and what is the backup schedule?
6. Privacy and de-identification. What identifiers will you remove, what transformation will you apply, and who reviews the output before release?
7. Access and sharing. Who can use the data, under what agreement, and in which repository will the final dataset be deposited?
8. Retention and preservation. How long will you keep the data, in what format, and who maintains them after the grant ends?
9. Roles and responsibilities. Name the person accountable for each section.

Before You Write: Gather Your Inputs

A DMP for clinical data fails most often because it is written before the operational realities are known. Collect these facts first.

• Funder requirements. Download the exact template. If your funder has no template, use your institution's.
• Ethics status. Record whether you have approval, a waiver, or an opt-out consent model. MAGIC includes only patients who did not refuse use of their routine hospital data, and obtains approvals or waivers from responsible ethics committees before any data exchange [9].
• Existing agreements. If your project spans institutions, a formal data transfer agreement signed by all contributing centers is the mechanism that makes data exchange lawful and auditable [9]. In the St. Louis violence intervention program repository, two health systems executed a data sharing agreement covering four hospitals before any data moved [6].
• Variable list. Enumerate every field you will extract. The STL-HVIP-DR defined its variables up front as demographic, hospital and timestamp, medical, and insurance information [6]. OncoLifeS enumerated clinical and treatment details, comorbidities, lifestyle, radiological and pathological findings, and long-term outcomes [7].
• Repository policies. If you will deposit into an existing repository, read its submission and access policies now, not at the end of the grant.

Step-by-Step: Writing the Plan

Step 1. Inventory Your Data Sources and Variables

Build a machine-readable inventory. A CSV file works and survives into later steps.

source,system,format,fields,sensitivity,update_frequency
EHR extracts,Epic Clarity,CSV,demographics labs meds dx,restricted,monthly
Imaging,PACS,DICOM,CT series MR series,restricted,quarterly
Patient surveys,Redcap,CSV,QOL scales self-report,restricted,per visit
Genomics,Sequencing vendor,VCF,variant calls,controlled,one time

For each row, note in your plan whether the source already feeds an institutional repository. Many projects duplicate effort because they never check that the hospital's clinical data repository already captures the fields they need. Existing repositories are also extendable. One team integrated medication alert data, a system-level data source that most repositories overlook, into an i2b2-based repository to enable retrospective study of drug interaction alerts [1].

Step 2. Estimate Storage and Growth

Worked example for a multicentre imaging and clinical repository, using an illustrative scale similar to the MAGIC design of 2,500 acute ischemic stroke patients with initial and follow-up imaging [9]:

# illustrative storage estimate
patients = 2500
imaging_studies_per_patient = 2      # initial + first follow-up
mb_per_study = 300                   # compressed CT series, illustrative
imaging_gb = patients * imaging_studies_per_patient * mb_per_study / 1000

clinical_rows = patients * 150       # lab results, meds, vitals per patient
clinical_gb = clinical_rows * 0.0005 # ~0.5 KB per structured row

total_gb = imaging_gb + clinical_gb
print(f"Imaging: {imaging_gb:.0f} GB")
print(f"Clinical: {clinical_gb:.1f} GB")
print(f"Total project footprint: {total_gb:.1f} GB")

Expected output:

Imaging: 1500 GB
Clinical: 0.2 GB
Total project footprint: 1500.2 GB

The lesson is general: imaging dominates, structured data barely register. State your assumed file sizes in the DMP so reviewers can adjust them, and add a growth line for multiyear collection. OncoLifeS enrolled over 3,700 patients with longitudinal follow-up, which is the kind of scale that turns a one-time estimate into a recurring line item [7].

Step 3. Choose Standards and a Repository Type

Pick the narrowest standard that fits. Naming each standard in the DMP is what makes your dataset reusable by others. Document attributes, for example, can be represented with the HL7/LOINC Document Ontology, with the caveat documented in practice that axes such as Setting and Role need extended value sets for full coverage [2]. Repositories built on openEHR begin with explicit data models before architecture decisions [11].

Then choose where the data will ultimately live. The following comparison reflects real, published repository models.

When you write the data repository comparison into your plan, state why the chosen model matches your consent, sensitivity, and reuse goals, and name at least one alternative you considered.

Step 4. Write the Privacy and De-identification Section

Be concrete. Reviewers reject vague sentences like "data will be de-identified." Specify the transformation chain. The MAGIC workflow is a useful template: files arrive at a central secure server, patient identifiers are removed, images are algorithmically de-faced, and a new identifier links the de-identified clinical data to the imaging data [9].

A minimal checklist to adapt:

1. Remove direct identifiers (name, medical record number, address, dates of service where permitted)
2. Apply consistent transformations to free text and image headers
3. Re-key the dataset with a study-specific identifier
4. Store the linkage key separately from both the repository and the identifiable source
5. Have a second person spot-check a sample before release

If your institution already operates a repository, ask whether de-identified extracts are a supported output. NIH's Biomedical Translational Research Information System supports visualization of ten years of de-identified patient data for exploratory analysis, which shows how a mature repository can serve reuse directly [12].

Step 5. Define Access, Sharing, and Agreements

Write down the access tiers, the legal instruments behind each tier, and the timeline. Two instruments recur in the literature:

• Data sharing agreement between institutions that each hold the data. Two health systems used one to aggregate four hospitals' data into a single regional repository [6].
• Data transfer agreement signed by every contributing center before exchange. MAGIC required a DTA from all seven centers before any file moved, and only centers that entered a DTA received data back for stroke research projects [9].

State who can request access, what review they undergo, and how you will handle requests you decline. If you plan public release, name the target venue. The VA oncology repository released a subset through the Genomic Data Commons and The Cancer Imaging Archive and the full repository through a dedicated commons, a two-tier pattern worth copying when part of your data is more sensitive than the rest [3].

Step 6. Document Quality Control

Clinical repositories contain errors, and your plan should say how you will find them. The strongest published evidence on this comes from a prostate cancer database where electronically imported pathology reports were compared in parallel with manually entered records for the same 421 patients. Manual entry was fully concordant for 76 percent of patients, and errors varied across pathology fields, showing that transcription is a measurable, field-specific risk [13]. Medication data are a known weak point. The University of Minnesota ran a dedicated quality improvement project on medication data in its clinical data repository precisely because medication fields needed systematic cleaning [14].

Your quality section should therefore name:

• Which fields are manually entered and which are electronically transferred
• A re-abstracted sample size and audit schedule
• A rule for resolving discrepancies between manual and electronic records
• Whether system-level data such as decision support alerts are in or out of scope, since most repositories omit them unless deliberately integrated [1]

Secondary-use studies have also shown what repositories can support when curated well, including mining disease-medication associations from a local clinical data repository combined with the biomedical literature using machine-learning classification [15], and measuring pharmacogenomic testing uptake across 268,262 medication orders in a multisite repository [16]. Both depended on documented data quality, which is exactly what your DMP promises.

Step 7. Assemble the Plan as a Versioned Document

Write the DMP itself as plain text in your project repository so it versions with your code and protocols. A compact skeleton:

title: "Multicentre registry for X syndrome"
version: "1.2"
irb_protocol: "STU-2026-0412"
data_types:
  - structured_ehr_extracts
  - imaging_dicom
  - patient_reported_surveys
standards:
  terminology: ["LOINC", "SNOMED CT", "RxNorm"]
  document_metadata: "HL7/LOINC Document Ontology"
  data_model: "openEHR archetypes"
deidentification:
  method: "identifier removal plus date shifting"
  linkage_key_storage: "separate encrypted server"
  review: "second-person sample audit before release"
agreements:
  - type: "data transfer agreement"
    parties: 7
    status: "signed"
repository:
  type: "multicentre consortium, central secure server"
  final_deposit: "institutional archive with DTA-gated access"
retention_years: 10
responsibilities:
  dmp_owner: "J. Doe, PI"
  data_manager: "A. Rios"

Expected output when a colleague opens the file: a one-page plan where every funder-required section maps to a filled key, and every change to access or standards appears in the version history. Review the DMP at each protocol amendment and at least annually.

Clinical Data Repository Tips

• Engage stakeholders before the schema. The Dup15q repository succeeded because a patient advocacy organization initiated and supported the repository, and stakeholder engagement was built into the workflow from the start [5]. Families, clinicians, and informaticists each catch different design flaws.
• Embed collection in routine care when possible. OncoLifeS attributes its data quality to embedding the data-biobank in clinical care rather than running a parallel abstraction effort [7].
• Write standard operating procedures for data entry. The NaPDI natural product-drug interaction repository documented its SOPs and its design that links chemical characterization, metabolomics, and clinical experiment data for each substance, which is what made multidisciplinary reuse practical [17].
• Budget for curation, not just collection. Curating 1,846 non-small cell lung cancer patients into a standardized data model was a deliberate, resourced step in the GENIE Biopharma Collaborative cohort [18].
• Plan visualization and exploratory tools early. Simple visualization of laboratory trends across 12,266 events on 622 patients identified hypotheses worth formal study, which is the kind of value a well-documented repository delivers within weeks of a new question [12].

Common Mistakes and Limitations

• Trusting manual transcription. The parallel manual-versus-electronic comparison found outright accuracy in only 76 percent of patients, with errors concentrated in specific pathology fields [13]. If your workflow includes hand abstraction, your DMP must include an audit.
• Assuming medication fields are clean. Medication data required a dedicated quality improvement effort at a mature academic repository [14]. Do not treat pharmacy data as extraction-ready.
• Ignoring system-level data. Standard repositories extract patient-level records but routinely omit system-level sources such as medication alerts. If those alerts matter to your question, say so in the plan and specify the integration [1].
• Overpromising standardization. Even a well-built ontology mapping left gaps requiring new value sets and stronger governance over document attributes [2]. Write standards goals realistically.
• Deferring the legal paperwork. Agreements take months. Seven stroke centers signed a DTA before data exchange began, and any one unsigned center stalls the whole repository [9].
• Treating de-identification as a single step. It is a pipeline of removal, transformation, re-keying, and audit, each of which needs an owner and a check [9].
• Choosing a repository model you cannot sustain. Locally deployed systems carry documented limitations in security, availability, and exchange compared with standardized cloud-enabled architectures [10]. Match ambition to your institution's informatics capacity.
• A general limitation. Every repository differs in consent, governance, and local law, and individual projects need review by their own IRB, information security office, and institutional counsel. Use published repositories as models, not as substitutes for your institution's requirements.

Frequently Asked Questions

What is a clinical data repository?

A clinical data repository is a centralized database that consolidates patient-level clinical information from one or more source systems, such as the electronic medical record, laboratory systems, and billing records, so the data can be queried for research, quality improvement, and care delivery.

What should a data management plan for clinical data include?

It should cover data description, standards and metadata, collection and provenance, quality control, storage and security, de-identification, access and sharing terms, retention, and named responsibilities for each item.

How do I de-identify clinical data for a repository?

Remove direct identifiers, transform or generalize remaining quasi-identifiers such as dates and free text, re-key the dataset with a study-specific identifier, store the linkage key separately, and audit a sample before release. Published workflows include algorithmic image de-facing before linking de-identified clinical and imaging data [9].

What is the difference between a clinical data repository and a data warehouse?

A clinical data repository holds integrated patient-level clinical data for operational and research reuse, while a data warehouse is a broader analytical construct that can combine many domains. In practice the terms overlap, and many research repositories, including i2b2-based systems, function as purpose-built warehouses [1].

Do I need a data transfer agreement to share clinical data?

Yes for data crossing institutional boundaries. Multicentre repositories require a signed data transfer agreement from every contributing center before any exchange occurs, and access for research is typically limited to centers under the same agreement [9]. Within a single health system, an internal data sharing agreement may apply instead.

Where can I share my clinical research data?

Options include institutional repositories, consortium repositories with agreement-gated access, public archives such as The Cancer Imaging Archive and the Genomic Data Commons, which host a released subset of a national oncology repository, and open-access domain repositories with public download [3], [8].

How accurate are data in clinical data repositories?

Accuracy depends on how each field entered the repository. Direct comparison of manually entered and electronically transferred pathology data found full concordance in 76 percent of patients, with error rates varying by field, so electronic transfer plus targeted audits is the safer design [13].

How often should I update my data management plan?

Review it at every protocol amendment, whenever a new site or data source joins, whenever an agreement is signed or expires, and at least annually. Treat the plan as a versioned document so every change is traceable.

Sources

1. Integrating Medication Alert Data into a Clinical Data Repository to Enable Retrospective Study of Drug Interaction Alerts in Clinical Practice
2. Application of HL7/LOINC Document Ontology to a University-Affiliated Integrated Health System Research Clinical Data Repository
3. The Veterans Affairs Precision Oncology Data Repository, a Clinical, Genomic, and Imaging Research Database
4. Clinical Course and Outcome of COVID-19 Acute Respiratory Distress Syndrome: Data From a National Repository
5. Multisite Semiautomated Clinical Data Repository for Duplication 15q Syndrome: Study Protocol and Early Uses
6. Positioning public health surveillance for observational studies and clinical trials: The St. Louis region-wide hospital-based violence intervention program data repository
7. The OncoLifeS data-biobank for oncology: a comprehensive repository of clinical data, biological samples, and the patient’s perspective
8. DRAMP 4.0: an open-access data repository dedicated to the clinical translation of antimicrobial peptides
9. The Multicentre Acute ischemic stroke imaGIng and Clinical data (MAGIC) repository: rationale and blueprint
10. The Cloud-Enabled Architecture of the Clinical Data Repository in Poland
11. An Implementation of Clinical Data Repository with openEHR Approach: From Data Modeling to Architecture
12. Visualizing the Data - Using Lifelines2 to Gain Insights from Data Drawn from a Clinical Data Repository
13. Error rates in a clinical data repository: lessons from the transition to electronic data transfer-a descriptive study
14. Clinical Data Cohort Quality Improvement: The Case of the Medication Data in The University of Minnesota's Clinical Data Repository.
15. Using classification models for the generation of disease-specific medications from biomedical literature and clinical data repository
16. Characterizing pharmacogenomic-guided medication use with a clinical data repository
17. A New Data Repository for Pharmacokinetic Natural Product-Drug Interactions: From Chemical Characterization to Clinical Studies
18. The GENIE BPC NSCLC Cohort: A Real-World Repository Integrating Standardized Clinical and Genomic Data for 1,846 Patients with Non-Small Cell Lung Cancer