Research
Preparing registry data entry
Read the form before adapting, define T0, prepare values without ever imputing, check non-objection, and bring follow-ups due to the surface: a registry kept up to date without the AI touching the data-entry site.
The problem
A multicentre registry asks you to enter, for each included patient, values at specific visits, in an online form whose version changes. The data exist in the records and in the database, but not in the right units or at the right windows, and follow-ups due get forgotten from one round to the next.
Step-by-step method
- Read the case report form (CRF) definition first: each variable is tied to the page that defines it, which is cited. If the online version differs from the one that was read, flag it before adapting anything.
- Define T0 (inclusion, diagnosis or first exam, depending on the registry) and assign each exam to a window of the form; an exam outside a window is flagged, never forced into the neighbouring window.
- Prepare the values to enter: units converted to those of the CRF, values mapped to the CRF categories, “na” when the data item is missing. Never any imputation. Bounds and unit pitfalls are listed once and for all, with a reusable blank template.
- The registry site stays read-only: data are entered by an authorised person, and the registry’s exports are never opened in the AI tool.
- Check that the patient was informed and did not object before any entry: a log (date, form, who collected it), cross-checked by script against the list of included patients to spot gaps.
- A follow-up listing cross-checked with the database: reported as aggregates (consents to collect, questionnaires to have completed, follow-ups due or done) and, for the team, by pseudonymised identifier with the expected action.
- Follow-up attendances are not protocol visits: a real-world consultation is linked to a registry visit only by explicit decision. Nor is the meaning of a listing you receive assumed (included, to include, withdrawn): ask.
- Deadlines come up: each follow-up due feeds the studies table and the dashboard, with its backward-planned date (see Managing your studies and cohorts).
Deliverable
A data-entry template per visit, a mapping table to the CRF pages, a non-objection log, a follow-up listing with the expected actions, and deadlines visible in the studies table.
Safeguards
The registry has its own framework (protocol, patient information, agreements between sites): it applies before any preparation. Claude works from the pseudonymised database and the CRF, never on the registry site or its exports. No value is invented or imputed; a missing data item stays “na”.
Starter prompt
Here is the registry’s form definition (pages attached, with their version number) and the list of variables in our database (names only). Map each variable, citing the CRF page, with unit conversions, categories, visit windows around T0, and a blank template. Flag any variable with no equivalent; do not impute anything.