Developing a Data Collection Plan

Overview

A data collection plan is the operational bridge between a research protocol and the dataset that will eventually be analysed. It specifies what information is required, where it comes from, when it is collected, who is responsible, how it is recorded, and how its quality and traceability will be protected. Good clinical-practice guidance increasingly emphasises designing quality into a study from the beginning rather than trying to inspect quality into the data after collection.[1,2]

This principle applies beyond regulated clinical trials. A cross-sectional survey, cohort, registry, qualitative project or mixed-methods study can all fail because an apparently minor field decision was not specified prospectively: the wrong blood-pressure reading was entered, a follow-up window was interpreted differently across sites, a questionnaire version changed mid-study, or a derived variable could no longer be reconstructed. A data collection plan makes these decisions explicit before they become inconsistencies.

Why this matters

Statistical software can analyse only the data that the research process produced. It cannot recover an outcome that was never measured, determine which of two conflicting dates was correct without a source trail, or distinguish a true zero from a value coded as zero because the item was not assessed. The integrity of the final analysis therefore depends on upstream operational decisions.

The plan should be proportional to the study. A small student project does not need the infrastructure of a multinational trial, but it still needs a clear map from objectives to variables and from variables to sources. Conversely, a complex multicentre study needs sufficiently detailed procedures, roles and controls to keep implementation consistent across people, sites and time.[1]

From objectives to collectable information

Start with the study objectives, not with an empty form. For each objective, identify the minimum information needed to answer it. Then classify each item as a direct observation, participant report, record abstraction, instrument score, laboratory measurement, device output or derived variable. This prevents the common problem of collecting many convenient variables while omitting one essential element of the primary outcome.

A useful planning matrix contains at least:

The operational definition should be precise enough for two trained collectors to make the same decision from the same information. If a concept requires judgement, the plan should state the rule and where ambiguous cases are escalated.

Source data, captured data and derived data

Source data are the original records or observations from which study information is obtained. They may include clinical records, laboratory reports, instrument readings, participant responses or device files. Captured study data are the values transcribed or entered into the study system. Derived data are calculated from other values, such as body-mass index, age at enrolment or a questionnaire total score. These layers should not be confused.[1,3]

When a value is derived, retain or reference the components required to reproduce it. For example, do not store only age if date of birth and index date are needed for a time-dependent eligibility rule. If a score is calculated automatically, document the algorithm and instrument version. If a source value is corrected, the change should remain traceable rather than silently overwriting the history.

Time points and windows

A protocol phrase such as “at six weeks postpartum” is not yet an operational rule. The data plan should define the reference date and acceptable window. Is six weeks measured from delivery date? Is a test at 4 weeks acceptable? At 13 weeks? If the research question concerns guideline completion, the clinically relevant window may differ from a visit scheduling window.

Visit windows influence missingness and interpretation. A very narrow window may classify clinically useful measurements as missing; a very broad window may combine meaningfully different stages of recovery. The plan should therefore distinguish:

• target time point — when measurement is ideally obtained;
• allowable operational window — when collection can occur;
• analysis definition — which measurements contribute to a particular endpoint; and
• out-of-window handling — whether the value is retained, flagged or excluded for a specific analysis.

Identifiers and linkage

Repeated or multisource data require stable identifiers. Assign a unique study identifier that does not change between forms or visits. When linkage to identifiable clinical systems is necessary, keep the re-identification key separate from the analysis dataset and restrict access according to study roles.

Do not use names, identity-card numbers or medical-record numbers as routine analysis identifiers. They may be necessary in a protected linkage file, but exporting them with analytical variables increases disclosure risk without improving analysis.

Roles and responsibilities

The plan should assign responsibility rather than assuming “the study team” will handle everything. Relevant roles can include screening, consent, measurement, source abstraction, data entry, query resolution, quality review, database administration and final data release. ICH E6(R3) emphasises that roles and responsibilities should be clear and that delegated activities require appropriate oversight.[1]

For multicentre work, specify which decisions are central and which are local. A central data manager may define variable rules and issue queries, while site staff resolve those queries against local source records. Escalation routes are useful for ambiguous eligibility, conflicting dates, unexpected units or suspected duplicate participants.

PROTOCOL CHECKLIST

Minimum elements of a data collection plan

• objectives and corresponding variables;
• operational definitions and units;
• data source and source hierarchy;
• collection schedule and allowable windows;
• identifiers and linkage procedures;
• responsible role for each activity;
• form or electronic field where each item is captured;
• permissible values, missing-value rules and edit checks;
• procedures for corrections and query resolution;
• quality-control and monitoring activities;
• confidentiality, access and transfer arrangements; and
• documentation of derived variables and dataset releases.

Missing, unknown and not applicable are different

A blank field is ambiguous. It may mean the assessment was not performed, the participant refused, the result is not yet available, the question did not apply, or the collector forgot to enter it. Whenever these distinctions matter, represent them explicitly.

Avoid inserting arbitrary numerical codes such as 999 into measurement fields unless the full pipeline is designed to treat them as missing. Such values are easily mistaken for genuine observations. Electronic systems often allow labelled missing-data reasons or separate status fields, which are safer than sentinel numbers.

Quality by design

Quality control should concentrate on data that are critical to the research question and participant protection.[1,2] A primary endpoint date may deserve programmed validation, source verification and central review, whereas a low-priority descriptive field may require only a permitted-value check.

Useful prospective controls include:

• range and type restrictions;
• required fields when logically necessary;
• branching logic to prevent irrelevant questions;
• checks for impossible date sequences;
• standard units;
• duplicate detection;
• predefined source hierarchy; and
• routine reports for missing or inconsistent critical data.

These controls should assist rather than replace judgement. Excessive hard stops can encourage staff to enter plausible but incorrect values merely to proceed.

DECISION GUIDE

Plan each variable through seven questions

1. Why is this variable needed?
2. What exactly does it mean?
3. What is the authoritative source?
4. When should it be collected?
5. Who is responsible for collecting or verifying it?
6. What values, units and missing states are permitted?
7. How will an error be detected, corrected and traced?

Worked example

WORKED EXAMPLE

Designing the postpartum-test outcome

The primary descriptive outcome is completion of postpartum glucose testing.

Poor specification: “Postpartum test: Yes/No.”

Improved specification: A laboratory glucose test performed from day 28 through day 84 after the delivery date. The laboratory information system is the preferred source. If testing occurred at an outside facility, a documented result is accepted according to the protocol. Record the specimen date, test type and result when available. Classify completion separately from whether the result was normal. If no result can be verified after the prespecified search procedure, record outcome status as unknown rather than automatically “No”.

This definition separates whether the recommended action occurred from what the result showed, preserves the timing needed for audit, and avoids turning absence of evidence into evidence of non-completion.

Interface with statistical analysis

The data plan should anticipate analysis without allowing software convenience to redefine the research question. Variable names, coding, units and repeated-measure structure should be compatible with the planned analysis. For example, categorical variables need explicit reference categories, dates should remain true dates rather than text labels, and repeated visits should be distinguishable by both participant identifier and time point.

The final analytical dataset should be produced through documented transformation from the collected data. Data cleaning and derivation should not destroy the original captured values. Principles for organising analysis-ready data are discussed further in the Biostatistics lecture on preparing medical data for analysis and in practical data-organisation guidance.[4,5]

Designing for reproducible dataset releasesMMed extension

Large studies should distinguish the capture database, cleaned study dataset and analysis dataset. Each release can be assigned a date or version, with documented inclusion rules, transformations and outstanding queries. This makes it possible to reproduce which data supported an interim report, abstract or manuscript.

A data-management plan can also describe file naming, documentation, metadata, sharing conditions and preservation. FAIR principles emphasise making research objects findable, accessible under appropriate conditions, interoperable and reusable; they do not mean that confidential participant-level data must be openly downloadable.[6]

Building a collection schedule and responsibility matrix

A data collection plan becomes more useful when it is converted into a schedule that shows what happens to a participant over time and which role owns each step. This is particularly important in longitudinal research because a list of variables does not show whether measurements can actually be obtained within the intended clinical workflow.

For each study time point, map the participant event, data source, expected duration, responsible role and downstream dependency. For example, a discharge assessment may depend on the delivery date being entered first; a follow-up questionnaire may depend on successful identity verification; a derived outcome may depend on both laboratory data and a verified specimen date. This map can reveal impossible sequences before recruitment begins.

A responsibility matrix should also separate collection, verification, query resolution and approval. The person who enters a laboratory value need not be the person who adjudicates an ambiguous external result. Separating these functions is useful when judgement is required or when a correction to a critical variable should receive independent review.

Plan for operational exceptions

A mature data plan describes what happens when expected data are not available. Common exceptions include participants transferred between hospitals, tests performed externally, partially completed questionnaires, visits outside the planned window, duplicate records and records that cannot initially be linked to a participant. These are not rare anomalies to leave until cleaning; they are foreseeable states of a real study.

Create an exception table specifying the trigger, immediate action, responsible role, documentation and escalation point. For example, if an external laboratory report uses a different unit, the collector should record the original value and unit rather than converting it manually; a documented transformation can then create the harmonised analytical value.

Review burden as a quality variable

Every requested data item has a cost. Long forms can delay clinical workflow, increase missingness and encourage superficial entry. Before finalising the plan, estimate the burden at each visit and ask whether every field remains necessary. Removing low-value variables is often a quality improvement because staff can concentrate on critical information.

For multicentre studies, compare source availability across sites before assuming one plan works everywhere. A variable that is automatically recorded at one hospital may require manual reconstruction at another. The scientifically important definition should remain common, but the source pathway may require documented site-specific implementation.

APPRAISAL CHECKLIST

Appraise the data collection plan before launch

• Can every primary and secondary objective be answered from the planned variables?
• Is each critical variable defined sufficiently for independent collectors to agree?
• Are time points and windows operationally feasible at every site?
• Are source hierarchies defined for likely conflicts?
• Are legitimate missing and exceptional states represented?
• Are participant identifiers and linkage needs proportionate?
• Are collector burden and respondent burden reasonable?
• Can the final analytical variables be reproduced from retained information?

Common mistakes

Knowledge check

A participant has no laboratory result in the hospital system. Should the primary outcome automatically be coded as 'test not completed'?

Answer and reasoning

No. Unless the study has established that the hospital system captures all possible testing, absence of a local result may mean the test was performed elsewhere or that verification is incomplete. The data plan should specify the search procedure and preserve an ‘unknown’ state when completion cannot be established.

Why should an operational definition include the data source as well as the variable name?

Answer and reasoning

The same concept may appear in several sources that disagree or have different completeness. Naming the preferred source and a hierarchy for alternatives makes collection reproducible and prevents collectors from choosing whichever value is easiest to find.

What is the advantage of storing components used to derive a variable?

Answer and reasoning

The derivation can be checked, corrected and reproduced if definitions change. Keeping only the derived result makes it difficult to detect errors or recalculate the variable consistently.

Which variables deserve the strongest quality controls?

Answer and reasoning

Controls should be risk-based. Variables central to participant protection, eligibility, primary outcomes, major exposures and key analysis decisions usually deserve stronger validation and review than low-priority descriptive fields.

Key take-home messages

SUMMARY

Key take-home messages

• Build the data collection plan from the research objectives and operational definitions.
• Specify source, timing, responsibility, units, permissible values and missing-data states prospectively.
• Preserve traceability from source information through captured and derived data to the analysis dataset.
• Use identifiers and access controls that support linkage without unnecessarily exposing participant identity.
• Concentrate quality controls on data that are critical to the research question and participant protection.
• Treat data management as part of study design, not as a clerical task performed after recruitment.

References

1. International Council for Harmonisation of Technical Requirements for Pharmaceuticals for Human Use. ICH harmonised guideline: Good Clinical Practice E6(R3). Step 4. 6 January 2025. https://database.ich.org/sites/default/files/ICH_E6%28R3%29_Step4_FinalGuideline_2025_0106.pdf
2. International Council for Harmonisation of Technical Requirements for Pharmaceuticals for Human Use. ICH harmonised guideline: General considerations for clinical studies E8(R1). 6 October 2021. https://database.ich.org/sites/default/files/ICH_E8-R1_Guideline_Step4_2022_0204%20%281%29.pdf
3. US Food and Drug Administration. Guidance for industry: Electronic source data in clinical investigations. Silver Spring (MD): FDA; 2013. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/electronic-source-data-clinical-investigations
4. Broman KW, Woo KH. Data organization in spreadsheets. Am Stat. 2018;72(1):2–10. https://doi.org/10.1080/00031305.2017.1375989
5. Michener WK. Ten simple rules for creating a good data management plan. PLoS Comput Biol. 2015;11(10):e1004525. https://doi.org/10.1371/journal.pcbi.1004525
6. Wilkinson MD, Dumontier M, Aalbersberg IJ, Appleton G, Axton M, Baak A, et al. The FAIR Guiding Principles for scientific data management and stewardship. Sci Data. 2016;3:160018. https://doi.org/10.1038/sdata.2016.18