Chapter 2. DFdiscover Study Files

Data records have the common fields and characteristics defined in Table 2.3, “DFdiscover Retrieval File field descriptions”.

This is an example of a DRF listing all primary records having one or more queries attached to them. The DRF filename ext_qcs.150813.drf was created on August 13, 2015 and has the description external qc notes.150813.

99001|1|2
99001|1011|9
99002|1|2
99002|22|5
99002|1011|9
99004|1|2

This file contains the edit checks that are defined for this study. The edit check language is fully described in Edit checks.

edit SetInit()
{
    if ( dfblank( init ) && !dfblank( init[,0,1] ) )
        init = init[,0,1];
}
edit AgeOk()
{
    number      age;
    if ( !dfblank( p001v03 ) && !dfblank( p001v04 ) )
    {
        age = ( p001v03 - p001v04 ) / 365.25;

Each DFdiscover study has a sites database that records where each participating site is located, who the contact person is, and what subject ID number ranges are covered by each site ID.

Each site typically corresponds to a different clinical site, but this is not required. If necessary, a single clinical site may be defined as 2 or more sites, each corresponding to a different participating clinical investigator at that site. The sites database consists of one record per site ID. The field definitions are described in Table 2.21, “Field definitions for DFcenters”.

Each site ID must be a number in the range 0 to 21460 and uniquely identifies the site within the database. All site numbers printed on DFdiscover reports are leading zero-padded to 3 digits but they may be up to 5 digits in length if the site number is greater than 999. The contact person is required as it is the person that outgoing faxes for the site are addressed to. A primary fax is not required and may be left blank for sites that are not meant to receive Query Reports. The primary fax number, if specified, should exactly match the number, including long distance, country, and area codes, that would be dialed from a numeric keypad. Most punctuation characters are ignored so they can be used for improving readability. Valid punctuation characters include: +#*-,()0-9 For example, 1-(416)521-9800 is equivalent to 14165219800.

	Whitespace characters
	Whitespace characters (space and tab) may not be used as punctuation as they are interpreted as delimiters between multiple entries.

Each comma inserts a one-second pause in the dialing sequence. This can be helpful when leaving a local PBX or waiting to dial an extension.

A valid email address may also be supplied in place of or together with a primary fax number. The email address must be specified using the notation mailto:email_address. The prefix mailto: is fixed and required while email_address must be a valid email address (there is no validity checking performed on email addresses, so be careful to enter them correctly).

If more than one email and/or fax number is specified, each must be separated by a single space. Comma separators are not permitted.

Subject ID ranges are specified in fields 11 through the end of the record. There is no limit to the number of range fields that can be given. Each range field contains a minimum subject ID and maximum subject ID separated by exactly one space character. For example,

|101 199|

indicates that subject IDs 101 through 199 inclusive are to be included for the site. Individual subject IDs that are disjoint from any range are indicated by setting both the minimum and maximum ids to the actual subject ID. For example,

|244 244|301 399|401 420|

includes subject IDs 244, 301 through 399 inclusive, and 401 through 420 inclusive.

In the event that subject IDs are incorrectly entered in data records, there should always be a 'catch-all' site listed that receives all subject IDs that do not fall into any of the other subject ID ranges. This site is indicated by the phrase ERROR MONITOR in the 11^th field and no other subject ID range fields.

Note

DFcenters may be modified at any time, via DFsetup only, for an active study. However, if quality control reports are being created for the study, the DFdiscover report DF_QCupdate must always be run after DFcenters modification and prior to Query Report creation. DF_QCupdate ensures that the most up-to-date DFcenters file will be used when generating subject status and scheduling information for the Query Reports.

011|Lisa Ondrejcek|DF/Net Research, Inc|140 Lakeside Avenue, Suite 310, Seattle, Washington, 98122|1-206-322-5932|country:USA;enroll:100|1-206-322-5931|Lisa Ondrejcek|1-206-322-5931||1101 1149|1151 1199

This field contains zero of more semi-colon ( : ) delimited pairs, where each pair is a keyword and value where the keyword is from the list country, beginDate, endDate, enroll, protocol1, protocol1Date, protocol2, protocol2Date, protocol3, protocol3Date, protocol4, protocol4Date, protocol5, protocol5Date, testSite.

This table describes the conditional cycle map file structure and provides an example. It does not describe all of the syntax and rules related to this feature. Usage instructions for all 4 conditional maps is fully described in Study Setup User Guide, Conditional Maps.

The file contains one or more specifications, each consisting of a condition definition followed by one or more actions to be applied if the condition is met. Entries in the file have the general appearance of:

IF|Visit List|Plate|Field|Value
AND|Visit List|Plate|Field|Value
[+-~]|List of conditional cycles

Each condition may be followed by one or more action statements. Each of these statements begins with: '+' to indicate that the cycles are required, '-' to indicate that the cycles are unexpected, or '~' to indicate that the cycles are optional, when the condition is met.

There is no limit to the number of condition/action entries that may be included but the order in which the conditions appear may be important, because in the event of a conflict, the action specified by the last entry, applicable to each cycle, is the action that will be applied. This point is illustrated in the following example.

IF|0|1|22|6
+|2,5,8
-|3,6,9
~|4,7,10

IF|0|1|22|5
AND|0|9|13|>0
AND|0|9|36|!1
+|11

IF|1|3|9|~^A
-|11

This example, consists of 3 conditional specifications. They are applied in the order in which they are defined. The first specification indicates that, if field 22 on plate 1 at visit 0 equals 6, then cycles 2, 5 and 8 are required; cycles 3, 6 and 9 are not expected; and cycles 4, 7 and 10 are optional. The second specification indicates that, if field 22 on plate 1 at visit 0 equals 5, and field 13 on plate 9 at visit 0 is greater than zero, and field 36 on plate 9 at visit 0 is not equal to 1, then cycle 11 is required. The third specification indicates that, if field 9 on plate 3 at visit 1 begins with the capital letter "A", then cycle 11 is not expected.

If both conditions 2 and 3 are met cycle 11 will be considered unexpected because, when a conflict occurs, the last condition wins.

This table describes the conditional visit map file structure and provides an example. It does not describe all of the syntax and rules related to this feature. Usage instructions for all 4 conditional maps is fully described in Study Setup User Guide, Conditional Maps.

The file contains one or more specifications, each consisting of a condition definition followed by one or more actions to be applied if the condition is met. Entries in the file have the general appearance of:

IF|Visit List|Plate|Field|Value
AND|Visit List|Plate|Field|Value
[+-~]|List of conditional visits

Each condition may be followed by one or more action statements. Each of these statements begins with: '+' to indicate that the visits are required, '-' to indicate that the visits are unexpected, or '~' to indicate that the visits are optional, when the condition is met.

There is no limit to the number of condition/action entries that may be included but the order in which the conditions appear may be important, because in the event of a conflict, the action specified by the last entry, is the action that will be applied. This point is illustrated in the following example.

IF|0|1|22|6
+|10-19
-|20-29
~|30

IF|0|1|22|5
AND|0|9|13|>0
AND|0|9|36|!1
+|40

IF|1|3|9|~HIV
-|40

This example, consists of 3 conditional specifications. They are applied in the order in which they are defined. The first specification indicates that, if field 22 on plate 1 at visit 0 equals 6, then visits 10 to 19 are required, visits 20 to 29 are unexpected, and visit 30 is optional. The second specification indicates that, if field 22 on plate 1 at visit 0 equals 5, and field 13 on plate 9 at visit 0 is greater than zero, and field 36 on plate 9 at visit 0 is not equal to 1, then visit 40 is required. The third specification indicates that, if field 9 on plate 3 at visit 1 contains the literal string "HIV", then visit 40 is not expected.

If both conditions 2 and 3 are met, visit 40 will be considered unexpected because, when a conflict occurs, the last condition wins.

This table describes the conditional plate map file structure and provides an example. It does not describe all of the syntax and rules related to this feature. Usage instructions for all 4 conditional maps is fully described in Study Setup User Guide, Conditional Maps.

The file contains one or more specifications, each consisting of a condition definition followed by one or more actions to be applied if the condition is met. Entries in the file have the general appearance of:

IF|Visit List|Plate|Field|Value
AND|Visit List|Plate|Field|Value
[+-~]Visit List|List of conditional plates

Each condition may be followed by one or more action statements. Each of these statements begins with: '+' to indicate that the plates are required, '-' to indicate that the plates are unexpected, or '~' to indicate that the plates are optional, at the specified visits, when the condition is met.

There is no limit to the number of condition/action entries that may be included but the order in which the conditions appear may be important, because in the event of a conflict, the action specified by the last entry, applicable to each plate, is the action that will be applied. This point is illustrated in the following example.

IF|0|1|22|6
+10,20|50,51
-10,20|40,41
~10,20|15

IF|0|1|22|5
AND|0|9|13|>0
AND|0|9|36|!1
+91-95|16

IF|1|3|9|yes
-91|16

This example, consists of 3 conditional specifications. They are applied in the order in which they are defined. The first specification indicates that, if field 22 on plate 1 at visit 0 equals 6, then at visits 10 and 20: plates 50 and 51 are required, plates 40 and 41 are not expected, and plate 15 is optional. The second specification indicates that, if field 22 on plate 1 at visit 0 equals 5, and field 13 on plate 9 at visit 0 is greater than zero, and field 36 on plate 9 at visit 0 is not equal to 1, then at visits 91-95 plate 16 is required. The third specification indicates that, if field 9 on plate 3 at visit 1 contains exactly the string "yes", and nothing more, then plate 16 is not expected at visit 91.

If both conditions 2 and 3 are met plate 16 will be considered unexpected at visit 91, but required at visits 92-95, because, when a conflict occurs, the last condition wins.

This table describes the conditional termination map file structure and provides an example. It does not describe all of the syntax and rules related to this feature. Usage instructions for all 4 conditional maps are fully specified in Study Setup User Guide, Conditional Maps.

The file contains one or more specifications, each consisting of a condition definition followed by one action to be applied if the condition is met. Entries in the file have the general appearance of:

IF|Visit List|Plate|Field|Value
AND|Visit List|Plate|Field|Value
A or E

Each condition is followed by either the letter 'A' (abort all follow-up), or 'E' (early termination of the current cycle). The termination date is defined as the visit date of the visit that triggered the condition, specifically the visit specified in the IF statement.

IF|0|1|22|6
A

IF|6|1|22|5
AND|6|9|13|>0
AND|6|9|36|!1
E

This example, consists of 2 conditional specifications. The first specification indicates that, if field 22 on plate 1 at visit 0 equals 6, then all follow-up terminates as of the visit date for visit 0. Visits scheduled to occur before this date are still expected, but visits scheduled following this date are not.

The second specification indicates that, if field 22 on plate 1 at visit 6 equals 5, and field 13 on plate 9 at visit 6 is greater than zero, and field 36 on plate 9 at visit 6 is not equal to 1, then the current cycle terminates, i.e. the cycle in which visit 6 is defined; with the termination date being the visit date of visit 6. Any visits in this cycle (or in previous cycles) that were scheduled to occur before the termination date are still expected, but visit within this cycle scheduled following this date are not. On termination of a cycle, subject scheduling proceeds to the next cycle in the visit map, if there is one.

Each record in the CRF type map has two fields, an acronym or short form (1^st field), and a descriptive label (2^nd field). The CRF type acronym and label appear in the Import CRFs dialog. The CRF type label appears in the DFexplore Preferences dialog.

This file is optional. If it does not exist, CRF Types are not used for this study.

PAPER|Print Version
CHINESE|Chinese
ENGLISH|English
SWEDISH|Swedish
FRENCH|French
SPANISH|Spanish

Each record in the CRF background map has three fields: the visit number with the background to be repeated (1^st field), the list or range of visit numbers where the background will be repeated (2^nd field), and an optional comment field (3^rd field).

This file is optional. If it does not exist, the default CRF will be displayed for visits not tagged during the Import CRFs step. If no default CRF has been imported, the CRF background will be blank for untagged visits.

10|11,13-14,16-17,19-20|Quarterly visits
12|15,18|Annual visits
22|25,28|Annual lab work

This file contains an internal, binary equivalent of the edit checks stored in the plain text DFedits file. This binary format contains no external references to other included files and is a more compact representation that can be more efficiently transmitted to and interpreted by DFexplore clients.

The DFedits.bin file is created when Publish is selected in DFsetup's edit checks dialog.

This file is the only edit checks file used by DFexplore.

The file map lists all of the unique plate numbers used in a particular study database. The study server uses this file at start-up to determine which database files it may need to initialize and allocate file descriptors for. In addition to the listed plate numbers, the study server also allocates file descriptors for the new records file () and the query data file ().

The format of this file is one record for each plate defined in the study setup. Each record has 4 fields. The first field of the record is the plate number, leading zero-padded to three digits. The second field is a textual description of the plate from the user-supplied definition in DFsetup. The textual part is displayed in the plate selection dialogs that can be found in various study tools. The third field identifies how the visit/sequence number key field is coded for that plate. A code of 1 means that the visit/sequence number is in the barcode; a code of 2 means that it is the first data field on the data entry screen for that plate. Any other code is an error. The fourth field indicates whether the arrival of this plate signals early termination of study follow-up for the subject, as would for example the arrival of a death report. A code of 1 appears if the plate signals early termination, otherwise the code is 2.

The records in the file map do not have to be sorted in increasing plate number order as the file is internally sorted by the study database server at start-up time.

001|Dosage of Study Drug (DOST-2)|2|2
002|Concomitant Medication (COM)|1|2
003|Written Consent (CONS-w)|1|2
005|Diagnosis (DSM-III-R)|1|2
006|Psychiatric History (PSH)|1|2
200|Death Report|1|1

A study logo is a small PNG file, maximum dimension is 64 pixels tall and 128 pixels wide. DFdiscover reports can display the study logo in the top-left corner of the report output. If no study logo is available, the study name is written to the header of each report output.

The study logo must be created outside of DFdiscover - there is no interface for creating it. Once the file is created, it must be copied to the study folder and saved as lib/DFlogo.png.

Lookup tables are used to select results from a list of pre-defined values and insert them into DFdiscover data fields. Lookup tables can also be defined for the query, query note, and reason fields to allow users to select pre-specified text for these fields. Lookup tables are described in Lookup tables.

A study setup may use multiple lookup tables and so the lookup table map is used to associate simple table names with more complex and lengthy full pathnames of the actual lookup tables.

Each record in the lookup table map has a lookup table name, followed by a |, and a filename containing the lookup table. DFdiscover will search for the lookup table filename first in the $(STUDY_DIR)/lut directory and if that fails in the /opt/dfdiscover/lut directory. The table name is a symbolic name that can be referenced in edit checks.

The special table names QC, QCNOTE and QCREPLY are used to associate a lookup table with the detail, note and reply fields, respectively, in the DFexplore Field > Add/Edit/Reply Query dialogs. The special table name REASON is used to associate a lookup table with the reason code and text for data changes.

QC|DF_QClut
QCNOTE|DF_QCnotelut
QCREPLY|DF_QCreplylut
REASON|DF_Reasonlut
MEDS|meds.dict
COSTART|costart.dict
WHO|who.dict

Each record in the missing value map has two fields, the missing value code (1^st field), and a descriptive label for the code (2^nd field). The missing value code appears verbatim in any data field which has been identified as missing with that code.

The missing value map lists all missing value codes used in the study. These codes can be entered into any data field by selecting the desired code from the list available under Field > Mark Field Missing in DFexplore.

Note that the field delimiter, |, which is used in all DFdiscover databases, can not be used as a missing value code (for obvious reasons). Any other single (or multiple) character is acceptable.

This file is optional. If it does not exist, a single missing value of * (asterisk) - Not Available is available by default. If it does exist but is empty, then no missing values are permitted.

Changes to the missing value map for an in-progress study

DFdiscover determines if each data value is a missing value code by comparing the value with each of the missing value codes in the map. If there is a match, DFdiscover handles that data value as a missing value. If there is no match, the data value is handled as a normal data value. This is important to remember because changes to the missing value map after a study has started and data has been entered can result in DFdiscover handling data values in a manner which is different from the handling when the value was originally entered. For example, defining .A as a missing value code at study start and then subsequently deleting that code from the missing value map will result in DFdiscover treating each occurrence of .A in the current database as a normal data value.

*|Not Available
.|Not Applicable
-|Temporarily Unavailable
.U|Unknown

This file is optional for a study. If defined, it must be located in $(STUDY_DIR)/lib/DFpage_map. The page map allows one to specify non-default labels, to identify visits and CRF pages, on Query Reports and in DFexplore's subject binder view. If a page map file is not defined, queries and pages in the binder are identified by the visit number and plate number keys of the CRF.

The first record in a page map contains only a single field which specifies a text label to be used as a title over the queries. The default label is:

PLATE       SEQNO

This label appears at the top of the Fax/Refax List and Question & Answer List sections of the Query Reports.

The remaining records describe the text labels to be used in place of the default plate and visit number identifiers.

The first field is the plate number, the second field is the visit/sequence number, and the third field is the substitution to be used for that plate and visit/sequence combination. The third field can contain %P and %S which are replaced with the plate number and the visit/sequence number fields from the query, respectively. It may also contain parts of the plate number and/or sequence number fields by using the notation %{n.P}, %{P.n}, %{n.S}, or %{S.n}. %{n.P} which returns the leading n digits of the plate number while %{P.n} returns the trailing n digits of the plate number. Similarly, %{n.S} and %{S.n} produce n leading and trailing digits of the sequence number. The third field may also contain the notation %# which is replaced with the value stored in field n of the data record matching the specified plate and sequence number. Additionally, when using the %# notation, and for data fields that have a data type of choice or check, it is possible to request that the reported value be decoded by using the %n:d notation. This substitutes the label associated with the value, instead of the value itself. ^[a]

When a Query Report is created, those queries whose plate and visit numbers match the first and second fields, will be identified on the Query Report by the label which appears in the third field.

If either the first field or second field contains a *, all values for that field that have not yet matched a previous rule will use the format in the third field.

For more information, see Study Setup User Guide, Page Map.

PAGE (PLATE-SEQ)
018|001|MED VISIT1
*|001|VISIT1 (%P-%S)
025|*|TERM (%P-%S)
*|*|(%P-%S)

A query sort order map can be specified to control the order in which queries appear on the reports created by DF_QCreports.

If DFqcsort is not defined, queries will appear on Query Reports sorted by ascending subject ID, then visit number, then plate, and finally data field number. A different sort order can be specified to reorder queries from particular visits and/or plates. For example, one might want all queries from adverse event reports to appear at the top of each subject's list. This can be done with DFqcsort.

The file contains one or more records in the following format:

plate#|visit#|sort_order#

where the sort_order# is an integer-valued sort priority such that a lower value indicates an earlier sort order. There is no minimum or maximum value for sort_order#, hence negative numbers can be used to give higher priority to sort_order#s of zero or greater. If two or more entries assign the same sort_order#, those entries are sorted in the default manner of ascending plate number within ascending visit number.

Within each record the plate number, or the visit number, can be replaced by * to signify all plates for a specified visit, or all visits for a specified plate. In such cases queries are sorted numerically on the unspecified field within the specified field. For example:

12|*|1

specifies that, for each subject, all queries on plate 12 are to be given a sort priority of 1 as compared to other queries. Since no visit number is specified, if queries appear on plate 12 at more than one visit for a given subject, they will appear on the Query Report sorted by visit/sequence number. * may also be specified for both plate and visit numbers (to catch all plate and visit combinations that were not otherwise specified), but this is not necessary as this is given the lowest sort priority by default.

Note that while sort order control is provided over plates and visits, no control is provided at the individual field level. Queries on a given plate are always sorted in field number order. Also queries and records are always sorted by ascending subject ID. Thus the control provided here does not allow for all possible sort orders. It merely provides a mechanism for controlling query ordering by plate and visit numbers.

12|*|1  (1)
*|1|2   (2)
25|2|3  (3)
13|2|4  (4)
5|2|5   (5)
*|2|6   (6)
*|*|7   (7)

Each record in the Query category code map has four fields, the category code (1^st field), the descriptive label (2^nd field), the auto-resolve value (3^rd field), and the sort value (4^th field). The query category code appears verbatim in any data field which has been assigned a query with that code.

The pre-defined categories are assigned integer codes from 1-6 and 21-23 (inclusive). User-defined categories must be assigned integer codes ranging from 30-99 (inclusive). Category codes must be unique.

The problem labels must have a length ranging from 1-20 characters (inclusive), must be unique, and are case insensitive.

The auto-resolve field may be set to No (0) or Yes (1). With auto-resolve set to Yes, an outstanding query with this category code will be automatically resolved if a new reason is added to the corresponding data value.

The sort value may be set to any integer value between -2147483648 and 2147483647. Category types are sorted in ascending order by sort value, then by code.

The query category code map lists all query category codes in the study. A query with one of these types can be entered into any data field by selecting the desired type from the category code list available under Field > Add Query... in DFexplore.

When a new study is started, the file is created. By default, the file is populated with the following:

1|Missing|1|0
2|Illegal|1|0
3|Inconsistent|1|0
4|Illegible|1|0
5|Fax Noise|1|0
6|Other|1|0
21|Missing Page|0|0
22|Overdue Visit|0|0
23|EC Missing Page|0|0

1|Missing|1|0
2|Illegal|1|0
3|Inconsistent|1|0
4|Illegible|1|0
5|Fax Noise|1|0
6|Other|1|0
21|Missing Page|0|0
22|Overdue Visit|0|0
23|EC Missing Page|0|0
30|Clinical QC|1|1
50|Needs Review|0|1
37|Refuted|1|2

Users create and save report history lists (including options) in much the same way that they create and save task lists.

The reports history list for ail study users is stored in this file in the study lib directory. Each history list is represented by a single record in this file. Each user may have more than one history list.

History lists are created in DFreport by executing the desired reports and then saving the history list. There is no text-based interface to this file or its contents.

The schema, or data dictionary, is generated/updated automatically by DFsetup whenever a save is required for the study definition. Each field is composed of a key letter (with a leading % character) to indicate the field type, a space character, and the value of the field. This is essentially UNIX 'refer' format.

The defined key letters and corresponding field types are listed in the Table 2.39, “Schema codes and their meaning”.

The T code requires additional explanation. Its value is the variable type (one of choice, check, int, date, string) followed by the setup style name. If the variable type is date, the style name is followed by the variable pivot year and the date imputation method and whether the date is used for scheduling purposes or not. The pivot year represents the first possible year in those dates where the year is only 2 digits. The imputation method is one of:

The scheduling attribute is unused by most programs except for DF_QCupdate which searches the schema file for date fields which use the Visit Date attribute. These date fields are used to determine subject visit scheduling. DFsas also uses this information to determine the correct year value to include in the YEARCUTOFF option statement.

Each study schema begins, in order, with records defining values for the S, B, N, Y and then Z codes. If study is linked with another study then a and b fields are included identifying production and development study numbers. Thereafter, each new plate definition begins with a record defining values for the P, t, n, E, and R codes. This is followed by records for each variable in that plate. Each variable has a record that begins with an I field, followed by at least i, V, D, W, w, T, and A fields. The v, F, L, H, J, j, K, k, g, h, s, c, and C fields are included only if applicable.

%S 254
%N 12
%B 1990
%Y 0 0
%Z 40

%P 1
%p Blood Pressure Screening Visits
%n 35
%t simple
%E 1
%R PrintCRF.shx

%I 1
%i 10
%V DFstatus1
%v DFSTATUS
%D DFdiscover Record Status
%T choice SimpleChoice
%A required
%W 1
%L 0~6
%C 0 lost
%C 1 final
%C 2 incomplete
%C 3 pending
%C 4 FINAL
%C 5 INCOMPLETE
%C 6 PENDING

%I 2
%i 11
%V DFvalid1
%v DFVALID
%D DFdiscover Validation Level

This file is very much like the study schema, DFschema - database schema, but instead of variable definitions it simply catalogs all of the variable styles used in DFsetup to define new variables. Like DFschema the file is generated/updated automatically by DFsetup whenever a save is required for the study definition.

Note that the style schema lists only field types that are defined by the style itself. It omits those definitions that are specified at the variable level.

%S 254
%N 51

%I 1
%T int SimpleNumber
%A optional

%I 2
%T date SimpleDate 1940 0
%A optional
%W 8
%F dd/mm/yy

%I 3
%T string SimpleString
%A optional

%I 4
%T choice SimpleChoice
%A optional
%L $(choices)
%l 0
%c 0

The setup file contains the study definition in JSON format that can be read and written efficiently by DFsetup. It keeps the internal state of the program together with all of the information about study, page, and variable definitions. Many other study configuration files, such as the ICR tips file and study database schema, are constructed from this internal representation.

	Internal use only
	This file format is intended to be written only by DFsetup only. It may be read and processed by other programs that need to determine setup information but its internal structure is subject to change without notice.

Each study database server is configured by this file. The study server configuration keywords and their meanings are given in the Table 2.42, “DFserver.cf configuration keywords”.

STUDY_NUMBER=254
STUDY_NAME=DFdiscover Acceptance Test Study
STUDY_DIR=/opt/studies/val254
PAGE_DIR=$(STUDY_DIR)/pages
WORKING_DIR=$(STUDY_DIR)/work
PRINTER=hp4000
THRESHOLD=500000
STUDY_URL=http://www.ourstudy.com/index.html
VERSION_STRICT=0
AUTO_LOGOUT=5|30
ADD_IDS=1||
VERIFY_IDS=0|

This file is optional for a study. If defined, it must be located in $(STUDY_DIR)/lib/DFsubjectalias_map. The subjectalias map allows the specification of "aliases" (descriptive labels), each up to 30 UNICODE characters in length, that may be used in place of the standard numeric subject identifier. If a subjectalias map is defined, and has been enabled as a preference for the current user, the subject alias appears everywhere in DataFax that the numeric subject ID would normally appear. Otherwise, the numeric subject ID is displayed. ^[a]

The file contains zero or more rows, each row containing 2 fields and the fields are delimited by |. The value in the first field is the numeric subject ID and the value in the second field is the matching alias for that subject ID. Each subject ID must be unique and each subject alias must also be unique.

For more information, see Study Setup User Guide, Subject Alias Map.

150040|T1-B-40
150041|T1-B-41
150042|T1-B-42
150043|T1-B-43
150044|T1-B-44
150045|T1-B-45
200006|T2-A-6
200007|T2-A-7
200008|T2-A-8
200009|T2-A-9
200010|T2-A-10

This file is optional for a study. If defined, it must be located in $(STUDY_DIR)/lib/DFsubjectalias_map.log. The contents of the file are managed entirely by DFserver.rpc - it is not meant for external editing.

The file contains zero or more rows, each row containing 7 fields where the fields are delimited by |. Each row logs the addition, editing or deletion of a single, specific subject alias.

200703|174748|userB|n|500003|T5-B-3|
200703|180202|userB|n|250009|T2-A-259|
200703|180219|userB|c|250009|T25-A-9|T2-A-259
200722|112345|userA|d|200004||T2-A-4
200722|112345|userA|d|200005||T2-A-5

The purpose of this file is to document the location, size, and type of each data field on each study plate. This information is parsed and used by during its ICR processing of each CRF image file.

The tips file begins with 4 comment lines which identify the study number, name, number of CRF plates that have been defined and the date on which the tips file was created. This is followed by the keyword DELIMITER which identifies the single character delimiter used to separate fields in data records. The current implementation of DFdiscover accepts only the | delimiter.

The above header information is followed by N plate definitions, where N is the number of unique plates defined for the study. Each plate definition begins with plate specific information followed by M variable definitions, where M is the number of variables defined on that plate. Each variable definition includes: the data field number and unique name, the data type, legal values (if any were specified), the size of the boxes, or VAS line, used to record the data field, and its location on the CRF image that was used to define the plate in DFsetup.

Each field in the tips file has a leading keyword separated from the value by a \t (TAB) character.

The plate specific keywords are listed in Table 2.47, “DFtips plate specific keywords”. The keywords recognized for variable definitions are listed in Table 2.48, “DFtips variable specific keywords”.

# Study Number: 253
# Study Name: Demo Study 253
# Total Pages: 14
# Created: Wed Dec  1 12:33:29 2004
DELIMITER       |
PAGE    1
PLATE   1       # Blood Pressure Screening Visits
SEQ_CODE        1
PREOP   echo "$image $data" >> /tmp/test
DO_ICR  2
# FAX: plt001
FIELD   1 # ID001
TYPE    int
LEGAL   $(ids)
PART    106 84 2 50 25
PART    167 84 3 74 25
.
FIELD   2 # PINIT001
TYPE    string  skip
PART    380 84 3 74 25
.
FIELD   3 # AGE
TYPE    int
LEGAL   21-90
PART    79 182 2 50 25
.
FIELD   4 # SEX
TYPE    choice
LEGAL   0,1,2, blank
PART    0 0 0 0 0 # blank
PART    277 189 1 1 15 # male
PART    277 212 1 2 15 # female
.
FIELD   5 # RACE
TYPE    choice
LEGAL   0-65535
PART    0 0 0 0 0 # no choice
PART    464 188 1 1 15 # Caucasian
PART    464 213 1 2 15 # African American
PART    464 238 1 3 15 # Asian
PART    464 263 1 4 15 # Other
.
FIELD   6 # RACEOTH
TYPE    string  skip
PART    588 257 1 107 26
.
FIELD   7 # S1DATE
TYPE    date
FORMAT  dd/mm/yy
DATES   1940 0
LEGAL   01/01/01-today
PART    172 330 2 49 25
PART    232 330 2 50 25
PART    295 330 2 49 25

The visit map file describes the subject assessments to be completed during the study, the timing of these assessments, and the pages of the study CRFs which must be completed at each assessment.

Each assessment is identified by a visit type. There must always be a baseline visit which is typically the date on which the subject qualified for entry to the trial and was randomized. There must also be a termination visit which ends study follow-up. Between baseline and termination there are often several scheduled visits, subject diaries, laboratory tests, and perhaps a few unscheduled visits. At each of these visits there will be a set of required (and possibly optional) forms to be completed.

Each visit is defined in a single record of the visit map. The fields in each record are described in Table 2.50, “DFvisit_map field descriptions”.

For additional information regarding visit maps, refer to Standard Reports Guide, DF_QCupdate and Study Setup User Guide, Visit Map.

A simple 4-visit visitmap:

0|B|Baseline|1|9 (mm/dd/yy)|0|0| 1 2 3 4 5 6 7 8||99|3 4 1 2 5 6 8 7
10|S|One Week Followup|9|9 (mm/dd/yy)|7|0| 9 10 14||||
20|S|Two Week Followup|9|9 (mm/dd/yy)|14|0| 9 10||||
30|T|Termination Visit|9|9 (mm/dd/yy)|21|0| 11 12||||

The DFwatermark file stores a description of the watermarks available for use in a study. The file contains zero or more records. The fields in each record are described in Table 2.53, “DFwatermark field descriptions”.

In determining which watermark to use, the records are searched in sequential order from the beginning of the file. The first record to match, based upon the current user's role and the role(s) in the record, is selected.

draft|Draft watermark|DRAFT|20|255,0,0|50|1|1|unrestricted,Sites

External Quality Control report cover sheets can be included by defining them in the file QCcovers. They may then be requested by running DF_QCreports with no -i option or running DF_QCreports with -i c. If no options are specified with DF_QCreports, a full 3-part Query Report and cover sheet will be generated. If -i is used, you must also specify other report parts to be generated (e.g. s, r, q, c). The -i c option may be specified with the site selection option, -c #. This allows the user to generate cover sheets only for those site IDs specified. The -i c option by itself will generate a cover sheet and nothing else for all sites.

A cover sheet begins with a

<FOR center="#list">

tag to identify the site(s) that are to receive the cover sheet. It is legal for some sites to receive cover sheets while others do not, and for different sites to receive different cover sheets.

Cover sheets are defined using a <TEXT> block. Within <TEXT> blocks, variable substitution may be performed as described in QCtitles for customized report titles. Aside from variable substitution, all other text will appear exactly as formatted within the text block. Blank lines used to double space text will also be preserved. The default font for cover sheet text is the constant width font, fCW.

If more than one cover sheet is defined and a site ID is included in the <FOR center="#list"> for more than one cover sheet, all <TEXT> blocks from all covers sheets specified for the site ID will be added to that site's cover sheet. The <TEXT> blocks will appear in the order they appear in QCcovers, and the site will still only receive one cover sheet.

Sites not specified in either QCcovers or QCmessages do not get a cover sheet. If a site is not defined in QCcovers, but that site is named in QCmessages, a blank cover sheet is generated onto which the message(s) can be written.

Note

DF_QCreports does not perform line wrapping on cover sheets. Each text block is printed exactly as it appears in QCcovers and QCmessages. Care must be taken when choosing fonts and using variable substitutions to ensure that text lines do not exceed the width of the page. DF_QCreports also expects that the cover sheet and all messages will fit on a single cover page for each site. It will not create automatic page breaks. DFdiscover version 3.7-003 and earlier requires that font specifications in QCcovers include the control-P (^P) character; for example <TEXT font="^P12 fB">. DFdiscover version 3.7-004 and greater accept the ^P but it is no longer required. For example, <TEXT font="12 fB"> is a valid font specification and may be defined using the Query Covers view in DFsetup.

The following is an example of an English and French version of a cover sheet for an international trial, where sites 20 to 29 inclusive use French, and all other sites use English.

<FOR centers="1~19,30~300">
<TEXT font="^P12 fB">
--------------------------------------------------------------
PLEASE DELIVER THIS FAX TO THE FITNESS STUDY COORDINATOR
TO: <WHO>
Site <CENTER>: <WHERE>
<DATE>
</TEXT>
</FOR>
<FOR centers="20~29">
<TEXT font="^P12 fB">
--------------------------------------------------------------
DONNEZ CE RAPPORT AU COORDINATOR DE RECHERCHE POUR FITNESS, S'IL VOUS PLAIT
TO: <WHO>
Site <CENTER>: <WHERE>
<DATE>
</TEXT>
</FOR>

Cover sheets may include messages for all or specified site IDs. Messages are stored in the file QCmessages and follow the same rules as described for QCcovers. While messages can be added to cover sheets by placing them in <TEXT> blocks in the QCcovers file, the use of a separate file for messages makes it easier to keep the fixed (probably unchanging) cover sheet header separate from the broadcast messages, which will change frequently throughout the trial.

The file QCmessages may include more than one message, and each site may receive none, some or all of them, as indicated by <FOR centers="#list"> which must appear at the beginning of each message. If a site is to receive more than one message, the messages will be printed on the cover sheet in the order in which they are defined in QCmessages.

It is unnecessary to define a cover sheet in order to use messages. If a message is specified for a site which has not been defined in QCcovers, a blank cover sheet will be created, onto which the message(s) will be printed. Cover sheets and messages must be requested by running DF_QCreports with the -i c option or by running DF_QCreports with no -i at all.

Note

DF_QCreports does not perform line wrapping on cover sheets or messages. Each text block is printed exactly as it appears in QCmessages. Care must be taken when choosing fonts and using variable substitution to ensure that text lines do not exceed the width of the page. DF_QCreports also expects that the cover sheet and all messages will fit on a single cover page for each site. It will not create automatic page breaks. Messages will continue to go on each report until the QCmessages file is removed. If you want to keep a message for use later on, but do not want to send it to anyone in the next batch of Query Reports, leave the site number string blank. e.g. use <FOR center="">. DFdiscover version 3.7-003 and earlier requires that font specifications in QCmessages include the control-P (^P) character; for example <TEXT font="^P12 fB">. DFdiscover version 3.7-004 and greater accept the ^P but it is no longer required. For example, <TEXT font="12 fB"> is a valid font specification and may be defined using the Query Messages view in DFsetup.

In the following example all site IDs (1 to 300 inclusive) receive the announcement of an upcoming meeting. For site IDs 1, 4, 22 to 24, and 127, this is followed by an important message regarding their lack of response to data queries.

<FOR center="1~300">
<TEXT font ="^P12 fB">
--------------------------------------------------------------
PLEASE NOTE:
</TEXT>
<TEXT font="^P10 fCW">
The next FITNESS Study investigator's meeting will be held on October 9-10,
1999 in Orlando, Florida.
Location and times will follow at a later date.
</TEXT>
</FOR>
<FOR center="1,4,22~24,127">
<TEXT font="^P12 fB">
--------------------------------------------------------------
IMPORTANT!
</TEXT>
<TEXT font="^P10 fCW">
We have not received any corrections related to the Quality Control reports we
have sent to your site over the last 2 months. Please make every attempt to
resolve the outstanding data queries as soon as possible.
By protocol and agreement with the FDA, all adverse events must be reviewed by
us within 3 days of each subject assessment.
If you are having problems of any kind, please let us know.
</TEXT>
</FOR>

The external or internal report title and sub-titles for each of the 3 sections (Subject Status, Refax List, Q & A List) of a DFdiscover Quality Control report may be specified in this file. DF_QCreports checks for the existence of this file and will use it if it exists, otherwise standard titles will be produced.

Title specifications must be formatted exactly as shown in the examples to follow. The opening and closing tags must appear on new lines by themselves, with no leading or trailing text outside of the tag. Anything entered outside of a tagged block is ignored. The # symbol may be used to indicate a comment line but the # is not strictly needed, and has no special meaning inside a tagged block. For example, it is legal to include a line of # as part of a title inside a tagged block.

Tags are only recognized if they begin a new line. Nothing is to precede the tag symbol '<'. No space is allowed within the opening and closing tag except before the word "font". The "font" value must be enclosed in double quotes.

Limited font specifications may be included within the opening tag as listed in Table 2.57, “QCtitles font specifications”.

The font specification is optional. By default, font ^P10 fCW is used for external and internal report titles, and font ^P10 fB is used for the 3 report section sub-titles. Note that in DFdiscover versions 3.7-003 and earlier, font specifications must include the control-P (^P) character; for example <EXTERNAL font="^P12 fB">. DFdiscover versions 3.7-004 and greater no longer require the ^P specification, but it is accepted if present. For example <EXTERNAL font="12 fB"> is a valid font specification.

The variables enumerated in Table 2.58, “Variables available for use in QCcovers, QCmessages, and QCtitles” may be included in the external and internal report titles which appear at the top of each page, but not in the sub-titles for the 3 parts of the report (status, refax and question & answer lists).

	Note
	DF_QCreports does not perform line wrapping on report titles. Each report title and section sub-title is printed exactly as it appears in QCtitles. Care must be taken when choosing fonts and using variable substitutions to ensure that text lines do not exceed the width of the page.

Here is an example of a QCtitles file that contains formatting information for an external and internal report title and the 3 section sub-titles.

# TITLE AT THE TOP OF EACH PAGE OF AN EXTERNAL QUERY REPORT
<EXTERNAL font="^P12 fB">
FITNESS STUDY REPORT <NUM> for: <MON> <DAY>, <YEAR> at
<TIME>
TO: <WHO>, <WHERE>
</EXTERNAL>
# TITLE AT THE TOP OF EACH PAGE OF AN INTERNAL QUERY REPORT
<INTERNAL font="^P12 fB">
INTERNAL QC REPORT: <NAME> page <PAGE> created:
<YEAR>-<MON>-<DAY>
</INTERNAL>
#SUB-TITLE ABOVE THE SUBJECT STATUS LIST (Part 1 of a standard external Query Report)
<STATUSLIST font="^P10 fB">
SUBJECT VISIT SCHEDULE: Note: *identifies subjects with data queries.
</STATUSLIST>
#SUB-TITLE ABOVE REFAX LIST (Part 2 of a standard external Query Report)
<REFAXLIST font="^P10 fB">
CRF CORRECTIONS: Initial and date each correction. Refax all corrected pages without delay.
</REFAXLIST>
# SUB-TITLE ABOVE THE QUESTION AND ANSWER LIST (Part 3 of a standard external Query Report)
<QALIST font="^P10 fB">
QUERIES: Print your response below each question and fax back this page.
</QALIST>

The file contains two optional sections, a script section and a style section. Both sections are optional. The script section contains an array, in JSON array notation, of colors for use in chart rendering. These values define the Palette picker. The style section contains CSS that is added to the head of the report output. This CSS can style the text and general appearance of reports.

<script type="application/json" id="dfreportjson">{
"palettes": {
    "Corporate": ["#26456e", "#3a87b7", "#b4d4da", "#1c5998", "#67add4", "#1c73b1", "#7bc8e2"],
    "Diverging" : ["#000066", "#6699ff", "#ffff00", "#3333ff", "#99ccff", "#ffff99", "#cc9900",
    "# 3366ff", "#ccccff", "#ffff66", "#663300"],
    "Monochrome": ["#1a1a1a", "#666666", "#b3b3b3", "#333333", "#808080", "#cccccc", "#4d4d4d",
    "#999999", "#e6e6e6"],
    "Color blind": ["#006ba4", "#ff800e", "#595959", "#5f9ed1", "#c85200", "#898989", "#a2c8ec",
    "#ffbc79", "#cfcfcf"]
}
}</script>
<style id="dfreportcss">
/* Body font */
body {
    font: 100% arial, sans-serif;
}
/* Title font */
.contextText.reportNameText {
    font: italic bold 1.5em Helvetica, serif;
}
/* Heading font */
.c3-title {
    font: 1.2em Helvetica, serif;
}
/* Axis label font */
.c3-axis-y-label, .c3-axis-x-label {
    font: normal 1.2em Helvetica, sans-serif;
}
</style>

A lookup table is a simple ASCII file. If it is anything other than this, an error message will appear on the command-line upon starting DFbatch.

Each lookup table file must be associated with a symbolic table name in the lookup table map in order to be used by the dflookup function or in DFexplore. The lookup table map is described in DFlut_map - lookup table map.

Within a lookup table, each record has at least 1 field. The first field is a short acronym (the search field), and the subsequent fields are the lookup text. If the record has only one field, it is the search and the result field (this is useful for spell checking). If the record has 2 fields, the first field is the search key and the second is the return value.

An example query lookup table with two fields is illustrated below.

miss|Please provide a response.
dtformat|Date format is YYYY/MM/DD. Please review and correct this date.
dtillegal|Date provided is illegal. Legal dates are 2016/01/01-today.
dtbeforeic|Date provided is before date of informed consent.
ongo|End date is provided, but Ongoing is checked. 
enddt|End date is prior to Start date. 

Records may also have 3+ fields (e.g COSTART tables, MedDRA), where the first field is the search key and all other fields are returned as a single delimited string that can be parsed using the dfgetfield function.

Within the lookup table structure, the search field is typically short but has no maximum length. The lookup text fields have no maximum length; however, they are truncated to the maximum length of the data field into which they are inserted.

Multi-field lookup tables can also support a more flexible structure as illustrated below.

#N:LL Term|Pref Term|SOC Term|LL Code
#L:Low Level Term|Preferred Term|System Organ Class|Low Level Code
#F:1|1-4
Abdomen enlarged|Abdominal distension|Gastrointestinal
disorders|10000045
Abdomen mimicking acute|Acute abdomen|Gastrointestinal
disorders|10000047
Abdominal cramp|Abdominal pain|Gastrointestinal disorders|10000056

These lookup tables contain 3 header rows which define the structure of the table.

If a lookup table is defined for a study data field, the defined lookup text can be retrieved in 2 ways. If the user remembers the acronym (first field) the lookup value can be entered by typing the acronym in the current data field and pressing Enter. The acronym is then replaced with the value from the matching lookup table record. Matching on the acronym is performed case-insensitive. Alternatively the user can simply press Enter without giving an acronym, to pop-up a scrolling list of all acronyms and their lookup text, and then click on the desired choice.

a|before
AA|auto accident (MVA)
A&P|anterior & posterior
abd|abdomen
abg|arterial blood gases
ac|before meals
acid phos|acid phosphatase
ACLF|adult congregate living facility
ACTH|adrenocorticotrophic hormone
acute MI|acute myocardial infarction
ad|right ear
Ad|up to
Ad lib|as desired
BaE|barium enema
Ba|barium
BB|blood bank
BCP|biochemical profile
BE|barium enema
BEE|basal energy expenditure

This file records the conditions defined in the conditional cycle map that were met for each subject. It is updated each time DF_QCupdate is run.

Table 2.62, “DFX_ccycle conditional cycle map conditions that were met” describes the data recorded for each of these conditions.

The following example shows 3 conditions (1,4 and 6), that were met for subject 11020. These conditions were met at visits 10,5 and 60 respectively, with data values 2, 98 and 0 respectively. To determine the actions triggered by these conditions we would need to consult the conditional cycle map to determine which cycles are affected by each condition.

11020|10|1|2
11020|5|4|98
11020|60|6|0

This file records the conditions defined in the conditional visit map that were met for each subject. It is updated each time DF_QCupdate is run.

Table 2.64, “DFX_cvisit conditional visit map conditions that were met” describes the data recorded for each of these conditions.

The following example shows 3 conditions (1,4 and 6), that were met for subject 11020. These conditions were met at visits 10,5 and 60 respectively, with data values 2, 98 and 0 respectively. To determine the actions triggered by these conditions we would need to consult the conditional visit map to determine which visits are affected by each condition.

11020|10|1|2
11020|5|4|98
11020|60|6|0

This file records the conditions defined in the conditional plate map that were met for each subject. It is updated each time DF_QCupdate is run.

Table 2.66, “DFX_cplate conditional plate map conditions that were met” describes the data recorded for each of these conditions.

The following example shows 3 conditions (1,4 and 6), that were met for subject 11020. These conditions were met at visits 10,5 and 60 respectively, with data values 2, 98 and 0 respectively. To determine the actions triggered by these conditions we would need to consult the conditional plate map to determine which plates are affected by each condition.

11020|10|1|2
11020|5|4|98
11020|60|6|0

This file records the conditions defined in the conditional termination map that were met for each subject. It is updated each time DF_QCupdate is run.

Table 2.68, “DFX_cterm conditional termination map conditions that were met” describes the data recorded for each of these conditions.

The following example shows 3 conditions (1,4 and 6), that were met for subject 11020. These conditions were met at visits 10,5 and 60 respectively, with data values 2, 98 and 0 respectively. To determine the actions triggered by these conditions we would need to consult the conditional termination map to determine which cycles are affected by each condition.

11020|10|1|2
11020|5|4|98
11020|60|6|0

This file records the key fields from all required plates found in the database. It is updated each time DF_XXkeys is run.

Table 2.70, “DFX_keys key fields from all required plates” describes the data recorded for each of these conditions.

The following example shows 4 records for subject 1044, for plates 3,2,1 and 2 respectively at visits 51,61,92 and 211 respectively. All plates have status 1=final and are at validation level 7.

1044|3|51|1|7
1044|2|61|1|7
1044|1|92|1|7
1044|2|211|1|7

This file records the current scheduling and status of all cycles and visits defined in the study visit map, for each subject. It is updated each time DF_QCupdate is run.

Table 2.72, “field definitions for cycle records in DFX_schedule” describes each field in the cycle records, and Table 2.73, “field definitions for visit records in DFX_schedule” describes each field in the visit records.

The following example shows the current status for one subject (id=1031) in a study having 3 cycle. The screening cycle consists of visits 91 and 92. The in-study cycle is required and has 8 visits beginning with pre-baseline visit 51 and ending with early termination visit 81. The end cycle contains a single abort visit (visit number 80).

1031|1|0|C|S|1|7||||||03/09/21|37884||
1031|1|0|91|X|1|7|||||||03/09/21|37884|||
1031|1|0|92|X|1|1|||||||03/09/28|37891|||
1031|1|1|C|R|1|7||||||~03/10/07|37900||
1031|1|1|51|P|1|7|||||||03/10/05|37898|03/10/05|37898|
1031|1|1|0|B|4|0|-1|10|51||||||||
1031|1|1|61|r|1|1|||||||04/01/06|37991|||
1031|1|1|3|S|2|1|||||||04/01/06|37991|||
1031|1|1|6|S|1|0|||||||04/04/07|38083|||
1031|1|1|9|S|1|0|||||||04/07/07|38174|||
1031|1|1|12|T|1|0|||||||04/10/06|38265|||
1031|1|1|81|E|3|0|||||||||||
1031|1|2|C|E|0|0||||||||||
1031|1|2|80|A|3|0|||||||||||

This file records the date and time each CRF page was processed from fax arrival to last record modification. It is updated each time DF_XXtime is run. A related file, named DFX_dfin, contains the same information as DFX_time1, for records that are still in the DFdiscover new queue. These records have not been validated and entered into the study database and thus may contain ICR errors in the key fields.

Table 2.75, “DFX_time1 timing data for each CRF page” describes the data recorded for each of these conditions.

The following example shows 4 records for subject ID 1501. The first 2 records are for plate 1 at visit 0, and the second 2 records are for plate 2 at visit 1. In both cases the first record is the primary and the second is a secondary record. In all 4 records the fax arrival date is missing. This will be the case if the record was not submitted by fax or email, but instead entered using raw data entry or ASCII record import, or if the fax_log is missing or has been trimmed.

1|1501|0|1|1|6|1995160154|03/30/95||95/04/24|95/04/24|34787|0|34812|34812||09:43:37|09:43:37|0|583.61|583.61
1|1501|0|1|4|4|1995130086|03/30/95||95/03/30|95/04/24|34787|0|34787|34812||18:41:04|09:43:43|0|1121.07|583.71
1|1501|1|2|1|6|1995200106|04/12/95||95/05/19|95/05/23|34800|0|34837|34841||16:46:37|11:12:18|0|1006.62|672.3
1|1501|1|2|5|5|1995160154|04/12/95||95/04/24|95/05/19|34800|0|34812|34837||09:43:59|16:46:39|0|583.98|1006.65

This file records the value of all dates in the database that use the VisitDate attribute. Only one date using the VisitDate attribute may appear on each CRF plate, but different plates for the same visit may contain VisitDate fields, and thus it is possible to have more than one record in for each visit for any given subject. A related file, named , records the preferred visit date for each visit, as defined in the study visit map. These 2 files are updated each time DF_XXkeys is run.

Table 2.77, “DFX_visit.dates the value of all dates using the VisitDate attribute” describes the data recorded for each visit date.

The following example shows 5 records for subject ID 1127, for visits 0,3,6,51. Note that there are 2 entries for visit 51, one from plate 10 and one from plate 13.

1127|0|03/08/19|37851|3
1127|3|03/11/20|37944|5
1127|6|04/02/18|38034|5
1127|51|03/08/10|37842|10
1127|51|03/08/10|37842|13