Chapter 8. Subject Visit Scheduling

If used, the screening cycle must appear at the beginning of the visit map as cycle number 0. It may contain visit types X (screening) and E (early termination) only; no other visit types are allowed. The screening cycle will not have a scheduled start date because nothing precedes it.

Within a screening cycle all screening visits (X) are required, unless they are made optional or excluded by the conditional visit map. Each screening visit can be unscheduled, or scheduled relative to the first screening visit that serves as the baseline for the cycle. The final screening visit serves as the termination of the screening cycle, unless it is made optional or unexpected by the conditional visit map, in which case the last required or completed screening visit is used as the termination visit of the screening cycle.

The screening cycle can be brought to an early conclusion by defining one or more early termination visits (E) within the screening cycle, by designing an early termination plate that can be submitted at the appropriate screening visit, or by defining termination conditions for the screening cycle in the conditional termination map.

Although unusual, it is legal for a visit map to contain nothing but a screening cycle. This might be useful for a trial consisting of an ordered list of subject assessments, where each subject was allowed to complete the assessments at their own pace, with no specified scheduling targets. This could be done using a visit map having nothing but a screening cycle containing a list of unscheduled screening visits.

In-study cycles sit between the screening cycle and end cycle, and are the most important part of the visit map. These are the cycles that contain the visits that record subject treatment and follow-up. A visit map may contain 1 or more in-study cycles, to accommodate different treatment and follow-up requirements for different subjects, or because treatment and/or follow-up is divided into different phases each with its own baseline visit for within-cycle visit scheduling.

In-study cycles may be defined as required, optional or conditional. A conditional cycle is unexpected unless triggered by a condition specified in the conditional cycle map (see Section 8.8, “Conditional Maps”). Required in-study cycles are required of all subjects unless the cycle is changed to optional or unexpected by the conditional cycle map. Optional in-study cycles may be completed or not at the discretion of the clinical site, unless the cycle is changed to required or unexpected by the conditional cycle map. Optional cycles become required once they start, i.e. visit scheduling and visit requirements become active within an optional cycle when one or more visits have been received.

A scheduling method should be specified for all in-study cycles, regardless of type. This is used to calculate the expected start date for required cycles, as well as for optional and conditional cycles (should they become required as a result of a conditional cycle map trigger). In-study cycles can be scheduled to begin a specified number of days following: the termination of the previous cycle, the baseline of the previous cycle, the baseline of the first in-study cycle, a specified visit number, or in the case of a cycle triggered by the conditional cycle map, the visit on which the condition was met. You will also be asked to specify an overdue allowance. When this time expires DFdiscover will generate an overdue visit query for the first required visit in the cycle if it has not yet arrived.

It is legal for any in-study cycle to consist of a single visit. If this is the case, the visit must be defined using the B (baseline) visit type, which then becomes both the baseline and termination visit for the cycle. This feature makes it possible to schedule visits relative to any other preceding visit in the visit map, rather than having all visits scheduled from a common baseline, as is the clinical trial norm. Such dynamic scheduling can be accomplished by scheduling each single visit cycle using any of the legal cycle scheduling methods described in Section 8.4.4, “Cycle Specifications”.

Most in-study cycles will consist of several visits, in which case they must include at least one baseline and one termination visit. A typical list of visit types for an in-study cycle would include:

For a description of the visit types, what they mean and the rules that apply to each of them skip ahead to Section 8.5.2, “Visit Type”.

The end cycle is so named simply because it comes at the end of the visit map. Its purpose is to serve as a container for any unscheduled visits that do not belong to a screening or in-study cycle. Because the end cycle contains no scheduled visits it does not have a scheduling method or start date. The end cycle may contain 3 visit types: O (optional), R (required on termination), and A (abort).

This is where you should define most event reports, e.g. adverse events, outcome events, hospitalizations, change of medication, problem reports, etc. Such assessments are defined as type O visits (optional), but they can become required during the study, triggered by data collected at other visits, as we'll see below when we discuss the conditional visit map (see Section 8.8.2, “Conditional Visit Map”).

The end cycle can also contain type R visits (required on termination), used to collect CRFs that become due when all subject follow-up ends. This might be used for subject diary forms, or any other assessment that is not required until the subject has completed the study.

Type A visits (abort), which terminate all follow-ups for all cycles, should be placed in the end cycle.

Each screening, in-study and end cycle begins with a cycle definition record containing 7 fields, which can be specified using study setup work sheet 3a, and entered into the visit map using the DFsetup Visit map view.

Each CRF page in a DFdiscover study is uniquely identified by 3 keys: a CRF plate number, a visit number and the subject ID.

Visit numbers (also referred to as assessment and sequence numbers) serve 2 purposes. For scheduled and optional visits they distinguish among different visit dates or times at which subjects were seen in the clinic, lab, home, etc. and for numbered event reports they serve as the report number, to distinguish, for example, one adverse event report from all others.

Each visit number must be an integer in the range 0-65535. Those less than 511 can appear in the barcode; otherwise, they must appear as the first data field at the top of each CRF page. If the visit number is greater than or equal to 511, and is fixed for the CRF page on which it appears, it can be pre-printed in the first data field so that it need not be entered by those recording subject data on the CRFs.

Although visit numbers are typically chosen sequentially this is not a requirement. Gaps can appear in the visit number list, and visit numbering need not correspond to the chronological order in which visits occur, as this is determined by the order in which they are listed in the visit map. Visit numbers can simply be viewed as an identification number that distinguishes one subject assessment from another.

Within each cycle the expected chronological order of the visits corresponds to the order in which they are listed in the visit map. Thus, for example, if a study uses visit numbers 1-50, and you discover that you need to add a new visit between visits 11 and 12, you could chose a number like 115, insert it in the visit map between visits 11 and 12, and specify an entry in DFpage_map to display it as 11.5 on quality control reports. This is the only way that visit numbers can appear to have decimal values. At the DFdiscover database level all visit numbers must be integers, but the CRFs can be designed to show decimals and the page map can convert the relevant integers to decimal values for the Query Reports sent to the clinical sites.

The selection of visit numbers should be done with care. They can be arbitrary but ideally they should be meaningful. For example, in a study consisting of up to 9 cycles, each with up to 99 visits, and with the possibility that each visit might need to be repeated, but no more than 9 times, visit numbers might be designed such that the first digit is the cycle number, the next 2 digits identify the visit number within the cycle, and the last digit is 0 for the first occurrence of the visit and 1-9 for repetitions. Thus, for example, visit number 4132 could be designed to represent the second repetition of visit 13 in cycle number 4.

For numbered reports, e.g. adverse event reports, hospitalization reports, medication change reports, etc., the visit number is more commonly called a sequence number. Since all visit/sequence numbers must be unique you cannot use the same value for both a visit and a sequence number. The recommended solution is to use a prefix number plus the report number to form sequence numbers that are different from any of the visit numbers used in the study. For example, to allow a maximum of 999 adverse event reports for each subject, in a study where all visit numbers were in the range 0-4999, we might use 5 + the adverse event report number to form sequence numbers in the range 5001-5999 for each adverse event report.

To make it easier for those completing the CRFs the visit number field can be displayed in separate parts on the CRF and combined by DFdiscover to compose the visit number key. In the first example described above the CRFs completed during the screening cycle might appear on the CRFs as:

Screening Visit #[ ][ ] repetition #[ ]

The cycle number, zero in this case, is not required. For visits completed during the in-study cycles the CRFs might read:

Phase #[ ] Visit #[ ][ ] repetition #[ ]

And for the adverse event forms the assessment number could look like this:

Adverse Event #[ ][ ][ ]

The prefix number 5, needed to put adverse event sequence numbers in the 5000 series, in the example above, can be specified as a constant when defining the sequence number for the adverse event plate(s) in DFsetup.

To make sure that investigators will be able to locate the specific CRF page related to each data query, the study page map ( Page Map) should be used to convert visit and sequence numbers into meaningful labels. This becomes particularly important when visit numbers are comprised of several parts and sequence numbers use a fixed prefix, as in the above examples.

The visit map can accept a single visit number, and a range or range list of visit numbers in a single visit map entry. This greatly simplifies the specification of various types of optional assessments, such as adverse event reports, hospitalizations, and interim visits. In some cases, the distinction may need to be made between visit ranges in which visit numbers must be used in order (e.g. adverse events), and visit ranges in which visit numbering may include gaps. Two types of range syntax accommodate these behaviors:

Visits specified with the #-# syntax will appear in order in the DFexplore record list. Visits with #~# will not appear in the DFexplore record list until they are manually added using the DFexplore Assessment - Add New Assessment menu item.

	Note
	It is invalid to mix the #-# and #~# syntax within the same visit entry. If a range list contains both - and ~, the ~ is treated as a -.

DFdiscover recognizes 12 different visit types each denoted by a single letter key, one of: XPBOSTWFEARr. The rules governing the usage of each visit type are described below.

A short (32 character maximum) descriptive must be provided for each visit (e.g. Cycle 1 Baseline, Week 2 Follow-up, Diary Card Week 22, etc.). This label is used to describe overdue visits on quality control reports if the visit is flagged as overdue. Thus each visit must have a unique visit label.

When a visit list is defined (e.g. 5001-5999 for adverse event reports) the label must include some part of the visit number in order to create unique labels. This can be accomplished using the same visit number substitutions described for the study page map. The label for visits 5000-5999 in our example might be specified as:

Adverse Report #%{S.2.3}

which indicates that, starting at the 2nd digit, the next 3 digits are to be included in the label immediately following

Adverse Report #

This results in the last 3 digits of the visit number being used to produce visit labels as in the following examples:

Adverse Report #001
Adverse Report #002

A visit due day, relative to the cycle baseline, must be specified for all scheduled visits. The due day must be negative for all pre-baseline visits (P), zero for all baseline visits (i.e. the first type X visit in the screening cycle, and all type B and F visits in in-study cycles), and positive for all scheduled follow-up visits (S, T). The due day can be greater than or equal to zero for type R visits. For screening visits (X) the due day must be zero if the visit is unscheduled and greater than zero if it is scheduled within the screening cycle. No due day is allowed for optional visits (O, E, A) or for visits linked to the next scheduled visit (r).

How long do you want to wait before calling a visit overdue? It may be OK if a visit occurs a few days late, or you might want to allow a few days for completed assessments to be transmitted, and a few days for data entry staff to review incoming CRFs, particularly if the incoming volume is large, or staffing is light. For all of these reasons it is a good idea to specify a grace period, following each visit due date, during which overdue visit queries will not be created. If the overdue allowance is set to zero, and a visit has not arrived by its due date, an overdue visit query will be created the very next day (or to be more exact, the next time the DF_QCupdate program is run).

This specification identifies a date field, defined with the Visit Date attribute, which will be used to record the date on which the assessment occurred. This date must exist on one of the required plates for the visit. DFdiscover uses all dates defined with the Visit Date attribute, so this is not a limiting specification. However, the date specified here has priority and will be used for subject scheduling if more then one Visit Date is available for any assessment.

Visit map worksheet 3c can be used to specify CRF plates for each visit. This includes required plates, optional plates, the display order in which these plates are to be listed in the subject binders, and any plates that are submitted when a visit is missed. All relevant plates should be specified for each visit. This allows DFdiscover to generate a warning for any plates that arrive unexpectedly. Any plate not listed as required, optional or a missed visit plate will be flagged as unexpected and listed by report DF_PTvisits.

Plates in the required list are expected when the visit arrives, unless they have been made optional or unexpected by the conditional plate map. Similarly, plates in the optional list are not considered necessary unless they have been made required by the conditional map. Plates that are required, after conditional plate map actions have been accounted for, will be identified as missing if they have not arrived when other plates for that visit have been received. The type of plate(s) received (optional, required or unexpected) does not matter. Arrival of any plate with a given visit number indicates that the visit has occurred and thus that all plate requirements should be checked.

The check for required plates does not occur immediately. After all, if it did, DFdiscover would identify all but the first plate to arrive as missing as soon as the first plate was entered into the database. Instead, missing plates and overdue visits are identified when the DF_QCupdate report is run. This can be scheduled to execute automatically (using the UNIX cron process) or can be executed manually as deemed appropriate for the study.

If the clinical investigators know that a particular visit was missed and will never be made up they can notify the data management office (and DFdiscover) of this fact, and thereby avoid receiving an overdue visit query, by submitting a missed visit report. When DFdiscover receives a plate that has been classified as a missed visit plate for that visit, it considers the visit as completed even though none of the required plates have been received.

If this method of registering missed plates and visits is not used, it will be necessary to either record missed visits using DFexplore, when you learn of them, or require that investigators fax all CRF pages for all assessments, including those which are missed or have not been completed.

Required and optional plates and their display order can be listed on Visit map worksheet 3c, and entered into the visit map using the DFsetup Visit map view, as a list of comma or space separated values and value ranges, like this 1-3,7,9,10-12,101, or this 1-3 7 9 10-12 101.

Each cycle defined in the visit map starts with a default requirement. The screening cycle, if present, is by default required for all subjects. Each in-study cycle is defined in the visit map as required, optional or conditional. An optional cycle is converted to required if any of the visits defined in the cycle arrive. A conditional cycle is unexpected unless it becomes required through a condition specified in the conditional cycle map. The end cycle, if present, is not required being just a container for unscheduled visits.

Using the conditional cycle map the requirement for screening and in-study cycles can be changed from their default visit map setting to any of: required, optional or excluded.

If there is more than one condition for a given cycle and the conditions have different actions, e.g. one making the cycle required while another makes it excluded, there is the potential for conflict, which will arise if 2 or more conditions having different actions are met. DF_QCupdate resolves such conflicts by applying the action specified for the last condition met. Thus it is important to consider the order in which conditions are specified in the conditional cycle map. If necessary conditions can be re-ordered within the Conditional Cycles view in DFsetup.

The following example illustrates how conditional cycle specifications are stored in DFccycle_map. It shows 5 conditions each followed by one or more action statements. Each action statement consists of 2 fields. The first field indicates the action to be applied when the condition is met, and the second field indicates the cycle or cycles to which the action is applied. If the first field contains a + (plus sign), the cycle(s) are required; a - (minus sign) indicates that they are unexpected, and a ~ (tilde) indicates that they are optional.

# After screening visit 0 subjects proceed to:
# Cycle 1 if hypertensive, defined by: visit 0, plate 1, field 13 equals 1
# Cycle 2 if normotensive, defined by: visit 0, plate 1, field 13 equals 2
# Hypertensive subjects may then optionally proceed to cycle 3,
# but normotensive subjects never do
IF|0|1|13|1
+|1
-|2
~|3
IF|0|1|13|2
+|2
-|1,3

# Cycle 3 requirements depend on the final diastolic reading recorded at
# visit 19 of cycle 1, in field 22 of plate 9. Cycle 3:
# - is not to be done if then diastolic is less then 80
# ~ optional if the diastolic is 80-89
# + required if the diastolic is 90 or more
IF|19|9|22|<80
-|3
IF|19|9|22|80-89
~|3
IF|19|9|22|>89
+|3

DFdiscover report DF_ICvisitmap checks the conditional cycle map for syntax errors, and DF_SSvisitmap can be used to produce a numbered list of the conditions, according to the order in which they are defined in DFccycle_map. Cycles effected by the conditional cycle map are indicated on the report produced by DF_PTvisits with a CC#[rox] tag, where # is the condition order number, and the suffix r, o or x indicates whether the cycle became required, optional or excluded respectively, when the condition was met.

Each visit defined in the visit map starts with a default requirement, which is either optional (visit types O, E, A) or required (all the rest). Using the conditional visit map the requirement for any visit can be changed to any of: required, optional or excluded.

If there is more than one condition for a given visit and the conditions have different actions, e.g. one making the visit required while another makes it excluded, there is the potential for conflict, which will arise if 2 or more conditions having different actions are met. DF_QCupdate resolves such conflicts by applying the action specified for the last condition met. Thus it is important to consider the order in which conditions are specified in the conditional visit map. If necessary, conditions can be re-ordered by editing DFccycle_map directly.

Conditional visit map action statements have the same syntax as described above for the conditional cycle map, except of course that the second field contains a list of the visits (not cycles) effected by the action. When the first field contains a + (plus sign), the visit(s) are required; a - (minus sign) indicates that they are unexpected, and a ~ (tilde) indicates that they are optional.

Conditional visit map action statements support one feature not supported by any of the other conditional maps. This is the ability to use the key word value, which is interpreted as the value of the data field, tested by the IF statement, to define the list of visits effected by the condition. The following example illustrates how conditional visit specifications using this feature would appear in DFcvisit_map.

# Adverse Event reports use visit numbers 5001-5999, where the
# last 3 digits correspond to the AE Report# recorded on AE forms.
# At each follow-up visit investigators are asked:
# Has the subject had any adverse events since the last visit?
# [ ]no  [ ]yes -> specify AE report#s: [ ][ ][ ] to [ ][ ][ ]
# The AE report numbers are recorded in fields 12 and 13 on plate 101.
IF|*|101|12|>0
+|5001~5000+value
IF|*|101|13|>0
+|5001~5000+value

# Adverse Event reports use visit numbers 5001-5999 in sequential order.
# These visit numbers, like all DFdiscover visit numbers, appear in field 6.
# AEs are reported on plate 101.
# If for example report 5012 has arrived, 5001-5012 should all be in the database
IF|*|101|6|>5001
+|5001~value

These 2 examples illustrate the 2 supported uses of the value keyword. These are the only supported uses. No other mathematical manipulations are allowed.

Use DFdiscover report DF_ICvisitmap to check the conditional visit map for syntax errors, and DF_SSvisitmap to produce a numbered list of the conditions, according to the order in which they are defined in DFcvisit_map. Visits effected by the conditional visit map are indicated on the report produced by DF_PTvisits with a CV#[rox] tag, where # is the condition order number, and the suffix r, o or x indicates whether the visit became required, optional or excluded respectively, when the condition was met.

For each visit, a list of required and optional plates is defined in the visit map. Think of this as the default plate requirements. Using the conditional plate map the requirement for any of these plates can be changed to required, optional or excluded.

Plate requirements for each visit are checked by DF_QCupdate if at least one plate is found for that visit in the study database. Each visit found in the database is checked regardless of whether the visit was required, optional or unexpected. Missing plate queries are created for any required plate that is missing, but queries are not created automatically for unexpected records. Instead these cases are written to the DFdiscover retrieval file and displayed by DF_PTunexpected. These tools should be used to review the unexpected cases so that the appropriate action can be taken. At one extreme unexpected records may arise because of a simple data entry error and at the other extreme they may identify a serious protocol violation that requires personal attention.

	Important
	may contain multiple entries for the same set of keys. This is because a plate may be rendered unexpected by a condition being met in DFcplate_map and DFcvisit_map. In DFexplore, an unexpected plate can only be retrieved once in a given set of records, regardless of the condition that made it unexpected.

If the conditional plate map contains multiple conditions affecting the same plates at the same visits it is possible for conflicts to occur. One condition might indicate that a plate is required while another indicates that it is optional or excluded at the same visits. DF_QCupdate evaluates conditions in the order in which they are defined in the conditional plate map, and for each action the last condition that is met wins. It is thus important to consider the order in which conditions are defined in the conditional plate map if different actions have different consequences for a given visit/plate combination.

In a conditional plate map, the action statements begin with either +, -, or ~ (for required, unexpected and optional respectively), followed by a visit number, a visit list or * (asterisk). This indicates the type of action and the visits to which the action is to be applied. The second field, following the |, is the list of plates affected by the condition at these visits.

An asterisk, in place of a visit number or list, in the first field of an action statement, indicates that the action is to be applied to the visit at which the condition was met. If the condition includes AND statements it is possible for the visits referred to in the IF and AND statements to differ. When this occurs the condition is classified as having been met at the visit referenced in the IF statement. Thus when using * to indicate that plates are required at the visit on which the condition was met make sure the appropriate visit is referenced in the IF statement.

# For follow-up visits 3-12 and 16 performed after Dec 31,2003
# a new form, plates 216-218, is required.
# This form did not exist prior to this date and thus would be unexpected
# for follow-up visits performed before Jan 1, 2004.
# The visit date is recorded in dd/mm/yy format in field 10 of plate 200
# at each of these follow-up visits.
IF|3-12,16|200|10|>31/12/03
+*|216-218
IF|3-12,16|200|10|<01/01/04
-*|216-218

# For all follow-up visits performed after Dec 31,2003
# a new form, plates 216-218, is required.
# This form did not exist prior to this date and thus would be unexpected
# for all follow-up visits performed before Jan 1, 2004.
# The visit date is recorded in dd/mm/yy format in field 10 of plate 200
# at each of these follow-up visits.
# Plate 200 is only used at follow-up visits (3-12 and 16).
IF|*|200|10|>31/12/03
+*|216-218
IF|*|200|10|<01/01/04
-*|216-218

# For subjects with a recent history of heart disease or stroke
# (field 22 on plate 15 at baseline visit 10 equals 2), the Long CVD Evaluation
# form (plates 60-66) is required at each follow-up (visits 20-80).
IF|10|15|22|2
+20-80|60-66
-20-80|67-68

# For subjects without a recent history of heart disease or stroke
# (field 22 on plate 15 at baseline visit 10 equals 1), the Quick CVD Evaluation
# form (plates 67-68) is required at each follow-up (visits 20-80).
IF|10|15|22|1
-20-80|60-66
+20-80|67-68

Use DFdiscover report DF_ICvisitmap to check the conditional plate map for syntax errors, and DF_SSvisitmap to produce a numbered list of the conditions, according to the order in which they are defined in DFccycle_map.

The conditional termination map is used to specify database conditions that indicate that follow-up has terminated, either for the current cycle, or for all cycles. Conditions are specified as for all other conditional maps, using IF and AND statements, and each condition is followed by a single action which can be either: A, to indicate that all follow-up is aborted when the condition is true, or E, to indicate early termination of the cycle in which the condition is met. Both of these uses are illustrated in the following examples.

# During screening subjects abort (do not proceed to any in-study cycles)
# if any of the 3 eligibility questions (fields 14-16 on plate 1 at visit 0)
# is answered no (which is coded 1)
IF|0|1|14|1
A
IF|0|1|15|1
A
IF|0|1|16|1
A

# The trial consists of several treatment cycles, each of which may end early.
# A question represented by field 33 on plate 20 at each follow-up visit asks:
# "Is the subject continuing with this course of treatment?"
# If the answer is no (code 1) the cycle terminates at that point
# and the next cycle is scheduled.
IF|*|20|33|1
E

When termination occurs the visit date of the visit at which termination was triggered becomes the abort or early cycle termination date, and is used like any other termination date to decide whether other visits are still required. Visits scheduled after a termination date are not required but those scheduled prior to termination are still expected and will be called overdue if they have not arrived.

Use DFdiscover report DF_ICvisitmap to check the conditional termination map for syntax errors, and DF_SSvisitmap to produce a numbered list of the conditions, according to the order in which they are defined in DFcterm_map. Visits at with a conditional termination has been triggered are indicated on the report produced by DF_PTvisits with a CT# tag, where # is the condition order number.