Schedule of Activities (SoA)

The Schedule of Activities (SoA) answers the question: which forms are filled in at which visit. It is the protocol plan laid out as a table. The SoA is part of the design version and is assembled on a dedicated builder screen: on the study’s Design page, click SoA matrix. Like the rest of the design structure, the matrix can only be edited in a draft; when a design is moved between systems it travels with the JSON import.

It is from the SoA that the subject’s casebook is later built: columns are visits, rows are forms, and at the intersection the coordinator sees what needs to be filled in.

0:000:00

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

Not to be confused with the Subjects screen

The SoA matrix screen is design: the plan of “which forms at which visit”, with no subjects at all. The Subjects section holds a different matrix — the working one, where entry progress for real subjects is shown against this plan (see Casebook & visits).

The forms × visits grid

The screen is laid out as a table: visits run horizontally, forms vertically, and each intersection holds a checkmark — “this form is collected at this visit”. Linking is a single click on the cell; a form ticked in several visits is collected at each of them.

Visit order is changed with the “Move visit left” / “Move visit right” arrows — this is how you arrange the columns into the protocol’s chronology. Forms appear in the matrix from the CRF Builder: if there are no forms yet, assemble them there first.

The Problems panel sees the schedule too

A form not linked to any visit, and a visit without a single form, are design open items: they are highlighted in the builder’s Problems panel and will not slip past submission for review unnoticed.

Visits and their windows

A visit is not just a column but a design object in its own right. A new visit is created with the Add visit button; an existing one’s properties open by clicking its header. A visit defines:

• Name — how the visit is labeled (Screening, Week 4, Completion).
• Visit type — scheduled, unscheduled or common (see below).
• Window — for a scheduled visit:
  • Planned day — the target day relative to the subject’s reference point (for example, day 28);
  • Window from and Window to — the allowance in days before and after the target (“from” is usually negative, for example −3).
• Order — the visit’s position in the schedule (the same arrows in the grid).

The window is conventionally written compactly, for example Day 28 (−3/+3).

A visit window is a range of allowed dates

The target day sets when the visit should take place per protocol, and the −/+ window sets how far the actual date can deviate while still staying “on schedule”. The values are in days relative to the subject’s reference point.

Unscheduled and common visits

Not everything in a study happens strictly on schedule — that is what the two visit types besides scheduled ones are for.

• An unscheduled visit is declared in the design in advance: you set which forms are allowed on it, and it has no window. “Unscheduled” does not mean “outside the structure” — it simply means its date is not fixed. During data entry the coordinator creates an instance of such a visit as it happens (with a date), and it is woven into the casebook in chronological order with a ⚑ mark and numbering (UNS-1, UNS-2 within the subject).
• A common visit is a container outside the schedule altogether: no target day, no date. It exists for the subject throughout the study and serves as the home for forms collected “as life happens” rather than at a specific visit — above all for repeating log forms (see below). In the casebook it is shown as the shared-log column.

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

Log forms (repeating)

Some data is not tied to a single visit and accumulates throughout the study: adverse events, concomitant therapy. Log forms — repeating forms — are used for these.

• 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 on a visit, or as a shared log not tied to a specific visit (for that, it is linked to a common visit).
• In the casebook a repeating form is collapsed with an instance counter (for example, ●(3)), and a shared log is shown as a separate column.

A section can also repeat inside a form — then it becomes a Log and is displayed as a table: columns are fields, rows are records. This is handy for tabular entry (several blood-pressure measurements, a list of drugs).

A log form ≠ an ordinary form on every visit

An ordinary form is linked to specific visits in the SoA matrix. A log form is about filling in the same form multiple times; most often it is collected as events occur, not on a schedule. Repeatability is set by the form’s flag in the CRF Builder.

What’s next

CRF BuilderThe forms and fields you link to visits.

Edit checksSystem and cross-field checks as part of the design.

Publishing & launchChecking the schedule and publishing the design.

Enrolling subjectsHow the SoA becomes the subject's casebook during data entry.