Data entry error rate calculator for clinical trials

The arithmetic is simple; the definitions are not. An error is a value in the database that differs from the source document or from the value the protocol rules require, and that was not caught and corrected by a query. A field is a single data point, a result, a date, a code, a yes/no, not a form or a page. An inspection compares a field with the source (or with a second independent entry). State all three in the data management plan, because "three errors on a page" and "three errors in 1,200 fields" are not the same rate, and an error rate calculated on a different base cannot be compared. Count each wrong field once, and decide in advance whether a missing value, an unexplained out-of-range value and a transcription difference are all errors or are separated by type.

Report error rates at the point in the process where they are measured. The entry error rate is measured on first-entry data before cleaning, and says how good the capture process is. The residual (database) error rate is measured after queries, SDV and cleaning, and says how good the data you will analyse are. A site can have a high entry rate and a low residual rate if checks and queries do their job, so a single number without its measurement point can mislead. It is also different from the query rate, such as 96 queries on 4,800 entered fields (2 per 100 fields), which counts questions raised, many of which turn out to be correct values.

For the interval, the Wilson score interval for a proportion is a good default: for x errors in n fields, with z = 1.96, it avoids the failures of the plain normal interval when x is small. For 12 of 4,800 it gives 14.3 to 43.6 per 10,000. For 3 of 2,500 (12 per 10,000) it is 4.1 to 35.2 per 10,000. With zero errors the rule of three is a useful shortcut: the 95% upper bound is about 3 / n, here 12 per 10,000 for 2,500 fields (the exact value is 11.98). The precision you need sets the audit size: n = z² p(1 − p) / d², so a rate near 25 per 10,000 estimated to within ±5 per 10,000 needs about 38,320 fields. That is far more than a typical audit sample, which is why a single audit should be read as a signal, not a measurement to the second decimal.

No single figure fits every field. A transcription slip in the time of a vital sign hardly matters; the same slip in a primary endpoint, a dose, a date of randomisation or an adverse-event seriousness flag can change a conclusion or a safety decision. Quality-by-design and risk-based guidance asks sponsors to identify critical data and processes and to apply controls proportionate to the risk, rather than to chase an identical number everywhere. This page does not cite a numeric regulatory limit, and none should be written into a plan from a blog or a vendor page. Set the target in your data management plan and quality risk assessment, justify it by field criticality, and have it approved by the people accountable for quality. Confirm the current regulatory wording with your QA lead.

A practical structure is to split fields into tiers: critical (primary and key secondary endpoints, eligibility, safety, randomisation and dosing data) and non-critical. Set a tighter target and a higher verification coverage for the critical tier. Decide in advance what happens when the interval for the critical tier exceeds the target: widen verification at the sites with the most errors, retrain, fix the form design (a poorly worded field generates errors everywhere), and re-audit. A rate that is flat across sites points to the form or the source; a rate concentrated at one site points to training or a local process. The risk-based quality management guide and the clinical data management process explain how these decisions fit the wider plan.

Reducing errors at entry. Capture is direct electronic entry, so the transcription step that double data entry guards against does not exist. Instead, edit checks (range high, range low and custom value rules, each with a configurable priority) fire when a site enters a value that breaks a rule and raise an auto-query while the site still has the participant or the source record. Skip logic hides questions that do not apply, calculated fields (BMI, BSA, eGFR, QTc and others) show derived values read-only so nobody types them, and approved forms are locked for live use so the form a site completes is the form the study approved. Pre-built eCRF templates give a starting point for the common forms.

Resolving errors. Query management tracks each query from raising to resolution, and the field-level audit trail records the timestamp, the user, the old value, the new value and the reason for every change, and is exportable and cannot be modified through the interface. That makes the correction history countable: the proportion of fields changed after entry, and for which reasons, is a direct measure of the entry error rate that survived to the point of being corrected.

Measuring what is left. Source data verification can be set per field, so the critical-tier fields can be verified at a higher coverage than the rest, as described in risk-based monitoring and SDV software and the glossary entry on source data verification. The monitoring dashboard shows progress, and CSV or Excel exports with a data dictionary let a data manager tabulate errors found at verification against fields verified, by form, site or reason, using the formulas on this page. Capture does not claim a built-in error-rate report; the rate is calculated from these exports. For the surrounding process see the clinical data cleaning guide, the data management plan template and the data validation plan template.