CRF Builder

The design draft is assembled visually — in the CRF Builder. Here you create forms, sections and fields, configure their properties, and set up value dictionaries (option lists), edit checks and derivations — all on one screen, with no files and no hand-written markup.

0:000:00

CRF Builder: forms, typed fields and form logic — visually, no code.

The entry point is the study’s Design page. If there is no design yet, click New design draft, then Open builder in the draft zone. Next to it are the SoA matrix button (linking forms to visits) and Preview (living the form before publication). A published version is opened from the same page via View design — the builder launches in read-only mode.

The builder’s three panels

The builder screen is split into three zones — left to right, from general to specific:

Panel	What is in it
Left — the list	Two tabs — Forms and Codelists — and a Search by name field. On the “Forms” tab — all draft forms; a click selects the form to work on. On the “Codelists” tab — the value dictionaries.
Center — the form	The open form in two tabs: Structure (sections and fields in display order; each field shows its type — Text · Pick from a list · Date …) and Logic (the form’s checks and derivations).
Right — the property inspector	The properties of the selected element — a form, a section or a field. Everything that defines the element’s behavior is configured here.

In the screen header are the Problems button (with a counter of findings) and the More (⋯) menu, which gathers the rare and advanced items: Export JSON, Import JSON and CRF languages.

Element order is changed with the Move up / Move down arrows or by dragging; a field can also be dragged into a neighboring section. This is how you arrange the form exactly as the coordinator will see it. Next to a field you can see badges: condition — the field has a display condition, auto-filled — the system computes its value, blinded — the value is masked.

Forms, sections and fields

The design tree: version → forms → sections → fields; option lists attach to choice fields separately.

On the Forms tab, click Add form and set a name. The OID (a technical identifier) is assigned by the builder itself — you do not enter it by hand.
On the Structure tab, add sections — the meaningful parts of the form. A section can be marked as a Log (a repeating section) — then during entry it turns into a table of rows (for example, a series of blood-pressure measurements).
Inside the sections, add fields, choose a question type, and configure each one in the inspector on the right.

A form, a section, a field and an option list can be duplicated — via the ⋯ menu next to the element: the copy keeps the properties, and the builder assigns it new OIDs.

Quick entry: the composer and clipboard paste

Add field opens an inline composer row right inside the section: type a name and press Enter — the field is created and the row waits for the next one. The type is a trailing command, a unit goes in parentheses, choice options after a colon:

Weight /number (kg)
Date of birth
Smokes /yesno
Sex /choice: Male, Female

“Sex” gets its option list right away. ⌥Enter creates the field and opens its properties, Esc closes the composer. Formulas and format tweaks stay in the full dialog — linked under the composer.

Clipboard paste: copy a list of questions from the protocol or Excel and paste it into the composer — each line becomes a field by the same grammar (with a confirmation of what exactly will be created).

Templates

The ⋯ menu of the centre panel (and the empty draft) offer “From template…” — a gallery of ready-made blocks: Demography, Vital signs, Adverse event (with its own dictionaries), standard lists. Inserting twice is fine — data names get a suffix and references are rewritten. Your own form or list can be saved as a template from its ⋯ menu — a form travels together with the option lists it uses and becomes available across the organisation.

Undo instead of warnings

Deleting a field, section, form or list asks for no confirmation — a “Deleted · Undo” toast and ⌘Z bring it back with all properties, rules and its former position.

The form itself can also be marked as repeating (several instances per visit, or a shared log) — this is how log forms for adverse events and concomitant therapy are made (see Schedule of Activities).

The field’s property inspector

For a field, the inspector configures:

Property	What it sets
Name	The field label, as the coordinator will see it.
Section	Which section of the form the field is in; switching moves the field into another section (dragging does the same).
Option list	For the “Pick from a list” type — which dictionary the value is chosen from.
Required	An empty field will count as an open item — the system itself creates a “field must not be empty” check.
Unit	Units of measurement — shown next to the field.
Min / Max value	Bounds of allowed values — the system itself creates a range check.
Range violation	Soft (record the value and raise a query) or hard (reject the value) — for a number with a defined range.
Max length	For text — a length limit.
Display condition	An expression over other fields of the form: true — the field is visible (see Skip logic & derivations).

Monitoring and blinding — Subject to SDV, Requires medical coding and Blinded (value is masked) — are gathered in the collapsed “Advanced” block. The collapsed “Technical details” block holds the OID and the full Data type (Text · Integer · Number · Yes/No · Date · Partial date · Date & time · Pick from a list) — the type is usually set by the “Question type” at field creation.

If the field takes part in checks or derivations, the inspector shows a “Rules of this field” block with the related rules; clicking a derivation opens its editor.

If the field is chosen as a derivation target, the inspector marks it as “auto-filled”: the value is computed automatically from the expression, manual entry is closed, and the data type cannot be changed. The formulas themselves are set in the Auto-filled fields block of the Logic tab (see Skip logic & derivations).

Option lists

The Codelists tab holds the value dictionaries for “Pick from a list” fields: a list of “code → label” pairs (for example, M → Male, F → Female). An option list is created once and attached to any number of fields. Codes within a list must not repeat — the builder watches for this. A ready list can be duplicated via the ⋯ menu.

Form logic: checks and derivations

The second tab of the center panel is Logic. It holds the behavior rules of the form that is open: a rule belongs to the form and is versioned together with the design — an edit after publication creates a new version. The logic is split into three blocks:

Edit checks — the data-quality rules (block and query) that fire during entry. The Add check button; a ready rule can be changed (by clicking it) or deleted. In detail — in Edit checks.
Auto-filled fields — computed fields: the system fills them in itself from other fields. The Add derivation button; a rule is likewise edited in place. In detail — in Skip logic & derivations.
From field properties — the checks the core creates itself from Required and the range bounds. A read-only block: these checks are not edited here but changed through the field properties.

The expression editor validates the formula on the fly: right under the input you see “Expression is valid” or the specific error, plus which fields the expression depends on.

The Problems panel

The Problems button in the header carries a counter of findings (errors in red) and opens a live “Design problems” report — the builder continuously reviews the draft and highlights open items, broken down into “Errors · Warnings · Info”:

the version has no forms, or no visits at all;
an empty form — it has no fields;
a form not linked to any visit (outside the SoA);
a “Pick from a list” field without an option list;
a minimum greater than a maximum;
a visit without forms, an option list without items, an option list not used by any field.

Each item leads to the place of the problem: a finding inside the design (a form, a field, a list) opens the relevant element in the builder, while a finding about visits and the schedule (a form outside the SoA, a visit without forms) leads to the SoA matrix — that is where it is fixed. It is best to resolve them as you build: the same checks are built into submitting the version for review — a “broken” design will not get past the draft.

Form preview: live it before publication

The Preview button on the Design page opens the form exactly as the coordinator will see it — and lets you live it before publication: enter values and watch how the form reacts.

Skip logic works (fields appear and hide by conditions), so do derivations (computed fields recalculate instantly) and checks — the ones that fire are listed under the form.
Format errors are highlighted just as during real entry.
All of this runs dry: the preview saves nothing, opens no queries and writes nothing to the audit trail.
A banner above the form reminds you: “This is a preview — nothing is saved.” What you entered can be reset with one button to start over.
A Log (a repeating section) is shown as a single row (during real entry there will be several).

CRF languages: single-language design by default

Multilingual CRF is needed by a minority of studies, so by default there is none: a new draft version’s list of languages is empty, and an element’s name is the very text a site will see. There is no separate Translations link in the header either — it would only hint that “there is still work to do here”.

Multilingualism is turned on by choice: the More (⋯) menu → CRF languages — tick the languages the CRF is authored in, and save. After that a Translations screen appears in the design navigation, and publishing the version starts requiring an approved translation of every ticked language (see Publishing & launch).

Command palette ⌘K

⌘K (or Ctrl+K) opens the command palette: add a form, section or field, insert a template, open Problems, the annotated CRF or the JSON export — without leaving the keyboard. Start typing the name of a field, form or option list and the palette finds it anywhere in the version and opens it selected.

Review comments

At the bottom of the inspector lives the Review comments thread: a reviewer leaves a comment on the selected element (or on the version as a whole) without editing the design — commenting works in read-only mode too, on a draft and on a version submitted for review. The author responds with edits and marks the comment resolved; resolved comments turn grey and stay as the review history. Unresolved comments show up as a counter on the Design page and add a warning next to the approve button — a warning, not a blocker: the decision stays with the approver.

JSON import and export

The Export JSON and Import JSON buttons (the More — ⋯ menu) remain for transferring a design between systems and studies: export the assembled design as a file, import a ready one — and keep refining it visually. The primary way to build is the builder; JSON is the way to move a design as a whole.

What’s next

Skip logic & derivationsDisplay conditions, computed fields and the expression language.

Edit checksSystem and cross-field checks — the Edit checks block of the Logic tab.

Schedule of Activities (SoA)The SoA matrix: visits, windows and form links.

Publishing & launchReview, publication, UAT and go-live.

Legal informationPersonal data processing policy