Electronic Data Capture and REDCap

Overview

Electronic data capture (EDC) moves study information into a structured digital system where forms, validation rules, user permissions, change history and exports can be managed systematically. REDCap—Research Electronic Data Capture—is a widely used, metadata-driven research platform that supports web-based data entry, audit trails, data exports and configurable research workflows.[1,2]

The presence of an EDC system does not by itself create high-quality or compliant research. The study team still has to define variables, configure forms correctly, test the project, control access, document changes, train users and understand the local hosting and governance environment. Current FDA guidance likewise focuses on whether electronic systems and records used in clinical investigations are trustworthy and reliable for their intended purpose, rather than treating a software name as proof of compliance.[3,4]

Why this matters

Electronic systems can prevent many avoidable errors: they can restrict data types, show relevant fields conditionally, calculate scores and make records available to authorised team members without moving paper forms. They can also propagate errors at scale. A wrong branching rule can hide an outcome for every participant; an incorrect calculation can create hundreds of wrong derived values consistently.

EDC therefore shifts part of quality control from post-entry checking to metadata and configuration design. That makes testing before production especially important.

Think in data structures before screens

A REDCap project is easier to design when the underlying data structure is clear. Ask first:

• What is one participant or record?
• Which instruments occur once and which repeat?
• Is the study longitudinal with predefined events?
• Can an event occur an unknown number of times?
• Which fields identify site, visit or occurrence?
• Which data are directly identifying?
• Which variables are raw and which are calculated?

Do not begin by creating a long list of fields in one instrument. Divide the project according to workflow and repeated structure.

Instruments and field types

REDCap supports common field types such as text, notes, radio buttons, dropdowns, checkboxes, yes/no fields, calculated fields and descriptive text. Choose the field type that matches the variable’s meaning.

Examples:

• Use a date-validated text field for delivery date.
• Use radio buttons for mutually exclusive categories such as verification status.
• Use checkboxes only when multiple categories may apply simultaneously.
• Use a notes field for genuinely open text, not for structured variables that will later be coded.
• Use calculated fields only when the calculation is stable, documented and appropriately tested.

Field labels should be understandable to users; variable names should be stable and analysis-friendly. Avoid changing variable names after data collection begins unless the consequences for exports, calculations and downstream scripts are understood.

Branching logic

Branching logic can hide irrelevant fields and reduce contradictory data. For example, external laboratory details can appear only when lab_source = external. However, hidden fields may retain older values if upstream responses are changed, depending on workflow and configuration. Test edit scenarios, not only first-time entry.

Complex branching is harder to audit. When logic becomes difficult to read, simplify the form or document the rule in the data dictionary. A shorter expression that matches the study definition is preferable to clever logic that only one designer understands.

Validation and edit checks

Data-type validation, minimum/maximum ranges and custom checks can improve quality, but validation limits should represent plausible study rules rather than arbitrary expectations. A blood glucose value outside a typical range may be clinically important rather than erroneous.

Use soft checks when unusual values are possible and hard restrictions when a value is structurally impossible, such as letters in a numeric identifier. Date checks can flag impossible sequences, but cross-field logic may require data-quality rules or external review rather than a single field constraint.

Longitudinal projects and repeating instruments

Use longitudinal events when the study has a defined schedule such as baseline, discharge and week-12 follow-up. Use repeating instruments or repeating events when occurrences can vary in number, such as contact attempts, adverse events or unscheduled laboratory tests.

A common design mistake is to create fields contact1, contact2, contact3, and so on. This embeds an arbitrary maximum into the schema and produces a wide, awkward dataset. A repeatable contact-attempt instrument usually represents the process more faithfully.

For analysis, ensure each exported row can be identified by participant, event and repeat instance as appropriate.

Identifiers and protected information

REDCap can hold identifiers needed for recruitment or follow-up, but access should be role-based. A central analysis export does not need every participant’s name, telephone number and medical-record number.

Separate or restrict identifying instruments where feasible. Marking fields as identifiers may support de-identification options, but study governance must still define who can view, export or edit them. System configuration and local policy determine the practical protections available.

User roles and privileges

Plan roles such as site data collector, site investigator, central data manager and statistician. Relevant privileges can include record creation, viewing, editing, exporting, form locking, project design and user-right management.

Shared accounts undermine accountability. Each authorised user should have an individual account where the hosting environment supports it. Remove or change access promptly when duties change or staff leave.

Current electronic-record guidance emphasises controls over authorised users, system use and record reliability.[3]

Audit trails and corrections

One advantage of an EDC system is the ability to preserve change history. REDCap includes logging of data changes and project activity as part of its research workflow design.[1,2] The study should nevertheless define when a correction requires a reason, how queries are resolved and whether critical changes are reviewed.

Audit trails are most useful when data are entered directly into the system or when transcribed values can be traced back to their source. Exporting data to a spreadsheet, modifying them silently and re-importing final values can destroy part of that traceability unless the process is controlled.

Development, testing and production

Separate project development from production use. Before collecting real participant data, test:

• every instrument;
• all branching paths;
• calculations;
• repeating forms and events;
• validation ranges;
• survey invitations where used;
• user roles and site restrictions;
• record locking or signatures where relevant;
• exports and codebooks;
• missing-data codes;
• data-quality rules; and
• correction workflows.

Use scripted test cases and document acceptance. Once the project is in production, substantive changes should be controlled and assessed for effects on existing records and comparability.

PROTOCOL CHECKLIST

REDCap project readiness checklist

• Data model and instrument structure match the protocol.
• Variable names and labels match the data dictionary.
• Branching and calculations have passed scripted tests.
• Repeating events or instruments represent repeated processes correctly.
• User roles follow minimum-necessary access.
• Identifiers are recognised and protected from routine exports.
• Data-quality rules target meaningful errors.
• Export structure has been reviewed with the analysis team.
• Production changes follow a documented change process.
• Local backup, availability, retention and incident responsibilities are understood.

REDCap surveys versus data-entry forms

A REDCap survey allows respondents to enter data through a survey interface; a data-entry form is typically completed by authorised project users. Participant-facing surveys require additional attention to invitation links, identity verification where needed, privacy, accessibility, save/return behaviour and the possibility of duplicate or unintended responses.

Do not assume that a unique survey link proves identity unless the study workflow establishes who received and used it. The authentication needed depends on the consequence of misidentification.

Exports and reproducible analysis

Test the exact export that analysts will receive. Review variable names, labels, checkbox encoding, date handling, repeated records and calculated fields. Keep a record of the export date and dataset version supporting an analysis.

Avoid manually “cleaning” the only exported copy. Preserve a raw or minimally transformed export, then perform documented cleaning and derivation in a reproducible workflow. The related Biostatistics lecture on preparing medical data for analysis develops these principles further.

WORKED EXAMPLE

Representing follow-up contact attempts

Instead of six fixed columns for six possible calls, the team creates a repeating contact_attempt instrument containing:

• attempt date and time;
• contact channel;
• outcome of attempt;
• whether identity was confirmed;
• whether follow-up assessment was completed; and
• reason contact did not proceed.

A participant can have zero, one or many instances. The final outcome form is separate and records the verified postpartum-test status. This prevents an operational activity—calling the participant—from being confused with the scientific outcome—whether testing occurred.

REDCap and regulatory claims

REDCap has technical features useful for controlled research data capture, and its design has been described in peer-reviewed methodological papers.[1,2] However, statements such as “REDCap is FDA compliant” are too broad. Compliance depends on the applicable regulation and on the entire implementation: hosting, validation, procedures, user management, electronic signatures where applicable, backups, training and study use.[3,4]

Phrase claims precisely. It is safer to describe the features used and the local controls applied than to infer compliance from the platform name.

Metadata-driven project governanceMMed extension

REDCap’s data dictionary and project metadata can support reproducibility because they describe field names, types, labels and logic. Retaining a metadata export with each major project release can help reconstruct how the database was configured at that point.

This is especially valuable when analyses occur months after recruitment or when a project is migrated. FAIR data-stewardship principles reinforce the value of well-described data and metadata while still allowing controlled access for sensitive human data.[5]

Governance of production changes

Electronic projects evolve, but production changes should be treated as controlled changes to a measurement system. Before modifying a field, ask whether the change affects existing data, branching logic, calculated values, exports, user rights or the interpretation of responses already collected.

A useful change record includes the request, rationale, risk assessment, approval, testing evidence, implementation date and any migration performed. If historical records require recalculation, use a reproducible script or controlled batch process rather than manual editing where possible.

Design for downtime and recovery

Even reliable systems can become temporarily unavailable because of maintenance, network failure or local connectivity. Decide prospectively what staff should do when the EDC cannot be reached. Options may include pausing non-urgent collection, using a controlled downtime form or capturing information in an approved source for later transcription.

The procedure should specify how delayed entries are identified and reconciled after service returns. Creating unofficial spreadsheets or personal notes during every outage can fragment the source trail.

Evaluate usability as part of validation

Technical correctness is not enough if users routinely choose the wrong field or cannot find the appropriate instrument. During user acceptance testing, observe representative staff completing scenarios. Record navigation problems, confusing labels, excessive clicks and places where the interface encourages workarounds.

A form that reduces data-entry time by several minutes across hundreds of visits can improve both efficiency and completeness. Conversely, aggressive required fields or poorly organised instruments can create false data despite technically valid configuration.

Separate project design privileges from data-entry privileges

Few users need authority to alter metadata in production. Restrict project design and user-right administration to designated personnel. Site collectors usually need record-level functions, while investigators may need review or locking privileges. This separation reduces accidental structural changes and supports accountability.

Plan archival exports

At important milestones, preserve not only participant data but also project metadata, data dictionary, relevant configuration documentation and the code used to create analysis datasets. This is particularly useful if the REDCap project later changes or the institution upgrades systems.

APPRAISAL CHECKLIST

Appraise an EDC project before production

• Does the database represent the actual study data model?
• Are critical logic and calculations covered by scripted tests?
• Have realistic users completed acceptance testing?
• Are design and export privileges restricted appropriately?
• Is there a controlled process for production changes?
• Is a downtime workflow defined?
• Can audit information reconstruct important corrections?
• Can the project metadata and final data releases be archived reproducibly?

Keep training and production environments distinct

Where the local REDCap installation permits it, use test records or a designated training project rather than entering fictitious participants into the live production dataset. Training artefacts can otherwise contaminate recruitment counts, exports and audit review. If production testing is unavoidable, define how test records are unmistakably identified and removed or excluded without obscuring the audit trail.

Common mistakes

Knowledge check

A participant may be contacted any number of times. What REDCap structure is usually preferable to fields contact1 through contact6?

Answer and reasoning

A repeating contact-attempt instrument, because the number of occurrences is not inherently fixed and each attempt has the same structure.

Does using REDCap automatically make a study compliant with electronic-record regulations?

Answer and reasoning

No. The applicable regulatory requirements and the local implementation, validation, procedures, access controls, training and hosting environment all matter. Software capability is only one part of the system.

Why should analysts inspect a test export before production?

Answer and reasoning

Screen layout can conceal how data are encoded. A test export reveals variable names, checkbox coding, repeated-record structure, date formats and calculated values that affect cleaning and analysis.

When can a validation rule be harmful?

Answer and reasoning

When it rejects values that are unusual but possible, encouraging staff to alter true observations. Validation should detect likely errors without deleting legitimate extremes.

Key take-home messages

SUMMARY

Key take-home messages

• Define the data model before configuring REDCap instruments and events.
• Use field types, branching, validation and repetition to represent the research process faithfully.
• Apply role-based access and minimise exposure of direct identifiers.
• Test forms, logic, permissions and exports before production and control later changes.
• Preserve auditability and reproducible data releases rather than cleaning by undocumented manual edits.
• Describe REDCap’s actual configured controls; do not equate a software platform with automatic compliance.

References

1. Harris PA, Taylor R, Thielke R, Payne J, Gonzalez N, Conde JG. Research electronic data capture (REDCap)—a metadata-driven methodology and workflow process for providing translational research informatics support. J Biomed Inform. 2009;42(2):377–381. https://doi.org/10.1016/j.jbi.2008.08.010
2. Harris PA, Taylor R, Minor BL, Elliott V, Fernandez M, O’Neal L, et al. The REDCap consortium: building an international community of software platform partners. J Biomed Inform. 2019;95:103208. https://doi.org/10.1016/j.jbi.2019.103208
3. US Food and Drug Administration. Electronic systems, electronic records, and electronic signatures in clinical investigations: questions and answers. Guidance for industry. Silver Spring (MD): FDA; 2024. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/electronic-systems-electronic-records-and-electronic-signatures-clinical-investigations-questions
4. 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
5. 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