What this is, and who it is for
The visit schedule is the protocol's list of visits: when each falls, relative to the participant's baseline, and how early or late it may be held. It is part of the design that is frozen when the version goes to UAT. From the schedule the system builds each participant's own visits when they are enrolled. This page covers defining the schedule; which forms each visit collects is the visit–form mapping.
| You need | To |
|---|---|
form.design or study.write | add, edit, reorder and remove visits, in a version in Build |
form.read or study.read | read the schedule |
Held by: Organization Admin, Project Manager, eCRF Designer (form.design or study.write).
Where to find it
Study → Build → Visit Schedule. The page lists the visits (code, name, type, day, window, required or optional), a Schedule and Timeline view of them and a Form sequence panel; Open Form Mapping → goes to the matrix.
What you can do
- Add visit (Define a protocol visit. It will be auto-scheduled for every existing subject based on their baseline date.).
- Edit a visit, Remove it (Removes the visit definition and any form mappings on it. Existing per-subject visit instances are preserved.), and move it up or down.
- Order the forms of a visit: Set the order in which forms appear to data-entry staff for each visit. Use the arrows to reorder. Changes take effect immediately.
- Read the Visit timeline to see the visits spaced by day.
Every option
A visit
| Field | Meaning |
|---|---|
| Code | Capitals, unique in the study (V01, V02…). Required |
| Name | What people read (Baseline / Day 1) |
| Type | Schedule: Screening, Baseline, Treatment, Follow-up, End of Study. Event-driven: Early Termination, Unscheduled. Stored as screening, baseline, treatment, follow_up, end_of_study, early_termination and unscheduled |
| Day offset | Days from baseline when the visit is due (negative before baseline). For a scheduled type |
| Window − / Window + | Days early and days late that are still in window. Both start at 3 |
| Description | Optional notes |
| Required visit | On by default. If on, subjects who miss this visit are flagged as deviations |
| Available during screening | Off unless the type is Screening. If on, this visit appears in a subject's casebook from screening (before enrolment). If off, it unlocks only on enrolment |
| Can be held remotely | Off by default. When on, a subject's visit can be recorded as held by phone, video or a home visit, and the forms that need the person in the room are marked in the mapping |
Event-driven visits are not part of the schedule backbone: they are captured when the event occurs, and the scheduling fields do not apply. A study may have at most one Unscheduled visit and one Early Termination visit; each is the system anchor that a participant's Add unscheduled visit and early-termination actions are made from, so it should not be removed (the list marks it System anchor — required for ad hoc visit creation, do not archive).
- Adds the visit to the schedule.
How a visit is timed for a participant
When a participant is enrolled, each scheduled visit is dated baseline + day offset, with a window of the days before and after. The participant's visit is then:
| Window state | Meaning | Data entry |
|---|---|---|
| Not yet open | Before the window | Blocked unless an early-access exception with a reason is recorded |
| In window | Inside the window | Allowed |
| Missed | After the window | Allowed (a late visit must still be recordable) |
See Run a visit and Statuses. Visits that are Available during screening appear before enrollment; the others unlock when the participant is enrolled.
What the system records
Each change is a revision of the version's draft design (study_visit.changed), attributed and dated. The schedule is part of the snapshot frozen at submission.
What you cannot do, and why
- Change a visit after the version leaves Build. Frozen with the design; an amendment is a new version.
- Remove a visit and lose participants' visits. Removing a visit leaves existing per-participant visits in place.
- Have two Unscheduled or two Early Termination visits.
- Leave a visit with no form, or a form with no visit. The version's build check refuses (Build a study).
- Move baseline. Baseline is the participant's own date, recorded at enrollment.
Compliance Q&A
Yes. The schedule, windows and required flags are part of the design snapshot tested and signed off before any participant is enrolled, and a participant's visits are dated from it when they are enrolled.
Limits: the schedule encodes the protocol as the study team entered it; checking that it matches the protocol is part of UAT.
Evidence: server/src/modules/study/visitsversions snapshotsubjects visit instances
Related
Binding a form to visits · Build a study · Run a visit · Enroll a participant · Statuses