Clinical trial software for clinical data scientists who need data they can trust
Models and analyses are only as good as the capture behind them. Capture gives you structured, traceable source data with a data dictionary, derived fields computed at entry, and standard exports, from a study you can set up yourself.
- Traceable source
- Data dictionary on every export
- SDTM as SAS XPT
Free sandbox · No credit card · 21 CFR Part 11 compliant
| SUBJ | ECGPERF_CODE | ECGPERF_LABEL |
|---|---|---|
| 01-001 | Y | Yes |
| 01-002 | ND | Not done |
What data scientists get
- Provenance: a field-level, append-only audit trail with user, time, old value, new value and reason, so every value in your analysis set can be traced.
- Structure: CSV and Excel exports in wide format, one row per submission, with an automatic data dictionary, raw and decoded.
- Standards: every eCRF template carries an OID and an SDTM domain, and SDTM datasets export as SAS XPT with Define-XML.
- Derived variables at source: BMI, BSA, eGFR (CKD-EPI 2021), QTc corrections, age from date of birth and time between date-times are calculated at entry and shown read-only.
- Multi-modal inputs: eCRF, ePRO and, where a device is enabled for the study, synced wearable data sit in one study.
The role
What a clinical data scientist needs from the capture system
Clinical data scientists sit between data management and biostatistics. They explore data early, build derived datasets and pipelines, flag quality patterns that rules do not catch, and increasingly work with data streams that did not exist in older protocols. Their frustrations with capture systems are consistent: unclear provenance, free-text where structure was needed, derived values computed three different ways downstream, and exports that need cleaning before they can be read.
This page is about those frustrations. It does not repeat the data manager workflow, which is covered in software for clinical data managers, or the statistical programming handover, covered in EDC for biostatisticians and SAS programmers. It is the analytics-side view of the same system.
The practical point is that decisions made when the form is built decide what your pipeline looks like months later. If a score is calculated at entry, it is calculated once. If a unit is a field, not free text, you never parse it. If an answer to a question is a coded choice, you get a coded variable and a decoded label side by side. Being involved in build review is the cheapest data quality work you can do.
Provenance
Trace any value back to its origin
The audit trail is written by database triggers, one row per changed field, and the database blocks updates and deletes on audit rows. Each row records who, when, the old and new value and the reason. Repeating rows such as concomitant medications or lab results each carry their own trail. When a model flags an outlier, you can see whether it was keyed, corrected or queried.
- Append-only and hash-chained per study.
- Always exportable for review.
- Clinical data is soft-deleted only.
Weight changed 68.0 to 68.5 kg
Site coordinator · Reason: Transcription error
Query Q-0014 answered on Weight
Site coordinator · Reason: Source checked
Vital signs form locked
Data manager · Reason: Visit cleaned
Derived variables
Compute once, at entry
Calculated fields run during data entry and show as read-only. That means the BMI, creatinine clearance or QTcF in your dataset is the number the site saw, not a number recomputed with a different rounding rule downstream. You still re-derive for analysis when your statistical analysis plan requires it, but there is no silent disagreement with the source.
- BMI, BSA (Mosteller and Du Bois), waist-hip ratio, MAP, pulse pressure.
- eGFR CKD-EPI 2021, Cockcroft-Gault, QTc Bazett and Fridericia.
- Age from date of birth; hours or minutes between two date-times.
BMI (Body Mass Index)
Auto-derivedHeight (cm)
172
Weight (kg)
68.5
Result
23.2 kg/m²
Reference: WHO · shown read-only during data entry
Open a sample study and look at the export
Build a small study in the free sandbox, enter sample data and download the CSV, data dictionary and SDTM files before you commit to anything.
Outputs
What leaves the system, and what you do with it
| Output | What it contains | Typical use |
|---|---|---|
| CSV / Excel, wide | One row per submission, raw and decoded files, by site and date range | Loading into R or Python for exploration and QC |
| Data dictionary | Automatically generated codebook for each export | Labels, types and coded values without a separate document |
| SDTM as SAS XPT | Domain datasets from template OIDs and domains, with Define-XML | Handover to statistical programming |
| Audit trail export | Field-level change history | Data-integrity analysis and inspector requests |
| Blank eCRF PDF | Every approved form printed empty | Reviewing what each variable meant when it was collected |
Capture does not claim an open API or named analytics integrations; plan on file-based exports.
New data streams
Questionnaires and device data beside the eCRF
Patient-reported outcomes arrive in the same study as clinic data, with the same identifiers and audit trail. Where the study team enables a device, participants connect their own account and data syncs automatically, with last-sync time visible. For a pipeline, that means fewer joins across systems and a single subject key.
- ePRO and eCRF share one subject ID.
- Native OAuth device sync, enabled per study.
- Wearable data discussed on best EDC for wearable data.
Build review
What to ask for during form review
Units as fields, not free text
Make unit a dropdown or tie it to the numeric field so you never parse strings.
Coded choices over free text
Use single choice or dropdown with defined codes, and read raw and decoded files.
Derived values as calculated fields
Where a standard formula exists, compute at entry and document it.
Repeating rows for repeating data
Use table sections for medications or labs so each row has its own trail.
SDTM domain mapping noted early
Check the template domain on each form during build.
Getting started
From sandbox to a first pull
- 1
Spin up a sample study
Use a template or upload a protocol for an AI draft, then review.
- 2
Enter varied test data
Include out-of-range values to see the queries raised.
- 3
Export and inspect
Download CSV, the data dictionary and SDTM files, and load them in your tools.
- 4
Feed back to the build
Change a field, re-approve the form and compare the new export.
Can I get raw clinical trial data into Python or R from Capture?
Yes, through file exports: CSV and Excel in wide format, raw and decoded, with an automatic data dictionary. Capture does not claim a public API, so build pipelines around file exports.
Does Capture export SDTM?
Yes. SDTM datasets export as SAS XPT files with Define-XML, based on the OID and SDTM domain carried by each eCRF template.
How do I trace an odd value in my dataset?
Use the field-level audit trail: it shows who changed it, when, the old and new values and the reason, and it can be exported.
Can I work with wearable data in the same study?
Where the study team enables a device, participants connect their own account via the vendor sign-in and data syncs automatically. Ask us which devices are available for your study.
Is the audit trail editable?
No. It is append-only: the database blocks updates and deletes on audit rows, and each row is hash-chained.
How is this different from the data manager page?
The data manager page covers building, cleaning and locking. This page covers what a data scientist uses afterwards: provenance, structure, derived variables and exports.
Can I try this before involving IT?
Yes. The free sandbox includes the full feature set with no card and no time limit.
Look at the export before you commit
Build a sample study and download the data, free. No credit card.