Skip to content
← All explorers

Visit Lifecycle Explorer

The window state that decides whether a visit accepts data — recalculated on every read, blocking in one direction only. Plus why the stored status is not the one that moves.

Run a visit →
Driven by real source: server/src/modules/study/subjects/domain/visit-instance.ts (computeVisitWindowStatus)

A visit has two different things called "status", and only one of them moves. The one below is the window state: it is worked out from the calendar every time the visit is read, and it is the only visit state that decides whether data may be entered. A participant's visits are made from the study's schedule when they are enrolled, and a visit added to the schedule later still appears.

·······
Not yet openEntry blocked

Today is before the visit's window opens: earlier than the scheduled date minus the days the protocol allows before it. Data entry is refused, and this is the only point in a visit's life where it is. A person who holds visit.write can lift it for this one visit by granting early access with a written reason, which is attributed, time-stamped and audited.

Moves to
In windowEntry allowed

Today falls inside the protocol window: the scheduled date, give or take the days allowed before and after it. Normal data entry. Unscheduled and early-termination visits are created here and are always enterable, because they have no schedule entry to take a window from.

Moves to
MissedEntry still allowed

The window has passed. This is a display flag and never a write gate: a late visit must still be recordable, so entry stays open. The window state moves only with the calendar, so nothing moves it back.

Terminal — no transitions out.

stored: scheduledSet at creation

What every visit made from the protocol schedule is stored as. It stays this value for the life of the visit.

Terminal — no transitions out.

stored: in_windowSet at creation

What an unscheduled or early-termination visit is stored as, because it is added at the moment it happens. It never changes afterwards. Do not confuse it with the live In window state above, which is recomputed on every read.

Terminal — no transitions out.

stored: completedNever set

Allowed by the database and written by nothing: there is no action that completes a visit. How far a visit has got is read from the records captured against it.

Terminal — no transitions out.

stored: missedNever set

Allowed by the database and written by nothing. "Missed" as a live fact is the window state above, derived from the calendar.

Terminal — no transitions out.

stored: out_of_windowNever set

Allowed by the database and written by nothing. A visit recorded outside its window is visible through the derived window state and the dates on the record; it is not stamped here.

Terminal — no transitions out.