Longevity studies measure biological age from a blood or saliva sample, then compare it over time. This template captures the parts a study team controls: who the participant is by date, which sample, which assay, which lab or vendor, which report, and chronological age at sampling.
Free sandbox · No credit card · 21 CFR Part 11 aligned
Sample
Date of birth
BRTHDTCSample collection date and time
LBDTCChronological age at sampling
AGECalculated from date of birth and sample date
50 years CalculatedSample type
SPTYPEFasting at collection
LBFASTAssay and report
Laboratory or vendor
LBNAMAssay or panel name
LBTESTReport date
RPTDTCPending: sample shipped 03-Mar-2027
At a glance
Why it matters
Longevity and healthspan studies often use a biological age estimate as an exploratory or secondary outcome, alongside clinical measures such as blood pressure, laboratory panels and questionnaires. The estimate itself arrives as a number, or a set of numbers, on a report from a laboratory or vendor. The data problem is rarely the number. It is everything around it: which sample produced it, whether it was collected under the same conditions each time, which vendor and which method version generated it, and how it links to the participant's other data.
In a small study that context often lives in an email thread and a spreadsheet. By the time a statistician needs it, a sample ID has been retyped, a vendor changed its method between baseline and follow-up, and nobody can say which. A form attached to the visit, with required fields and an audit trail, prevents most of it. Our EDC for longevity clinical trials page covers the wider workflow for these studies.
A participant sampled at baseline and again at, say, month 6 and month 12 produces several rows of the same structure. Because each visit carries its own form with the same fields, the dataset is already in the long format an analyst wants, and an exported data dictionary explains each variable.
It does not reproduce any vendor's or publisher's clock algorithm, input panel or item wording, and it does not calculate biological age. Each clock has its own licence, method and reporting format, and those belong with the vendor or publisher. Enter the result, units and method version exactly as the report gives them.
Template
| Field | Type | Notes |
|---|---|---|
| Date of birth | Date | Source for chronological age; PII handling per your role setup |
| Sample collection date and time | Date-time | Required; used for age and for time-in-study |
| Chronological age at sampling | Calculated (years) | Age from date of birth, shown read-only |
| Sample type | Single choice | Whole blood, saliva, buccal swab, other |
| Sample ID or barcode | Text | As labelled on the tube; links to the vendor manifest |
| Fasting status | Single choice | If the protocol specifies conditions |
| Collection and storage notes | Text | Time to freezing, deviations from the lab manual |
| Shipment date and courier reference | Date, text | Chain of custody |
| Laboratory or vendor name | Text or dropdown | Each vendor listed once for consistent analysis |
| Assay or panel name and method version | Text | Exactly as stated on the report |
| Report date | Date | Date the vendor issued the result |
| Reported biological age estimate | Numeric (years) | Entered as reported, with the unit given |
| Other reported measures | Table rows | Vendor-specific values, one row each with name, value and unit |
| Sample quality or failure flag | Single choice | Passed, failed QC, recollected |
Adapt to your protocol and vendor report. Keep names and units exactly as reported.
In Capture
Capture's calculated fields include age from date of birth, which appears read-only during entry. Vendor-reported results go into numeric fields or a repeating table section where each row has its own audit trail. Edit checks can raise an auto-query when a value is outside a range you set, for example a missing report date or an implausible age, and the AI form builder can draft the form from your vendor report layout or an uploaded description, with nothing saved until you review it.
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
Upload a report layout or describe the fields, then review and test in the free sandbox with sample data.
Data quality
Longitudinal comparison depends on consistency. If the baseline sample is processed by one laboratory and the follow-up by another, or the vendor updates its method in between, a difference in the numbers may reflect the process, not the participant. Recording the vendor, assay name and method version on every form makes that visible so the analysis plan can handle it, and the audit trail records any later correction with a reason.
Sample collection conditions matter in the same way. Time of day, fasting status, collection method and storage delay can all differ between sites, so capture them as fields rather than free-text notes. For multi-site studies, a site-level participant numbering scheme and by-site exports make site differences easy to review; see wearable data integration for linking this form with continuous device data in the same study.
Time between samples is another quantity worth structuring. Define the visit schedule so each sample falls within a window around the planned day, and use the visit windows in the schedule to flag late or early collection. Participants who start a new intervention, supplement or medication between samples should have that recorded on the concomitant medications eCRF, so the analyst can see what changed. A short vital signs form at each sampling visit gives context for the biological age value without adding a second system.
Finally, treat the vendor's report as source. Attach or store the original report according to your source data plan, enter the values from it, and use source data verification on the fields that feed your endpoints. The result of any clock stays the vendor's result; your study documents what was reported and when.
Date of birth is personal data. In Capture, site coordinators see participant names while researchers see coded IDs, and your consent form should say what is shared with the vendor. See the wearable data sharing consent template and the genomic research consent template for sections to adapt when samples are analysed for DNA-based measures.
Before go-live
Vendor, assay and version named, with a rule for changes.
Collection date, type and sample ID cannot be left blank.
Chronological age from date of birth and sample date.
Name, value and unit exactly as on the report.
Shipment date and reference recorded.
Sample use and vendor data sharing described.
Original report stored per the source data plan.
Sample type and collection date, sample ID, handling conditions, laboratory or vendor, assay and method version, report date, the reported values with units, and chronological age at sampling.
No. It captures the value from the vendor or laboratory report. It calculates only chronological age, from date of birth and the sample date.
No. It is a data capture structure and makes no claim about the validity of any clock. Choose and justify the measure in your protocol.
Yes. Add a repeating table section with one row per reported measure, each with name, value and unit, entered as reported.
Every change is recorded in the field-level audit trail with timestamp, user, old value, new value and reason.
Yes. The Capture sandbox is free with every feature and no credit card; you pay only when you go live with real participants.
Keep exploring
Sample metadata, vendor reports and an audit trail. Free sandbox, no credit card, pay only when live.