Schedule and dynamic collection

Review status

Included in the proposed model: Period/Cycle Definition, Visit/Event Definition, Schedule Rule, CRF Placement, Repeat Policy, Condition, Derivation, Edit Check, and their evaluation evidence.

Open: adaptive schedules, cross-casebook rules, and post-opening window recalculation policy.

Clinical purpose

The schedule tells a site what collection is expected for a subject and when. It must support fixed visits, treatment cycles, unscheduled events, conditional follow-up, repeating logs, and data-driven forms without confusing display order with clinical timing.

Definition records

Period or Cycle Definition

• name and clinical purpose;
• display order;
• single or repeating;
• maximum or unbounded-with-justification occurrence policy;
• occurrence label pattern, such as Cycle 1, Cycle 2;
• included visits/events; and
• condition for opening another occurrence.

Visit or Data-Collection Event Definition

Field	Meaning
Name and label	Protocol-recognizable occurrence
Kind	Scheduled visit, unscheduled visit, phone contact, follow-up, diary period, or other named kind
Repeatability	Single, repeating within cycle, or freely unscheduled
Schedule rule	Anchor, offset, early/late tolerance, and recalculation policy
Opening policy	Automatically expected, manually added, or opened when a condition becomes true
CRF placements	Forms expected at this event
Completion policy	What must be submitted, marked not done, or otherwise accounted for
Visit method	On-site, remote, telephone, home, or protocol-defined alternatives

Five independent visit/event decisions

These aspects must be authored and evaluated separately:

Decision	Question answered	Example
Display order	Where does it appear to the user?	Week 4 appears after Week 2
Applicability	Is it expected for this subject?	Pregnancy follow-up applies only after a reportable pregnancy
Schedule	When is it planned and what is its window?	Day 28, −3/+5 days from Baseline actual date
Availability/opening	When may the site begin it?	Available seven days before target, or manually added as unscheduled
Completion	What must be accounted for before it is complete?	Required CRFs submitted or explicitly marked not done

A visit can be applicable but not yet available, available but outside its window, or complete while some cleaning work remains. Changing one axis does not silently change another.

Schedule Rule

anchor
+ planned offset
− early tolerance
+ late tolerance
unresolved-anchor policy
recalculation/fixation policy

Supported anchors should initially be limited to:

• screening or enrollment date;
• another visit occurrence’s planned or actual date;
• an exact date datapoint; and
• a declared subject milestone received through an approved contract.

A missing or partial anchor produces an unresolved schedule. It never invents a complete date.

Definition is not occurrence

Design definition	Subject occurrence
Week 4 Visit	Subject 104’s Week 4 Visit
Adverse Event CRF	The third AE CRF occurrence for Subject 104
Concomitant Medication row design	The fifth medication row entered for Subject 104
Cycle definition	Cycle 7 for Subject 104

Every repeated occurrence has a stable sequence identity. Deleting an earlier occurrence does not renumber later clinical records.

Subject visit/event fields

• subject and casebook;
• definition and design version;
• period/cycle occurrence;
• event occurrence number;
• target date and window;
• source values used to calculate the window;
• actual start/date and visit method;
• applicability: undetermined, applicable, or not applicable, with rule/evidence;
• availability: not available, available, opened, or closed to new entry;
• conduct: not started, in progress, performed, or did not occur, with reason;
• completion: incomplete, complete, or reopened, with completion evidence;
• timing: unresolved, before window, within window, after window, or unscheduled;
• opening actor/rule and time;
• completion evidence; and
• correction history for each independent decision.

Independent subject-visit movements

There is no single visit status journey. Each aspect moves independently:

Applicability: Undetermined → Applicable / Not applicable
               Applicable ↔ Not applicable after governed reassessment

Availability: Not available → Available → Opened → Closed to new entry
              Closed to new entry → Available, only through authorized reopen

Conduct: Not started → In progress → Performed
         Not started / In progress → Did not occur, with reason
         Performed / Did not occur → In progress, only through authorized correction

Completion: Incomplete → Complete
            Complete → Reopened, with reason → Complete

Timing: Unresolved → Before window / Within window / After window
        Scheduled or unscheduled timing is recalculated when an allowed anchor changes

An applicable event may remain unavailable. A performed event may be outside its planned window. A did-not-occur event can be complete once its reason and permitted follow-up forms are accounted for. Completion does not mean clean, reviewed, signed, or locked.

CRF occurrence journey

Not started → In progress → Submitted
                              ↘ Reopened / In edit → Submitted

Not started or In progress → Intentionally left blank

Submission is an explicit site action. A form with no unresolved required entry may still remain in progress until the site submits it.

Conditions

A condition contains:

• clinical intent;
• evaluation scope;
• exact inputs and occurrence selectors;
• true/false/unknown result;
• effect;
• effective design version; and
• test examples.

Supported effects should be named explicitly:

• make an item visible;
• make an item required;
• make a CRF applicable;
• open a visit/event;
• add a repeating period, event, form, or row;
• request that a dynamic occurrence is no longer expected;
• change a review requirement; or
• publish a Potential Protocol Deviation for assessment by the owning deviation-management process.

Unknown is not false. If a necessary input is missing, the condition records that it could not yet be determined.

Derivations

A derivation records output Item Placement, formula, inputs, occurrence selection, units, rounding, rule version, evaluation trigger, and manual-override policy. Each derived value records the exact input revisions and rule version that produced it.

For repeating data, a rule must say current row, first, latest, any, all, count, sum, minimum, maximum, or another supported selector. “Use the adverse-event severity” is invalid when several adverse events may exist.

Repeating collection

Structure	Example	Occurrence rule
Period/cycle	Treatment cycles	Stable cycle number; may contain several events
Event	Unscheduled visit	Stable event sequence
CRF	Multiple procedures in one visit	Stable form sequence
Item group	Adverse-event or medication log	Stable row sequence

A new occurrence is created only through an allowed action. Maximum counts apply to new occurrences; lowering a maximum does not delete or renumber existing ones.

An unused blank occurrence may be removed when policy allows. Once data, missing assertions, queries, review, signature, or audit-relevant work exists, the occurrence is retained and marked not done, no longer expected, or inactive with reason.

Actions

• Open an expected visit/event.
• Add an allowed unscheduled event.
• Add the next cycle occurrence.
• Add a repeating CRF or item-group row.
• Record or correct an actual event date.
• Mark an event did not occur and provide its reason.
• Reopen a completed or not-done event with authority and reason.
• Evaluate schedule, condition, derivation, and edit-check rules.
• Resolve a dynamic-removal conflict.

Business rules

1. Display order, applicability, schedule, availability/opening, and completion are independent.
2. Schedule calculations identify their source revisions.
3. Partial or absent anchors do not produce fabricated dates.
4. Correcting an unfixed anchor recalculates dependent windows and records the change.
5. Post-opening recalculation follows a declared study policy.
6. A dynamic rule never silently deletes nonblank clinical records.
7. Condition, derivation, validation, and schedule rules may share calculation machinery but retain different clinical meanings.
8. Sequence identities are stable and are not reused.
9. A visit marked did not occur may still contain explicitly permitted contact or safety forms only when the design says so.
10. Changing applicability after data entry creates a visible conflict or inactivation decision.
11. EDC supplies the observation, rule, subject/event context, and audit history for a Potential Protocol Deviation; it does not decide classification, significance, reportability, or final disposition.

Audit evidence

For every schedule or dynamic decision retain:

• rule and design version;
• exact input revisions;
• evaluation time and trigger;
• result, including unknown;
• occurrence created, changed, or proposed for removal;
• actor when a human overrode the calculated result;
• reason and authority; and
• later reconciliation caused by input correction or amendment.

Important exceptions

• Baseline actual date is corrected after Week 4 was completed.
• A subject begins another treatment cycle after the configured expected maximum.
• A pregnancy follow-up form becomes applicable after the parent visit was submitted.
• A controlling answer becomes “No” after dependent data were entered.
• An event is marked did not occur, but a serious adverse event was reported during telephone contact.
• A rule attempts to remove a signed dynamic form.
• Two repeating rows make a single-value derivation ambiguous.
• An unknown day in a partial date prevents an exact visit-window calculation.