What this is, and who it is for
A participant's visits are made from the study's schedule when they are enrolled, each with a due date and a window. Running a visit is finding the participant's visit, seeing which forms it expects, saying how it was held, and entering the forms (Enter visit data). It also covers the two visits the schedule does not predict: an unscheduled visit, and entering data before a visit's window has opened.
| You need | To |
|---|---|
visit.write and subject.write (site coordinator, principal investigator) | Enter data, say how a visit was held, add an unscheduled visit, grant early access |
visit.read | See the visits |
Held by: Principal Investigator, Clinical Research Coordinator (visit.write).
Where to find it
A participant's page → Visits & forms (the visit rail and the casebook). The Activity tab shows what happened and, under Every recorded change, each change with who, when and why. The rail on a form's page has two lists: Visits (scheduled and unscheduled) and Forms (the forms of the chosen visit), with Required marked on forms the visit expects and IN PERSON on forms that need the person in the room.
What you can do
Find the visit and its forms
Each visit shows its status by its window state (Statuses):
| Window state | Entry |
|---|---|
| Not yet open | Blocked until the window opens, unless early access is granted |
| In window | Allowed |
| Missed | Allowed: a late visit must still be recordable |
The forms listed are those the design binds to the visit (Binding a form to visits); the casebook shows each as empty, in progress, complete or locked. Choose Open on a form to enter it.
Say how the visit was held
For a visit the design allows to be held remotely, the participant's page offers How the visit was held (Plan visits): On site, with the person in the room, or Remotely with a channel (Phone, Video, Home visit), and Why it is being recorded this way (recorded in the audit trail). A visit is held on site unless it is said to have been held remotely. A form that needs the person in the room takes no record at a visit held remotely. Those forms are marked and stay read-only. A visit cannot be made remote while a form that needs presence already has data (the dialog names the forms).
Enter data before the window opens
If a visit must be recorded before its window (for example, a participant is discharged early), choose Grant early access: This exception is permanently recorded on the visit's audit trail, with your name and the reason below. A Reason is required. Entry is then allowed.
- Opens the dialog that records an exception, with a reason.
- Allows entry for this one visit.
Add an unscheduled visit
Choose Add unscheduled visit (Document an unplanned subject visit. A new serialized visit instance is created, and an event found at it is recorded for each form you select.). Give the Reason for unscheduled contact (for example Subject reported worsening fatigue between V03 and V04; telephone triage with site PI on call) and choose the event forms to record at it (adverse event, medication or other event forms; No event forms are defined in this design if the designer has made none). The visit is numbered after the participant's other unscheduled visits.
Record an event
Event forms (adverse events, medications) are not on the schedule: Record event here on a visit, or from the participant's Events page (Record an adverse event).
Every option
How the schedule becomes visits
On enrollment each scheduled visit is dated: baseline date + day offset, with its window before and after (Plan visits). Visits marked Available during screening exist from screening. A participant who moves to an amended version has their not-yet-held visits replaced by the new version's (Amend a live study). A visit is never closed by being late, and nothing marks a visit "done": how far it has got is read from its forms. If the version asks for visit signatures, the investigator can sign a visit once its expected forms are complete (Sign records).
What the system records
subject.unscheduled_visit (reason, forms), subject.visit_early_access_granted (reason, who), visit.mode_set (on site or remote, channel, reason), and the form saves. See Audit events.
What you cannot do, and why
- Enter a visit before its window without a recorded exception.
- Record a form that needs presence at a remote visit. The database refuses it.
- Make a visit remote that the design does not allow.
- Delete a visit. Visits are retired only when the participant moves to a new version and the visit never took place.
- Add scheduled visits by hand. The schedule is the design's; use an unscheduled visit.
Compliance Q&A
Yes. Entry before a window opens is refused unless a person with the right records an exception with a reason, which is kept on the visit's audit trail; late visits are recordable and are reported as missed.
Evidence: server visit window state computed on readdata-capture gateaudit event subject.visit_early_access_granted
Related
Enter visit data · Plan visits · Use the casebook · Statuses · Clinical Research Coordinator