Blog · Study designUpdated October 16, 2026

GLP-1 trial data capture: lessons for small sponsors

Weight management trials look simple on paper: weigh people, compare the change. In practice, the data problems sit in measurement conditions, units, dose records, diaries and what happened when a participant stopped or changed treatment. This is a practical list. It makes no clinical claims.

  • Nine data-capture lessons
  • Operational, not clinical
  • Demo examples only

Free sandbox · No credit card · 21 CFR Part 11 aligned

Body weight form (demo)
Subject 001-0042 · Visit 4 (Week 12)Draft

Measurement conditions

Weight

WEIGHT
91.4kg

Height (screening value)

HEIGHT
172cm

BMI

BMI

Calculated, read-only

30.9 kg/m2 Calculated

Scale used

Site scale A

Fasted?

YesNoUnknown

Measured by

Site staffParticipant at home
Demo values onlySave
The conditions matter as much as the number.

The nine lessons in brief

  • A weight is only as good as its conditions. Capture the scale, who measured, and whatever the protocol says must be standardised, so the number can be defended later.
  • Collect raw inputs, derive the rest. Height and weight in, BMI out. Never ask a site to type a calculated value.
  • Make units explicit. Mixed kilograms and pounds are a classic source of silent errors.
  • Treat dosing as data, not a footnote. Planned dose, actual dose, missed doses and titration changes belong on their own structured forms.
  • Design the diary around dosing days. Symptom entries are far more useful when you know when the last dose was taken.
  • Record why treatment stopped or changed, and what else the participant started, so analysts can handle those events later.
  • Label the source of every value: site-measured, participant-reported or device-derived.
  • Use edit checks for implausible values, and listings for implausible changes.
  • Plan the export on day one, including a data dictionary.

Scope

What this post is, and is not

GLP-1 receptor agonists and related therapies have made weight-management trials a busy area. Small sponsors, academic groups and device or digital-health companies are now running studies that used to be the territory of a few large programmes. Many hit the same operational snags.

This post is about data capture only. We say nothing about how well any therapy works, about its safety profile or about how to design an endpoint, and none of the figures here come from a real study. If you want to see how Capture is set up for this type of study, the product-fit page is EDC for GLP-1 and weight management trials. This post is the lessons list: the things we would check in any weight-management build before go-live.

Lessons 1 to 3

Weight, conditions and units

In most weight-management protocols, body weight (or its change) is central. That makes small measurement differences matter, and it makes the conditions of measurement part of the data.

Lesson 1: record the conditions the protocol standardises

Whatever your protocol requires for a valid weight, such as a calibrated scale, light clothing, time of day or fasting status, should be a field or a completion instruction, not an assumption. A dropdown for the scale used and a simple fasted yes/no cost a second at the site and give the statistician something to check if a site's results look different. Where weights are also taken at home, capture a separate flag so the two sources can be told apart.

Lesson 2: collect raw inputs, derive the rest

Capture calculates BMI from height and weight as a read-only field during entry, and offers other calculated fields such as BSA and waist-hip ratio. The principle applies to any system: staff enter measured values, the system derives the result, and nobody re-keys a calculator output. Add a dedicated height field at screening and decide whether it is re-measured at later visits. Our vital signs eCRF template and DEXA body composition eCRF show how these forms are laid out.

Lesson 3: make units explicit and check ranges

If a site can enter either kilograms or pounds, store the unit with the value or fix the unit on the form and say so in the field label. Add range-high and range-low edit checks at plausible limits so that a typo (91.4 entered as 914 or 9.14) raises an auto-query as the value is entered, not at the monitoring visit. Keep the limits wide enough that real values never trigger them, since a query on every entry trains staff to ignore queries.

Design table

Fields worth adding to a weight-management build

A starting list, to be adjusted to your protocol. Fields and thresholds are illustrative.

Data pointField designWhy it helps later
Body weightNumber with fixed unit, range edit checkCatches typos at entry
HeightNumber captured at screening (and later if protocol-defined)BMI is derived, not typed
BMICalculated, read-onlyRemoves manual calculation error
Scale used / who measuredDropdown / single choiceExplains site or source differences
Fasting statusSingle choice: yes, no, unknownSupports protocol-deviation review
Waist circumferenceNumber, with measurement site if the protocol defines oneConsistent technique across sites
Dose administered (date, time, amount)Dosing form or table section, one row per doseLinks diary symptoms to dosing
Missed or delayed doseYes/no with reason and dateSeparates adherence from outcome
Reason for treatment change or stopSingle choice plus free text, with dateSupports later handling of intercurrent events
Other weight-affecting medicationConcomitant medication table sectionContext for any weight change

Capture's eCRF forms support table sections for repeating rows, which suits dose and concomitant medication records.

Build the form, then test it with demo data

Draft a weight and dosing form in the free sandbox, add a range check, and see the auto-query fire. No credit card, and you pay only when you go live with real participants.

Build your study free

Lessons 4 and 5

Dosing records and the diary around them

Weight management therapies are often given on a schedule that changes over the first weeks, and many trials ask participants to record how they feel. Both are data design problems before they are clinical ones.

Lesson 4: treat dosing as structured data

Do not rely on a single "treatment compliance" yes/no. Give dosing its own form with the planned dose, the actual dose, the date and time, and a repeating row per administration if the protocol needs that level of detail. When a dose is missed, delayed or changed, add a reason. Self-administered injections are a special case: decide in advance whether the record is site-observed, participant-reported or from a diary, and mark it.

Lesson 5: design the diary around dosing days

An ePRO diary for tolerability, appetite or injection-site reactions is only interpretable if you can place each entry relative to dosing. Put the date of the last dose in the same data model (or at least in an exportable dataset joined by participant and date), keep the number of questions small so completion stays high and use the same wording across visits. Capture's ePRO offers ten question types and participants complete questionnaires from a link without installing an app. See GI symptoms diary examples and our guide to digital patient diaries, and aim to read compliance by week as your study runs (ePRO compliance and completion rates).

Lessons 6 to 9

Stops, sources, checks and exports

The last four lessons are about making sure the dataset can still be analysed honestly when real life intrudes.

Lesson 6: record why treatment stopped or changed

Participants stop, pause, switch dose or begin other treatments. How those events are handled in the analysis is a statistical decision, discussed in the ICH E9(R1) addendum on estimands, and your statistician owns it. Your job in the EDC is to make sure the raw facts exist: a date, a reason from a defined list and a link to any new medication. Retrofitting that from free text at database lock is slow and unreliable.

Lesson 7: label the source of every value

Site-measured, participant-reported and device-derived values behave differently. If weights arrive from a connected scale or from a wearable, keep that as a separate field or flag rather than blending it into the site column. Capture connects wearables by native OAuth sync, with the participant connecting their own account, and the FDA's final guidance on digital health technologies for remote data acquisition (22 December 2023) is the document to read on fitness for purpose and usability. See EDC for wearable device studies and the FDA DHT guidance explainer.

Lesson 8: edit checks for values, listings for changes

Capture's edit checks are range-high, range-low and custom value rules on a field, raising an auto-query when a value breaks a rule. A large drop between two visits is a different question, and a monitor or data manager review listing is a more honest tool than an automatic query that might reflect real change. Decide before go-live which anomalies get a rule and which get a recurring review. See edit checks software.

Lesson 9: plan the export on day one

Ask your statistician what they need: wide or long format, a data dictionary, SDTM domains. Capture exports CSV and Excel with an automatic data dictionary, and SDTM datasets as SAS XPT files with Define-XML. If your protocol follows the ICH M11 structured template, which reached Step 4 on 19 November 2025, aligning your visit schedule and forms to it makes the build easier to audit. Our ICH M11 guide explains the template.

Go-live check

A pre-launch checklist for weight-management builds

Weight and conditions are on the form

Scale, who measured, fasting or other protocol conditions, with fixed units.

BMI and similar values are calculated

Nobody types a derived value; the field is read-only.

Range checks are tested

Enter a deliberately wrong value in the sandbox and confirm an auto-query is raised.

Dosing has its own form

Planned vs actual, missed or changed dose, date and reason.

Diary entries can be tied to dosing

The last dose date is available in the export.

Stops and changes have a reason list

Agreed with the statistician before go-live.

Source of each value is labelled

Site, participant or device.

Export tested with demo data

Data dictionary and, if needed, SDTM output checked by the person who will analyse.

Worked example

A demo schedule that keeps the data joined up

This is an invented 24-week schedule showing which forms exist at which visits. It is not a protocol recommendation. The pattern to copy is that weight, dosing and the diary are scheduled together.

  • Screening captures height, consent and baseline weight.
  • A dosing form is completed at every visit.
  • A short symptom diary runs weekly (D).
Schedule of assessments builder
Demo schedule of assessments
AssessmentScreenWk 0Wk 4Wk 8Wk 12Wk 24
Consent
Weight and conditions
Dosing record
Concomitant medications
Symptom diaryDDDDD

x = site visit form, D = weekly participant diary

Illustrative only.

Where Capture fits

Using Capture for this, honestly

Capture puts EDC, the eCRF builder, ePRO, eConsent and safety reporting in one system with one audit trail, for Phase 1 through Phase 3, with a free sandbox where you can build and test all of the above. You can also upload a protocol and let the AI study builder draft visits and forms, which you then review. Pricing is not published on the site, so ask us.

This is a data-capture post. It does not claim that any particular trial design, endpoint or safety plan is right for your therapy. Your protocol, your statistician and your regulators decide that.

FAQ

Common questions

Something not covered here? Ask us directly.

What data does a GLP-1 clinical trial usually need to capture?

It depends on the protocol, but common elements are serial body weight and related measures, dosing and titration records, concomitant medications, safety data and participant-reported diaries. This post covers the data-capture design for those, not the clinical design.

Should BMI be entered by the site or calculated?

Calculated. Sites enter height and weight, and the system derives BMI as a read-only field, which avoids transcription and calculator errors. Capture calculates BMI during entry.

How do I handle kilograms and pounds in a multi-site trial?

Fix the unit on the form, or store the unit alongside the value, and add range checks so an implausible value raises a query immediately. Decide the rule in the data management plan.

How should dosing be recorded?

On its own structured form, with planned dose, actual dose, date and time, and a reason when doses are missed, delayed or changed. Avoid relying on a single compliance yes/no.

Can edit checks catch a large weight change between visits?

Capture's edit checks are range and custom value rules on a field. For visit-to-visit change, plan a review listing as well, since a big change may be real.

Can I use wearable or connected-scale data?

Capture supports native OAuth wearable connections where the participant connects their own account. Label device-derived values separately from site-measured values and read the FDA's DHT guidance on fitness for purpose.

Does this post say anything about safety or efficacy?

No. It covers operational data capture only. Safety and efficacy design belong in your protocol and with your clinical and statistical leads.

Test your weight-management build with demo data

Free sandbox with every feature. No credit card, and you pay only when you go live with real participants.

Build your study free