Build the visit schedule

The Schedule of Activities (SoA) answers one question: which forms are filled in at which visit. It is the protocol plan laid out as a table. The subject’s casebook is later built from the SoA: columns are visits, rows are forms, and at each intersection the coordinator sees what needs to be filled in.

Who and when

Data manager — the study designer (Study Builder) or the data manager with the “edit a design version” permission (studyversion.update). The schedule takes effect after another person approves and publishes the version.

The task comes up while building the design — usually once the forms are built in the builder — and with a protocol amendment that changes the visit schedule.

Before you start

• The design version is a Draft.
• The forms already exist in the CRF builder: the matrix takes its rows from there. If there are no forms, it says “The version has no forms — build them in the builder first.”
• The protocol’s visit schedule is at hand: names, target days and tolerances.

Steps

0:000:00

The SoA matrix: forms as rows, visits as columns — with types and windows.

1. Open the study’s Design section and click SoA matrix in the draft zone.

2. Click Add visit and fill in its properties:

   • Name — how the visit is labelled (Screening, Week 4, End of study);
   • Visit type — scheduled, unscheduled or common (see More details);
   • for a scheduled visit — Planned day, Window from (days) and Window to (days): the target day counted from the baseline visit and the tolerance (“from” is usually negative, e.g. −3).

3. On the baseline visit (usually the baseline or randomization visit), tick Schedule anchor — the planned windows of all other visits are counted from its date. An anchor visit requires a planned day.

4. Arrange the columns in protocol order with the Move visit left / Move visit right arrows.

5. Mark the “form × visit” cells. A click (or Enter) cycles through ● mandatory → ○ as indicated → · not collected; Delete removes the form from the visit, the arrow keys move between cells.

6. If needed, set the order of forms within a visit — Alt+↑/↓ in the cell. The number in a cell is the order in which the form appears in the subject’s casebook.

An existing visit’s properties open with a click on its header; Delete visit is there too.

Mark many cells at once

• The More menu in a visit header: All forms required on this visit, Same as the previous visit, Remove all forms from this visit.
• The More menu in a form row: Form on every visit (required), Remove the form from every visit.

Collect a form repeatedly

For data that accumulates throughout the study (adverse events, concomitant medication), tick Repeating form (multiple instances per visit) in the builder inspector and link the form to a common visit — that gives a common log not tied to a particular visit. More in Log forms.

What happens

• Every change is saved in the draft and written to the audit trail (“Visit created”, “Visit updated” in the design change log).
• The builder’s Problems panel stops showing “The form is not linked to any visit (outside the SoA)” and “A visit with no forms” once the schedule is complete.
• After the version is published, each subject’s casebook is built from the schedule; for scheduled visits the windows are computed from the anchor visit’s date, and visits get statuses such as Planned and Overdue.

If it doesn’t work

• “Visit windows are defined but no visit is the schedule anchor” — no planned window is computed for any subject, and the version won’t pass validation at publication. Tick Schedule anchor in the baseline visit’s properties.
• “An anchor visit requires a planned day” — set a Planned day on the anchor.
• “Window fields must be numbers” — Window from / to take whole days only, with a minus sign for the tolerance before the target day.
• Saving moves the anchor — there is exactly one anchor per version; ticking it on another visit moves it, and the windows of all visits are recalculated from the new one.
• Cells don’t toggle — the version is not a draft or you don’t hold studyversion.update; the matrix is open read-only.

Next

Build forms in the CRF builderThe forms and fields you assign to visits.

Set up edit checksSystem and cross-field checks as part of the design.

Publish a version and launchChecking the schedule and publishing the design.

Enrol a subjectHow the SoA becomes a subject's casebook during data entry.

More details

Don't confuse it with the Subjects screen

The SoA matrix screen is design: the plan of “which forms at which visit”, without a single subject. The Subjects section has a different matrix — a working one, showing completion progress for real subjects against this plan (see Casebook and visits).

The forms × visits grid

Visits run horizontally, forms vertically, and each intersection shows whether the form is collected at the visit: ● — mandatory, ○ — as indicated, empty — not collected. A form marked at several visits is collected at each of them. Like the rest of the design structure, the matrix can be edited only in a draft; when a design is moved between systems it comes along with the design import from a file.

Visit window and anchor

The target day sets when the visit should take place per protocol, and the −/+ window sets how far the actual date may deviate while staying “on schedule”. Values are days counted from the anchor visit. A window is usually written compactly, e.g. Day 28 (−3/+3). There is exactly one anchor per version — usually the baseline visit or randomization; without it the server cannot compute any planned window.

Unscheduled and common visits

• An unscheduled visit is declared in the design in advance: you set which forms are allowed on it, but it has no window. “Unscheduled” doesn’t mean “outside the structure” — its date just isn’t fixed. During entry the coordinator creates an instance of such a visit as it happens (with a date), and it is placed in the casebook in chronological order with a ⚑ mark and a number (UNS-1, UNS-2 within the subject).
• A common visit is a container outside the schedule: no target day, no date. It exists for the subject throughout the study and is the home for forms collected “as life happens” rather than at a specific visit — above all for repeating log forms. In the casebook it is shown as a separate common-log column.

This way you decide in advance what may be collected off-schedule, and the coordinator on site only records what actually happened and when.

Log forms (repeating)

• A form is marked as repeating in the property inspector of the CRF builder.
• Such a form can be created several times: as several instances at a visit, or as a common log not tied to a particular visit (for that it is linked to the common visit).
• In the casebook a repeating form collapses with an instance counter (for example, ●(3)), and the common log is shown as a separate column.

A section inside a form can repeat too — it then becomes a log and is shown as a table: columns are fields, rows are records. This is handy for tabular entry (several blood-pressure readings, a list of medications).

A log form ≠ a regular form at every visit

A regular form is assigned to specific visits in the SoA matrix. A log form is about filling in the same form many times; most often it is collected as events happen rather than on a schedule.