Clinical Trial Data Management

What is clinical trial data management?

Clinical trial data management is the process of collecting study data to the protocol in an electronic data capture (EDC) system, checking it with edit checks and queries, and locking a clean dataset for analysis. Every entry and change is attributable through an audit trail, so the sponsor can show FDA how each value reached its final form.

EDC, CTMS and the rest of the study stack

• EDC or CDMS: Holds the eCRFs, edit checks, queries, signatures and lock. This is the data management system.
• CTMS: Tracks sites, enrollment, monitoring visits, payments and milestones. It manages the trial, not the data.
• IRT: Handles randomization and investigational product supply.
• eCOA and ePRO: Capture questionnaires and diaries directly from participants.
• eTMF: Stores the essential documents of the trial, such as protocols, approvals and training records.

Clear boundaries matter. When the CTMS starts storing clinical values or the EDC starts tracking site payments, validation scope and audit responsibilities blur.

Which FDA rules govern trial data systems?

21 CFR Part 11 governs electronic records and signatures used to meet FDA requirements, and FDA guidance explains how it applies in clinical investigations. Good Clinical Practice and the investigational product regulations add recordkeeping duties.

• Audit trails: 21 CFR 11.10(e) requires secure, computer-generated, time-stamped audit trails that record operator entries and actions that create, modify or delete records, without obscuring previously recorded information.
• Validation and access: 21 CFR 11.10(a) and (d) require validated systems and access limited to authorized individuals, and 11.50 requires signed records to show the signer's name, the date and time, and the meaning of the signature.
• Clinical investigation guidance: FDA's final guidance Electronic Systems, Electronic Records, and Electronic Signatures in Clinical Investigations: Questions and Answers (October 2024) gives recommendations for sponsors, investigators, CROs and IT service providers.
• EHR data as source: FDA's 2018 guidance on using EHR data in clinical investigations says FDA does not intend to assess EHR systems for Part 11 compliance, but Part 11 applies to the sponsor's EDC system that extracts the EHR data.
• Good Clinical Practice: ICH E6(R3), published by FDA as final guidance in September 2025, sets out risk-based quality management and data integrity expectations for trials.

For drug and biologic studies, 21 CFR 312.62 requires investigators to keep case histories and other records for 2 years after a marketing application is approved for the indication, or 2 years after the investigation is discontinued and FDA is notified.

Where does HIPAA fit, and where does it stop?

HIPAA governs the clinical site's disclosure of patient data, not the sponsor's EDC. A sponsor or CRO is generally neither a covered entity nor a business associate of the site, so PHI the site discloses under a patient authorization or an IRB or privacy board waiver is not governed by HIPAA once the sponsor holds it.

• At the site: The hospital or clinic is usually a covered entity. To disclose PHI to a sponsor for research, it needs an authorization under 45 CFR 164.508, a waiver under 164.512(i), or another Privacy Rule pathway.
• In the sponsor's hands: The data is governed by the protocol, the informed consent, the clinical trial agreement, FDA regulations and any applicable state or foreign privacy law, rather than the HIPAA Security Rule.
• Data minimization still matters: Trial systems normally use subject IDs rather than names, and eCRFs should collect only what the protocol needs.
• When HIPAA can apply: If the sponsor performs a function for the covered entity under a business associate agreement, or is itself a covered entity, HIPAA can govern that part of the work.

Security is still expected. Part 11 access controls, the clinical trial agreement and data protection laws all require the EDC to protect participant data, even where HIPAA does not apply.

How should an eCRF and its edit checks be designed?

Design the eCRF from the protocol's schedule of assessments, so every field traces to a protocol requirement, and specify the edit checks before the first participant is enrolled. Fields with no protocol reason add site burden and query volume.

• Range checks: Flag values outside a plausible range, such as a systolic blood pressure entered as 1200.
• Required fields: Prompt for missing values that the protocol requires at that visit.
• Date logic: Catch a visit date before consent, a lab date after a death date, or a visit outside its protocol window.
• Cross-form checks: Compare an adverse event start date with concomitant medication dates, or eligibility answers with screening labs.
• Unit checks: Require a unit with each lab value and flag units the protocol does not expect.
• Coding: Code adverse events with MedDRA and medications with WHODrug, with coder review of uncoded terms.

Write each check as a specification with an ID, the logic, the message the site sees and the expected action. Test every check against designed test data during user acceptance testing, and keep the results as validation evidence.

Bringing EHR data into eCRFs

EHR-to-EDC transfer saves transcription, but FDA's 2018 guidance attaches expectations to it. The data management plan should list each site's EHR system with its manufacturer, model, version and whether it is ONC-certified. The EHR is identified as the data originator for each transferred element. After transfer, only the investigator or delegated study staff should change the data, each change should carry the date, time, originator and reason, and the investigator should review and sign the completed eCRF.

How do queries move from open to closed?

A query opens when an edit check fires or a data manager or monitor raises a manual question, and it closes only when the reviewer accepts the site's answer. Each step is recorded in the audit trail with the user, time and reason.

• 1. Open: The system or a reviewer raises the query with specific text, such as the value, the rule and what to check in the source.
• 2. Answered: The site corrects the value with a reason for change, or confirms the value as correct and explains why.
• 3. Reviewed: The data manager accepts the answer or re-queries with a clearer question.
• 4. Closed: The query is closed and the value is ready for review and signature.

Track query age by site and form. Queries that stay open for long periods tell the study team where training or form design needs to change, and they decide how quickly the study can lock.

What happens at database lock?

Database lock is the point at which the sponsor removes edit access so the dataset can be analyzed. It is a data management procedure defined in the data management plan and SOPs, not a Part 11 requirement, although the lock and any reopening must appear in the audit trail.

• Pre-lock checklist: All queries closed, medical coding complete, external data such as central lab and ECG files reconciled, serious adverse events reconciled with the safety database, and investigator signatures in place.
• Soft lock: Freeze a subject, visit or form for review while still allowing controlled corrections.
• Hard lock: Remove write access for all users and record the lock with date, time and approver.
• Reopening procedure: A documented request, approval, change, re-review and re-lock, all visible in the audit trail.

Reconciling external data before lock

Central labs, ECG readers, imaging cores and the safety database each send data that must match the EDC before lock. Agree a transfer specification for each vendor at study start, with file format, subject and visit keys, and frequency, then run reconciliation on a schedule rather than only at the end, so mismatched subject IDs or missing visits surface while sites can still fix them.

Failure points in trial data systems

• Hospital warehouse patterns: A generic data store with no query state, no signatures and no lock cannot support a trial.
• Back-end edits: Database scripts that change values outside the application bypass the audit trail.
• Shared accounts: A login used by several site staff breaks attribution of entries and signatures.
• Unvalidated changes: A mid-study form change deployed without impact assessment and testing.
• Silent EHR imports: EHR data loaded into eCRFs without documenting the source system, mapping and data originator.
• Unrehearsed inspection: Nobody has practiced pulling one subject's data from source to eCRF to listing with its audit trail.

How Agnotic can help

Trial software is judged at inspection, so the audit trail, validation evidence and lock procedure need to be designed in from the first form. Agnotic Technologies builds clinical trial data management software for sponsors, CROs and research sites: protocol-driven eCRFs, edit-check engines with specification traceability, query workflows, electronic signatures, lock and reopening procedures, EHR-to-EDC data pipelines and Part 11 controls.

Sources

• eCFR: 21 CFR Part 11, Electronic Records; Electronic Signatures
• FDA: Electronic Systems, Electronic Records, and Electronic Signatures in Clinical Investigations: Questions and Answers
• FDA: Use of Electronic Health Record Data in Clinical Investigations
• FDA: E6(R3) Good Clinical Practice (GCP)
• eCFR: 21 CFR 312.62, Investigator recordkeeping and record retention
• HHS: Research and the HIPAA Privacy Rule
• 45 CFR 164.512: Uses and disclosures for which authorization is not required, including research