AnzarSeha

Clinical data capture

By Dr Rida Akodad · Publication director · Updated 21 August 2026

Capture is the stage where an observation becomes a value in a database. It is also the most irreversible stage of a study: what was not captured, or was captured without its context, generally cannot be recovered.

The four routes of capture

RouteWhat it isIts characteristic weakness
Direct entryAn operator reads a record and types into a formTranscription error, fatigue, implicit interpretation
Structured importExisting fields are taken from a source systemThe source field may not mean what is assumed
Deterministic ruleA value is computed from others (BMI, stage, delay)The rule must be versioned, or it changes silently
Extraction from textA value is drawn from a free-text reportWithout the source sentence quoted, unverifiable

A serious study mixes all four. What matters is not favouring one, but that every value knows which route it came by — see data provenance.

Retrospective and prospective: two different problems

Retrospective capture

The data already exists, in records written to treat rather than to research. The constraint is heterogeneity: what was noted varies from clinician to clinician and year to year, and the absence of a mention does not mean the absence of the sign.

  • Absence is ambiguous by nature: "not noted" is not "absent".
  • Definitions may have changed during the study period.
  • You cannot go back and ask the patient: a missing datum is missing for good.

Prospective capture

The protocol precedes observation, which allows exact definition of what will be measured and how. The constraint shifts to exhaustiveness over time: keeping capture complete across eighteen months demands a discipline that clinical workload tests.

Design mistakes that cannot be undone

  1. A free-text field where a list belonged. Three hundred free entries of "stage" produce forty variants to be recoded by hand, with the risk of inventing a category the author never meant.
  2. The implicit unit. A creat column with no declared unit becomes unusable the moment a department changes laboratory. See UCUM.
  3. The all-purpose empty cell. The same blank serves for "not sought", "normal" and "information lost". The three are handled differently and become indistinguishable.
  4. The measurement with no date. A value without a date cannot be placed in the follow-up; it is lost to any longitudinal analysis.
  5. The endpoint defined afterwards. This is the error that invalidates the inference rather than the data — and the only one that protocol locking prevents mechanically.

Designing the collection form

The collection form — *fiche d'exploitation* in the francophone tradition, case report form elsewhere — is the instrument of the study. Its design is judged on three criteria.

  • It asks only for what will be used. Every variable should map to a question in the planned analysis. A variable collected "just in case" will be incomplete, and its incompleteness will pollute the analyses it appears in.
  • It constrains rather than suggests. Types, closed lists, bounds: constraint at entry costs less than correction afterwards.
  • It is reusable. Reusing CDASH names and definitions where they exist makes the dataset legible to others and comparable with others.

For the electronic form of this instrument and what distinguishes it from an ordinary web form, see the electronic case report form.

How AnzarSeha addresses it

  • Records live in a structured, typed registry, and studies build on it instead of starting from an empty file.
  • Values arrive by all four routes, and each keeps its own, with its justification.
  • A value proposed by a model must quote the exact sentence from the source document, or it is discarded; a human confirms it before it becomes final.
  • Reasons for absence are explicit and specific to each variable.

Frequent questions

How many variables should be collected?

As few as answer the question posed, plus those the planned adjustment requires. A form of one hundred and twenty variables over a sixty-record cohort mostly produces missingness: each added variable dilutes capture effort across the ones that matter.

Can a variable be added after capture has started?

Technically yes; methodologically it calls for care. Records already processed must be revisited, otherwise the variable is completed for only part of the cohort, introducing a bias tied to entry order. The addition must be dated and logged.

Who should enter the data?

Someone who can read the record — entry is not a mechanical task, it requires interpreting a report. Review, on the other hand, is ideally done by someone other than whoever entered it.

Sources and standards