Enter data in a form

A CRF form is built from sections and fields per the study design. Entry is designed to be fast and keyboard-driven, and to make data impossible to lose. Every save goes to the audit trail.

Who and when

Coordinator — the site coordinator. You need the permission for initial value entry (data.enter); the “not done” / “unavailable” marks need data.mark_not_done; marking the form complete needs form.mark_complete. If the form has an entry restriction, you also need form.entry.<label>. The task comes up after the participant’s visit, once the source documents are at hand.

Before you start

• The visit exists in the casebook and its date is recorded — see Open a visit and a form in the casebook.
• The form is not under a lock.
• The site’s source documents are at hand. Do not enter the participant’s name or other direct identifiers — neither in fields nor in comments.

Steps

1. Open the form from the casebook.

2. Enter the values. Ctrl+S saves, Enter moves to the next unfilled field. With the first value the form moves from Not started to In progress.

3. If there is no value for an objective reason, do not leave the field empty: in the field menu choose Mark as not done / unavailable… and give a reason.

4. If a check (block) rejects the save, correct the value — the rule’s message explains what is wrong. If the value was saved but an automatic query opened, the value is questionable; see Answer a query.

5. When all needed fields are filled in, click Mark complete — the form gets the Complete status and can be signed. If required fields are still empty, the system lists them and offers either to go to the field or to Complete anyway.

0:000:00

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

Editing a saved value requires a reason

Changing an already saved value opens the “Reason for Change” dialog. It is a separate step with its own consequences — see Correct a saved value. Initial entry needs no reason.

Enter a series of rows from a spreadsheet

Pasting tabular data is handy for repeating rows (for example, a series of measurements): copy a range from Excel or another spreadsheet and paste it into a table section — the rows fill downwards. After pasting, the system reports how many cells were saved. If a cell requires a reason for change, fix it by hand. Ctrl+D copies the value from the row above.

Enter a partial date

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.

What happens

• Every save is written to the audit trail: “before → after”, author, time (UTC).
• The field gets the Entered status; a deliberate gap — Not done or Unavailable with a reason.
• A query check does not block the save: the questionable value is saved and an automatic query opens on the field.
• Auto-filled fields are recalculated as soon as their source values are entered.
• Mark complete moves the form to Complete — it enters the investigator’s signature queue.

If it doesn’t work

• The save is rejected, the field is highlighted — a blocking check (block) fired: the value is impossible (a future date, out of range). Nothing was saved — correct the value.
• “The form is locked — data changes are not possible” — a lock covers the form. The data manager can release it.
• The “Reason for Change” dialog opened — you are editing an already saved value; choose a reason. Without it the save is impossible (the server answers 422).
• The “Version conflict” dialog opened — someone else changed the value while you were editing. The dialog shows “You entered”, “Now in the database”, the author and the time. Take the database value or overwrite it with yours (overwriting requires a reason for change).
• “You are offline — changes were not sent” — the value was not recorded. Wait for “Connection restored” and save again.
• The field does not accept input and is marked “auto-filled” — the system calculates the value; edit the source fields.
• “Hidden by a condition but holds a value” — the field became hidden after the controlling answer changed. Click Clear (with a reason) or restore the controlling answer.
• The form is marked “View only” in the casebook — the form has an entry restriction and you lack form.entry.<label>.
• “Hidden” and a lock instead of the value — the field is blinded and you lack the permission to see unblinded data (see More detail).

Next

Correct a saved valueEditing with a reason for change and its effect on SDV and signatures.

Answer a queryWhat to do with automatic and manual queries on your data.

Sign dataSigning a form, coverage, and auto-invalidation when data changes.

More detail

Field statuses

Mark	Meaning
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 empty values

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

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

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

Edit checks

On save, the check rules built into the design fire:

• block — the value is impossible (a future date, out of range): the save is blocked, the field is highlighted and the rule’s message is shown;
• query — the value is questionable: it is saved, but the system automatically opens a query on the field.

Questionable does not mean 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. From the person entering data it looks like this:

1. Checks before writing. Writing into a locked area is impossible; editing an already saved value first asks for a reason for change. A blocking check (block) rejects an impossible value entirely — nothing is saved.
2. Writing the value and resetting derived axes. SDV returns to pending, medical review to Not reviewed, the form to In progress; covering signatures are invalidated, calculated fields are recalculated.
3. An auto-query for a questionable value. A query check does not block the save: a possible but questionable value is saved and accompanied by an automatic query on the field.
4. Writing to the audit trail. “Before → after”, author, time (UTC) and, for an edit, the reason.

The full ten-step chain, including the internal steps the person entering data does not see, is covered in Audit trail; a summary of the status axes and their mutual reactions is in the Status reference.

Keyboard entry

The form is designed for fast mouse-free entry:

Shortcut	Action
Ctrl+S	Save
Enter	Go to the next unfilled field
Ctrl+D	Copy the value from the row above (fill-down)
Alt+Enter or Shift+F10	Open the field menu
Paste from a spreadsheet	Clipboard data (TSV) fills the rows downwards

Time and UTC

Date-times are stored and displayed canonically in UTC — “as the server stores them”. In your profile you can set a display time zone: timestamps are shown in it, but in the database and the audit trail they remain 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 appear only when relevant (for example, “If yes — specify” is visible only after answering “Yes”). A hidden field does not count as unfilled and does not prevent completing the form. If a field becomes hidden while it already holds a value, the system does not delete it: you 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 calculated by the system from other fields — for example, BMI from height and weight. The value appears instantly as the source values are entered; manual entry into such a field is closed. Editing the sources recalculates the result — with an SDV reset and invalidation of signatures covering the recalculated value, as with any data edit.

How this is configured in the design — see Skip logic and auto-fill.

Blinded fields

If a field is blinded, its value is masked by the server, not by the interface: anyone without the permission to see unblinded data (data.unblinded.read) sees “Hidden” and a lock icon. The value reaches neither the interface nor an export without that permission, and there is no “show” gesture. A holder of the permission sees the value directly; such a read is written to the audit trail.

When you enter a blinded value, the system asks you to repeat it (“Confirm blinded entry”): after saving it is masked and cannot be checked by ordinary reading.

Connection loss

If the connection to the server drops, the interface says so immediately — with the “Connection lost — data is not being sent” notice, anywhere in the application; when the connection returns, “Connection restored” appears. If a particular save did not reach the server, you see “You are offline — changes were not sent”: the value was not recorded. This way a loss never goes unnoticed.

Accessibility

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