Clinical Data Management: A Practical Guide for Trial Teams

Clinical data management is the set of activities that turn what happens at a study site into a dataset a regulator can review: designing the database, capturing and validating entries, resolving discrepancies, reconciling external feeds, and locking the study for analysis. Most of the delay in that chain comes from four handoffs between owners, not from data entry itself.

A trial’s data does not travel in a straight line. It starts as a note in a source document or a reading on a device. It becomes an entry in an electronic data capture system, gets questioned, gets corrected, is reconciled against laboratory and patient-reported feeds, is mapped into a standard structure, and is finally locked. Every one of those steps has an owner, and the points where ownership changes hands are where studies quietly lose weeks.

This guide follows that path in order, from the protocol that decides what to collect through to the datasets that go into a submission. It is written for the people doing the work: clinical data managers, data coordinators, clinical operations leads, and the CRO staff who inherit half-built studies.

What this guide covers is the shape of the process, who owns each stage, and where the cost sits. What it does not cover is the step-by-step procedure for any single stage. Each section below links to a dedicated guide that goes deeper, because a database build checklist and an amendment change-control procedure are different jobs and deserve their own pages.

What Clinical Data Management Covers, and Where It Stops

Clinical data management owns the data. It does not own the study. That distinction settles most of the arguments that break out in month five.

Clinical operations owns site selection, site management and monitoring. Biostatistics owns the analysis and the analysis datasets. Regulatory affairs owns submission assembly. Data management owns everything in between: what gets collected, how it is validated, what it is reconciled against, who signs off on it, and when the database is locked and handed on. Where those responsibilities meet is where the work is.

The artifact that fixes those boundaries is the data management plan. Written properly it names the data sources, the validation rules, the reconciliation pairs, the coding dictionaries and versions, the review meetings, the sign-off chain and the lock criteria. Written as a compliance exercise and filed once, it does none of that, and the boundaries get renegotiated by email every time something unexpected arrives. The Society for Clinical Data Management’s Good Clinical Data Management Practices remains the reference point for what belongs in scope.

One boundary is worth naming early, because it is the one most often assumed away. The electronic data capture system is where the data lives, but it is not the whole of data management. It does not own your metadata, your export specification, your validation package or your query process, whatever the demo suggested. That gap is covered in detail in what an EDC system does, and the four jobs it cannot do for you.

The Study Build, From Final Protocol to First Patient In

The build is a sequence, and it runs in this order for a reason. The protocol is reviewed and turned into a data collection specification. The eCRF is designed against that specification, ideally with CDASH structures in mind. Edit checks are specified, then configured. The build is tested, first by the builders and then by the people who will use it. Validation documentation is assembled. Site staff are trained. The database goes live.

Nothing in that list is optional, but three items are compressible under pressure, and they are always the same three: user acceptance testing, the edit check review, and the validation documentation. Compressing them does not remove the work. It moves the work to a worse place. An untested edit check becomes a query storm in month three. A thin validation package becomes an inspection finding, or a full revalidation the first time the protocol changes.

The other quiet rule of the build is that whoever writes the specification owns the ambiguity in it. If the protocol says an assessment is done at screening and the eCRF offers one date field, someone has already decided how to handle the site that spreads screening across two visits. If nobody decided deliberately, the sites will decide, differently from each other, and the reconciliation cost lands on data management. The full sequence, step by step, is in every step between final protocol and first patient in.

How the Data Actually Moves, in Six Stages

Six stages, from the site to the submission dataset.

1. Source capture. A measurement, an observation or a patient response is recorded at the site, on a device, or by the patient.
2. Entry. Site staff enter it into the EDC, or it arrives directly from an ePRO app, a central laboratory or a connected device.
3. Automated validation. Edit checks fire on entry: range checks, logic checks, cross-form and cross-visit checks.
4. Discrepancy management. Queries are raised, sent to the site, answered and closed. Manual data review sits alongside this.
5. Reconciliation. External data is compared against the EDC record: laboratory results, ePRO completions, imaging, device output, and safety data against the pharmacovigilance system.
6. Close-out. Medical coding is finalized, data review meetings sign off, the database is locked, and the export is produced for analysis and submission.

The part that trips up planning is that stages three, four and five do not run in sequence. They run continuously and concurrently from first patient in to last patient out. A Gantt chart that shows data cleaning as a bar after enrollment closes is describing a study that does not exist. Cleaning is a standing activity, and the volume of it in the last two months is a direct function of decisions made during the build.

The Four Handoffs Where Studies Lose Weeks

Delay clusters at the boundaries, not inside the stages. Four boundaries account for most of it.

Protocol to Database Specification

What changes hands is intent. The protocol says what the study measures. The specification says what the database will accept. Ambiguity survives this handoff invisibly, because both documents look complete on their own. The cheap fix is a joint read of the specification by the medical, data and statistics leads before configuration starts, with the specific question: what would two different sites do with this field?

Source to System at the Site

What changes hands is a record. A coordinator reads a source document and types into a screen. Transcription error, timing lag and missing source are the three failure modes, and all three surface as queries weeks later. The cheap fix is a workflow design that matches the order in which the site actually sees the patient, rather than the order the protocol lists assessments in.

External Vendor Data to the Study Record

What changes hands is a file, on a schedule, in a format agreed months earlier. Failure looks like identifiers that do not match, units that changed, visit labels that drifted, or a transfer specification that was never tested with real volume. The cheap fix is a dry run with production-shaped data before first patient in, and a reconciliation report that runs on every transfer rather than at the end.

Clean Database to Statistics and Submission

What changes hands is structure. The collected data has to become standardized datasets with a define file that describes them. If the eCRF was designed without that destination in mind, the mapping absorbs the difference, and it does so in the weeks when there is least room. The cheap fix is annotating the eCRF at design time, not at submission time.

Query Management, and Why Volume Rises Late

Late-study query spikes are usually read as a site quality problem. They are more often a design problem, and the design decision happened before the first patient was enrolled.

Three mechanisms drive the rise. Cumulative checks, the kind that compare a value against a patient’s own history, cannot fire until there is history to compare against, so they arrive in bulk later. Visit-window and completeness checks aggregate: one missed assessment can raise several queries across forms. And reconciliation queries, by their nature, arrive when external data arrives, which is often in batches near the end.

None of that is avoidable in full, but the volume is controllable. Edit checks written against the protocol produce queries that are technically correct and operationally useless, the ones sites answer with a shrug and a comment. Edit checks written against the site workflow catch the same data problems earlier and generate fewer of them. The difference shows up in resolution time, which is the number worth watching rather than raw query count, because it measures whether the query was answerable.

Query burden is also a retention issue. Sites that spend their Fridays clearing queries they consider pointless are slower to enroll on the next study. Why query volume rises late in a study, and what reduces it goes through the edit-check design decisions in detail.

Mid-Study Amendments, the Most Expensive Change You Will Make

An amendment that adds two fields sounds like a morning’s work. In practice it touches the eCRF, the edit check set, the export specification, the external transfer specification, the training material and the validation package, and each of those has a different owner and a different approval route.

The question that decides the cost is how much of the build has to be revalidated. Answering it well means scoping by risk rather than by habit: what changed, what depends on what changed, and what evidence would satisfy an inspector that the change did not break anything else. A risk-based approach is the one described in GAMP 5 Second Edition and is consistent with how regulators expect validation effort to be targeted. Revalidating everything is expensive and is not more compliant.

The other factor is metadata ownership. If your study metadata, the field definitions, the edit check logic, the coding configuration, sits with the vendor rather than with you, every amendment is a change request with a queue and a price. If it sits with your team, an amendment is work you can schedule. That is a procurement decision made long before the amendment, which is why it appears in the vendor questions guide. For the scoping method itself, see handling a mid-study amendment without revalidating the whole build.

Why Patient-Reported Data Behaves Differently

Every other data source in a study is entered by trained staff who are paid to enter it. ePRO is not. The person entering it is the patient, and their reasons for continuing are their own.

That changes what compliance means. A missing case report form is a site task that can be chased. A missing patient diary entry is gone, because the question asked how the patient felt yesterday and yesterday has passed. So ePRO design is a prevention exercise, not a recovery one. The levers are practical: how many questions, on what device, at what time of day, with what reminder, and how much of the first visit goes to setup.

The pattern worth planning for is that compliance rarely collapses at the start. It drifts, and the drift often becomes visible around the fourth month, once the novelty of the first visits has worn off and the site has stopped mentioning it in every call. By then the missing data is already missing. The check that helps is a compliance review scheduled early enough to act on, with a named owner, rather than a report that circulates once a quarter. Why ePRO adoption drops in month four covers the site-side workflow in full.

How Data Standards Decide What Submission Costs

Two standards do most of the work, and they sit at opposite ends of the flow. CDASH describes how to collect data. SDTM describes how to submit it. The define file describes the relationship between what you submitted and what it means. Controlled terminology keeps the values consistent enough for any of that to hold.

The practical point for a data manager is that the cost of the second is set by the first. An eCRF designed with the submission structure in view maps cleanly and cheaply. An eCRF designed only for the people entering data maps too, but the mapping absorbs every decision that was left open, and it does so under submission timelines. Free-text fields where a code list would have worked, one field carrying two concepts, and inconsistent date handling are the recurring three.

Regulators publish what they expect. For submissions to the FDA, the Study Data Technical Conformance Guide and the supported standards catalog between them define which versions apply and when. Those documents are updated, so the version check belongs in the build, not in the submission. Where CDASH to SDTM mapping breaks, and how to design the EDC to prevent it works through the specific design decisions.

A Readiness Check Before You Lock the Build

Ten questions. If more than two get an uncertain answer, the go-live date is optimistic.

1. Has the data management plan been read by the medical, data and statistics leads in the same room, in this version?
2. Has every edit check been tested with data designed to break it, not only with clean data?
3. Has each external transfer been run once, end to end, with production-shaped volume?
4. Is there a named owner for each reconciliation pair, with a run frequency?
5. Is the eCRF annotated to the submission structure, and has anyone from statistics confirmed it?
6. Do you know which standards versions apply, and are they current?
7. Is the study metadata editable by your team, or does every change go through the vendor?
8. Does the validation package describe what you validated, not only that you validated?
9. Is there a change-control route for a mid-study amendment that someone has actually walked through?
10. Is the database lock criteria written down, with the sign-off chain named?

If you are still choosing a system rather than configuring one, the questions to put to vendors are a different set. Ask them before signature, not after: twelve questions to ask an EDC vendor before you sign.

Where This Fits

Clinera EDC is the data capture and validation layer described above, and Clinera ePRO and Clinera Survey cover the patient-reported side. For teams applying automation to the review and reconciliation stages, clinical and R&D AI sets out where that helps and where it does not. A worked example of the same pattern applied earlier in the study appears in the AI patient recruitment use case.

References

• 21 CFR Part 11, Electronic Records; Electronic Signatures. US Code of Federal Regulations, Title 21, Part 11. ecfr.gov
• ICH E6(R3) Good Clinical Practice. International Council for Harmonisation. ich.org
• CDASH, Clinical Data Acquisition Standards Harmonization. CDISC foundational standards. cdisc.org
• SDTM, Study Data Tabulation Model. CDISC foundational standards. cdisc.org
• Good Clinical Data Management Practices. Society for Clinical Data Management. scdm.org
• Study Data Technical Conformance Guide and the FDA Data Standards Catalog. US Food and Drug Administration, Study Data Standards Resources. fda.gov

This guide describes process and regulatory expectations in general terms and is not legal or regulatory advice. Confirm the current version and applicability of any standard or guidance for your study and region.