Open a visit and a form in the casebook

A subject’s casebook is the participant’s main screen: the subject’s visits and the CRF forms in each of them, per the study’s schedule of activities (SoA). From here you reach any form and see at a glance what is filled in and what is still waiting.

Who and when

Coordinator — the site coordinator. To see the casebook you need the permission to see subjects (subject.read) at the site; to record a visit date or mark a visit as not done — visit.update; to create an unscheduled visit — visit.create; to add a record of a repeating form — form.instance.create. The task comes up every time the participant attends a visit or you need to enter data from source documents.

Before you start

• The subject exists — see Enrol a subject. Scheduled visits appear automatically from the schedule as soon as the subject reaches an active status.
• You hold a role at the subject’s site.

Steps

1. Open the study → Subjects and pick the subject (or follow the “Open casebook →” link right after creating it). The Casebook tab opens.

2. Look at the whole casebook (“All visits”): columns are visits in chronological order, rows are forms. Under each visit heading is its phase in words: “Done …”, “Expected …”, “Overdue · …”, “Did not occur” or “Date not recorded”.

3. Click a visit heading — the visit opens: its forms, date and actions. The ‹ › arrows move to the previous or next visit; All visits returns to the overview.

4. If the visit date is not recorded yet, click Record visit date. The date comes first: protocol windows are judged against it.

5. Click a form (a cell or a row of the visit) — the form page opens. Continue with Enter data in a form.

The casebook tells you what's next

The next unfilled form in schedule order is highlighted (“Next form to complete”), and the main Continue entry button in the header goes straight to it — with the hint “Next: form · visit”.

0:000:00

A subject's casebook: visits and forms, adding an unscheduled visit

Add an unscheduled visit

Not everything happens on schedule: an unplanned visit, a repeat sample, a safety visit. “Unscheduled” does not mean “outside the structure” — the forms allowed for it are declared in the design in advance.

1. In the casebook header click Add visit. The “New visit” dialog opens.

2. Choose the Visit definition (an unscheduled or common event) and enter the Visit date.

3. Click Create visit. The visit is placed in the casebook by its actual date.

Add a record of a repeating (log) form

Some forms repeat by nature: adverse events (AE), concomitant medications (ConMeds). A single visit may hold several instances of them.

1. Click the log form’s cell — it shows a counter, for example “3 records”. The cell expands the list of records.

2. Click + Add record — another instance of this form is created in the visit.

Each instance is a separate record with its own status, queries and history.

Mark a visit as not done

If the participant did not come, open the undated visit and click Visit not done. A reason is mandatory and goes to the audit trail. The mark is reversible: recording a date later moves the visit back to occurred (also with a reason).

Build the subject documents

Open the More actions (⋯) menu → Subject documents. The server builds the Casebook (PDF) or the Audit log (PDF) — for the site archive or for handing over materials. What the documents contain — in More detail.

What happens

• A form instance is created “lazily” — when it is first opened. As soon as you enter the first value, the form moves Not started → In progress by itself.
• Recording a visit date, marking “Visit not done”, creating an unscheduled visit and a new log form record are all written to the audit trail.
• A date outside the protocol window is captured as a deviation: the system asks for a reason, and the visit gets an “out of window” mark in the casebook.
• Every subject document build appears in Exports with a SHA-256 checksum, and every download is written to the audit trail.

If it doesn’t work

• No visits (“No visits scheduled yet”) — the subject has not reached an active status yet; scheduled visits are created automatically after enrolment.
• Nothing to choose in the “New visit” dialog — the design has no unscheduled or common events: scheduled visits are created automatically, and only unscheduled and common ones are created by hand. Contact the data manager.
• No “Record visit date” / “Add visit” / “+ Add record” buttons — you lack visit.update, visit.create or form.instance.create respectively.
• The system asks for a reason when recording the date — the date is outside the protocol window, or you are editing an already recorded date (“Edit visit date (reason required)”). Enter a reason.
• A form is marked “View only” — the form has an entry restriction and you lack the entry permission for it (form.entry.<label>).
• A “version outdated” mark in the header — the subject stayed on a superseded design version after an amendment. Moving to the new version is done on the Amendments page (by the data manager).
• No “Subject documents” item — building a document is an export and needs export.run.

Next

Enter data in a formFilling in fields, “not done” marks, keyboard entry.

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

Answer a queryThe subject's queries — on the casebook's Queries tab.

Status lifecyclesAll status axes of forms, subjects and data in one place.

More detail

Subject tabs

The subject header has three tabs:

Tab	What it shows
Casebook	Visits and forms — the data-entry workspace
Queries	All queries of this subject in one list
Audit	The subject’s change history — who changed what, when

Next to the subject number the header shows its status and progress per axis: entry, SDV, signature. The More actions (⋯) menu holds Change status…, Subject documents and other actions, according to your permissions.

What a cell shows

Each cell is a form in a particular visit; a dash means the schedule has no such form in this visit (“This form is not part of this visit”). A cell shows the form’s state word and the number of open queries. Status axes do not merge into one “overall” colour: entry, signature and lock states read as a word, queries as a separate counter.

State in the cell	Meaning
Not started	The form has not been opened yet, there are no values
In progress	At least one value has been entered, filling in continues
Complete	The coordinator has explicitly marked the form as finished
Awaiting signature	Complete and waiting for the investigator’s signature (seen by the PI)
“Signed”	A valid electronic signature covers the form
“Locked”	The form is under a lock — editing values is closed

Form completion statuses

A form (FormInstance) has its own completion status — managed by the coordinator:

1. Not startedfirst value
2. In progressmark complete
3. Complete
   • data editIn progress

The form's completion status; editing after “Complete” automatically returns it to “In progress”.

The Complete mark is set by a person with the Mark complete button — a deliberate step, not automation.

Note

If someone changes the form’s data after it was marked “Complete”, it automatically returns to In progress — the status always honestly reflects the real state of the data.

Visit date and protocol windows

A visit has a protocol window (under the visit heading — “Planned: … (target …)”). Windows are counted from the date of the schedule’s anchor visit: until that date is recorded, visits have no planned windows and nothing counts as overdue — the casebook tells you which visit’s date to record. If the window has closed and no date is recorded, the visit is marked “overdue”.

A date outside the window is captured as a deviation

If the recorded date falls outside the visit window (or you edit an already saved date), the system asks for a reason, and the deviation is captured in the audit trail.

Data entry into the visit’s forms is not blocked while the date is missing (data sometimes comes before the visit is closed), but recording the date is the first thing to do.

Subject documents

More actions (⋯) → Subject documents opens a page where the server builds two documents. A file leaving the system is an export: documents can be built by holders of the export permission (export.run). A sponsor auditor with view-only access does not build documents — they read the data on screen, and the data manager prepares inspection materials as an inspection packet.

• Subject casebook (the Casebook (PDF) button) — visits and forms, questions in their design wording, values in words (decoded codelists, units, statuses), the SDV and medical review status of every field and the electronic signature register: signer, meaning, moment, method and checksum of the covered data. This is PDF/A-3: the machine-readable JSON source is embedded in the same file.
• Subject audit log (the Audit log (PDF) button) — all audit trail entries for the subject in order of occurrence — who did what, when and what changed (“before → after”), with reasons for change. Available to those with the audit trail permission.

The casebook contents are configured before building: the Include the change history checkbox adds every value’s edits (before → after, who with role and organisation, when and why — needs the audit trail permission), the Include queries checkbox adds the field query threads. The Document language is chosen here too; without a choice the document is built in the study’s primary language.

The button queues the build, waits for it and downloads the finished file. Blinded values are hidden in the document. More on server-built documents — in Documents and certified copies.