Entering data in a form

A form (CRF) is assembled from sections and fields per the study design. Entry is arranged to be fast and keyboard-friendly, and to make data impossible to lose or silently overwrite. Every save goes into the audit trail.

0:000:00

Entering a value, a blocking edit check, and a save — written to the audit trail

Filling in and field status

Open the form from the casebook. As soon as you enter the first value, the form moves from Not started to

In progress. Each field also has a completion status:

Mark	What it means
Empty	No value has been entered yet
Entered	A value has been entered
Not done	The procedure or measurement was not performed
Unavailable	The value cannot be obtained (lost or inaccessible)

“Not done” and “Unavailable” are not emptiness

If data is missing for an objective reason, do not leave the field empty — mark it deliberately. In the field menu choose “Mark as not done / unavailable…”:

• Not done — the procedure or measurement was not performed;
• Unavailable — the value cannot be obtained (lost, inaccessible).

Why this matters

A deliberate “Not done” differs from “Empty”: the “field is required” edit check will not raise a query on it. This way the system understands that the omission is intentional, not forgotten. You can return the field to normal entry with the “Return to data entry” item.

The mark requires a reason. If the field already held a value, it will be cleared (but will remain in the audit trail), and covering signatures will be invalidated; the system warns about this in advance.

Edit checks

On save, the edit checks built into the design fire:

• block — the value is impossible by definition (a date in the future, out of range): the save is blocked, the field is highlighted, the rule message is shown;
• query — the value is debatable: it is saved, but the system automatically opens a query on that field.

Debatable is not the same as blocked

A block rule stops only clearly impossible values. Everything else is saved as is and accompanied by an automatic query: data from the source matters more than “instant cleanliness”, and the query leaves a managed trail for resolving the discrepancy.

The order of reactions on save

A single value save triggers a fixed chain of reactions — always in the same order and in one transaction. If any step trips a block, the whole save is rolled back:

1. Rejection on an active lock — writes into a locked area are impossible.

2. Reason for Change (RfC) — only when editing an already-saved value; initial entry needs no reason.

3. Blocking check (block) — an impossible value is rejected entirely, nothing is saved.

4. Value written and derived axes reset — SDV returns to “pending”, medical review to “not reviewed”, the form to “in progress”.

5. Covering signatures invalidated — if the data snapshot was signed.

6. Derivations recomputed and query checks — auto-filled fields update against the new value; a debatable but possible value is saved and accompanied by an auto-query.

7. Audit-trail entry — “before → after”, author, time (UTC) and, for an edit, the reason.

For a full summary of the status axes and their mutual reactions, see the Status reference.

Keyboard entry

The form is designed for fast, mouse-free entry:

Shortcut	Action
Ctrl+S	Save
Enter	Jump to the next unfilled field
Ctrl+D	Fill down the value from the row above (fill-down)
Paste from a table	Data from the clipboard (TSV) fills the rows downwards

Pasting tabular data is handy for repeating rows (for example, a series of measurements): copy a range from a table and paste — the rows fill downwards. After pasting, the system reports how many cells were saved. If a cell requires a reason for change, it has to be corrected by hand.

Partial dates

The full date is not always known. A date field accepts a partial value in the YYYY, YYYY-MM or YYYY-MM-DD formats — as separate “Year”, “Month”, “Day” fields. If the format is wrong, a hint explains the expected form.

Time and UTC

Date-time is stored and displayed canonically in UTC — “as the server stores it”. In your profile you can set a presentation timezone: timestamps are shown in it, but in the database and the audit trail they stay in UTC.

Hidden and auto-filled fields

The design can make a form “live” — some fields appear on conditions, some are filled in by the system:

• Fields with a display condition are shown only when relevant (for example, “If yes — please specify” is visible only when the answer is “Yes”). A hidden field does not count as unfilled and does not prevent completing the form. If a field hid while already holding a value, the system does not delete it: you will see the warning “Hidden by a condition but holds a value” and a “Clear (with a reason)” button — either clear the value, or restore the controlling answer.
• Auto-filled fields (marked “auto-filled”) are computed by the system from other fields — for example, BMI from height and weight. The value appears instantly as the sources are entered; manual entry into such a field is closed. Editing a source recalculates the result — resetting SDV and invalidating signatures that cover the recomputed value, as with any data edit.

How this is configured in the design — in Skip logic & derivations.

Blinded fields

If a field is blinded, its value is masked by the server, not the interface — you see ••• and a lock icon. The value reaches neither the interface nor the export without the corresponding permission. A holder of clearance clicks “Show” — and this fact of unblinded reading is recorded in the audit trail.

Completing the form

When all the required fields are filled in, click “Mark complete” — the form gets the

Complete status and can be signed. If required fields are left empty, the system lists them and offers either to jump to the field or “Complete anyway”.

Editing a saved value requires a reason

Changing an already-saved value opens the “Reason for Change” dialog. This is a separate important step with its own consequences — see Reason for Change. Initial entry does not require a reason.

Version conflict

If, while you were editing a value, someone else changed it, the save will not silently overwrite the other person’s work. A “Version conflict” dialog opens: it shows “You entered”, “Now in the database”, the author and the time. You choose — take the value from the database or overwrite it with yours (overwriting will require a reason for change).

Connection loss

If the connection to the server drops, the interface signals it right away — a notification “Connection lost — data is not being sent”, anywhere in the app; when the connection returns, “Connection restored” appears.

If a particular save did not reach the server because you are offline, you see “You are offline — changes were not sent”: the value was not recorded. That way the loss does not go unnoticed — wait for the connection to come back and save the value again.

Accessibility

The form screen is fully keyboard-navigable (Tab, Enter, the hotkeys above), the fields and actions carry labels for screen readers, and the breadcrumbs always answer the question “where am I”. Changing the interface language changes only the labels — the data and the addresses stay the same.

Reason for Change (RfC)Editing a saved value and its impact on SDV and the signature.

QueriesHow auto and manual data queries work.

Electronic signaturesSigning a form, coverage and auto-invalidation on data change.