Quality control is how clinical data management proves that its output is good — not just that the data was cleaned, but that the cleaning worked and the resulting dataset meets the required standard. The audit trail is what makes that proof possible: the complete record of who did what to the data, when, and why. Together, quality control and the audit trail are how a trial demonstrates data integrity, the quality that everything else in clinical data management ultimately serves.
This guide explains what quality control involves in clinical data management, how data quality is measured, what the audit trail is and why it matters, and how both connect to the principles of data integrity. It focuses on the data-management quality perspective; the technical detail of how an EDC system records its audit trail, and the regulatory requirements for validating that system, are covered in the linked guides.
What is quality control in Clinical Data Management?
Quality control in clinical data management is the set of checks that verify clinical trial data, and the deliverables built from it, are accurate, complete and consistent with the source documents and the study specifications. QC is performed throughout the trial: during set-up on the database build and edit checks, during conduct on data review and queries, and at close-out on the final dataset before database lock.
QA vs QC in Clinical Data Management
Quality control (QC) is the set of checks that confirm data and deliverables meet defined quality standards. It is distinct from the cleaning itself: data validation finds and fixes problems, while quality control verifies that the data which results is genuinely fit for purpose. It is also distinct from quality assurance (QA) — QC checks the output, while QA provides independent assurance that the processes producing it were sound. In practice QC is woven through the whole data lifecycle, from checking a freshly built database before go-live to confirming a clean file before lock.
The difference shows in who does the work. QC is operational and sits inside the data management workflow: for example, a second data manager checks the edit check specifications against the protocol, or a sample of database records is compared with the CRFs. QA is independent of the study team: a quality function audits whether data management SOPs were followed and documented. QC finds errors in the output; QA asks whether the process that produced it can be trusted.
How quality control works: data QC procedures
Quality control in data management takes several forms, applied at different points:
- QC of the database build — confirming the eCRF and edit checks behave as specified before data collection begins. This is usually done through user acceptance testing (UAT): test data is entered to show that each edit check fires when it should and stays silent when it should not, and the test scripts and results are kept as evidence.
- QC of the data — reviewing data for accuracy and consistency, either across the whole dataset or on a defined sample, to confirm cleaning has been effective.
- QC of queries and data review: checking that queries sent to sites are clear, justified and correctly closed, and that manual review listings have been worked through. How the cleaning itself works is covered in our guide to data validation in clinical data management.
- QC of coding and reconciliation — independent checks that coded terms and reconciled data are correct. Typical examples are a second review of MedDRA and WHODrug coding and a check that serious adverse events in the safety database match the clinical database after SAE reconciliation.
- QC of data transfers: checking that external data loads, such as central laboratory or ePRO data, and the datasets delivered to biostatistics match the agreed transfer specification in structure and content.
- Database QC (data audit): before lock, a sample of records is compared field by field against the CRFs or source documents, or against data listings, to measure the error rate in the database. The result is compared with acceptance criteria set in advance, usually in the data management plan or a separate QC plan.
- QC at database lock — the final confirmation that the clean-file criteria are met before the database is frozen.
- Documentation and corrective action: each QC check is recorded with what was checked, what was found and how each finding was resolved. If QC finds a systematic error, the fix is applied across the whole dataset, not only to the sampled records, and the check is repeated where needed.
Many organisations apply a risk-based approach, concentrating QC effort on the data that matters most — critical variables and safety data — rather than treating every field identically. The aim is not flawless data at any cost, but assurance that the data is reliable for the decisions it supports.
Measuring clinical data quality
Quality is managed through metrics. Common measures include query rates and how quickly queries are resolved, the volume of open and ageing discrepancies, error rates found during QC review, and the time taken to reach key milestones such as database lock. Defined acceptance criteria turn these metrics into a clear standard: a dataset is considered clean when it meets the thresholds agreed in advance. Tracking these measures throughout the trial — rather than only at the end — is what lets a team catch a systemic problem while there is still time to fix it.
What is an audit trail in Clinical Data Management?
An audit trail is the secure, time-stamped record of every change made to the data: what was changed, who changed it, when, and why. It means that any data point can be traced back through its entire history to its origin. Two requirements make it trustworthy: it must be tamper-protected — unchangeable even by system administrators — and it must remain available for inspection at all times. An audit trail that could be edited would prove nothing. This traceability is the backbone of data integrity, and it is what an inspector relies on to confirm that the data presented for a decision genuinely reflects what happened in the trial.
The audit trail is generated by the system itself, not kept by hand, and it records when data is created as well as when it is changed or deleted, with the previous value preserved. For electronic records, FDA's 21 CFR Part 11 requires secure, computer-generated, time-stamped audit trails, and ICH E6 Good Clinical Practice expects the computerised systems used in a trial, such as the EDC system, to keep one. Data managers can also review the audit trail during the trial, for example to spot unusual patterns of changes to critical data.
Audit trails, data integrity and the ALCOA principles
Data integrity is most often expressed through the ALCOA principles: data should be Attributable, Legible, Contemporaneous, Original, and Accurate — frequently extended (ALCOA+) to also require that data is complete, consistent, enduring, and available. The audit trail is the practical mechanism that makes most of these principles demonstrable: it provides attribution, preserves the original record alongside any change, and shows that entries were contemporaneous.
The audit trail in this article is treated as a data-integrity concept. The technical detail of what an EDC system captures in its audit trail is covered in our complete guide to EDC systems, and the regulatory requirements for validating that the system records it reliably — including 21 CFR Part 11 — are covered in our guide to EDC validation requirements.
What happens in a Clinical Data Management audit?
A clinical data management audit is an independent review of how a trial's data was managed, checking processes, documentation and the audit trail against the protocol, SOPs and Good Clinical Practice. Sponsors audit their CROs and data management vendors, organisations run internal audits, and regulators such as the FDA, the MHRA or India's CDSCO carry out inspections.
Auditors typically look at:
- the data management plan, SOPs and training records
- evidence of database build testing and UAT, and how changes to the database were controlled
- query, data review, coding and reconciliation records
- QC results and the documentation behind the clean file and database lock
- the audit trail, including a trace of selected data points from source or CRF to the final database
Findings are graded by severity, commonly critical, major or minor, and answered with a corrective and preventive action (CAPA) plan. Note the difference in terms: an audit of clinical data management is a QA activity that examines the process, while the database audit before lock described above is a QC check of the data itself.
Where quality control fits in the lifecycle
Quality control is not a final gate alone; it runs throughout. It checks the system during set-up, monitors data and metrics during conduct, and provides the final confirmation at close-out that the clean-file criteria are met. Because it is the activity that ultimately vouches for the dataset, completing the required QC is a direct prerequisite for declaring a clean file and locking the database.
Frequently asked questions
What is quality control in Clinical Data Management?
Quality control is the set of checks that confirm data and deliverables meet defined quality standards. It is distinct from data cleaning, which fixes problems, and from quality assurance, which independently assures the process. QC verifies that the resulting data is genuinely fit for purpose, and it runs throughout the lifecycle, from checking the database build to confirming the clean file before lock.
What is the difference between quality control and quality assurance in Clinical Data Management?
Quality control checks the output — reviewing data and deliverables against defined standards to confirm they are correct. Quality assurance provides independent assurance that the processes producing the data were sound, typically through audits and oversight. QC is built into the data management workflow; QA sits independently of it. Both are needed for a trial to demonstrate reliable data.
What is an audit trail in Clinical Data Management?
An audit trail is the secure, time-stamped record of every change to the data: what changed, who changed it, when, and why. It allows any data point to be traced through its full history back to its origin. This traceability underpins data integrity and is what regulators rely on during an inspection to confirm the data reflects what actually happened in the trial.
Which regulations require an audit trail in clinical trials?
For electronic records, FDA's 21 CFR Part 11 requires secure, computer-generated, time-stamped audit trails that record when data is created, modified or deleted without obscuring the previous value. ICH E6 Good Clinical Practice expects the same of the computerised systems used in clinical trials, which is why EDC systems keep an audit trail as standard.
What are the ALCOA principles of data integrity?
ALCOA states that data should be Attributable, Legible, Contemporaneous, Original, and Accurate. The extended version, ALCOA+, adds that data should also be complete, consistent, enduring, and available. These principles define what trustworthy data looks like, and the audit trail is the main mechanism that makes them demonstrable in a clinical trial.
How is data quality measured in Clinical Data Management?
Quality is managed through metrics such as query rates and resolution times, the volume of open and ageing discrepancies, error rates found during QC review, and time to milestones like database lock. Defined acceptance criteria turn these into a clear standard, and tracking them throughout the trial lets teams catch systemic problems while there is still time to act.
What is database QC in Clinical Data Management?
Database QC, often called a data audit, is the check made before database lock to measure how accurately the database reflects the CRFs or source data. A sample of records is compared field by field with the CRFs, source documents or data listings, and the error rate found is compared with acceptance criteria set in advance, usually in the data management plan. Errors that point to a systematic problem are corrected across the whole dataset.
What happens in a Clinical Data Management audit?
Auditors review whether data was managed according to the protocol, SOPs and Good Clinical Practice. They examine the data management plan, database testing records, query, coding and reconciliation records, QC results, lock documentation and the audit trail, and trace selected data points from source to the final database. Findings are graded by severity and resolved through a corrective and preventive action (CAPA) plan.
Build quality expertise with TriTiCon
Quality control and data integrity run through every stage of the data management process. TriTiCon's training covers them in context across the lifecycle — from the conduct-stage cleaning and review in The Clinical Data Management Conduct Process to the final checks before lock in The Clinical Data Management Close-out Process. And because quality control is only half the picture, Oversight in Clinical Development takes the quality-assurance side further — the risk-based approach, sponsor oversight, trial-level metrics (KPIs and KQIs), and the QCs and spot checks that keep a trial's data reliable. Explore the full TriTiCon course platform to see how quality is built in at every step.
