Table of Contents
DFdiscover includes 3 primary tools:
DFexplore for study data management,
DFsetup for creating new study databases, and
DFadmin for user and study administration.
This guide explains how to use DFsetup. This introduction covers DFdiscover study configuration components, describes the steps required to create a new study database, and provides suggestions for testing your study setup. The next chapter, Using DFsetup - An Overview, provides an overview with screenshots of the main dialogs. This is followed by a chapter, Defining Data Fields, that explains how to create modules and define fields within them, optionally get study CRFs into DFsetup and assign the data fields on each unique page. The remainder of the guide explains each of the study setup options, in a separate chapter for each of the main menus: File Menu, Field Menu, Study Menu and View Menu.
We start with a list of the components that make up a DFdiscover study database. Use this as a guide to identify the information needed before using DFsetup to create a new study.
CRFs |
Study case report forms (CRFs) must be designed in a word processing or graphics program, saved as a PDF file, and then imported into DFsetup where modules and data fields have been defined. The same CRFs used in a paper based study to record data and fax or scan it to a DFdiscover server, also appear in the screens used to enter data in DFexplore and send it to the server over the internet. This dual purpose means that data entry screens do not need to be programmed, and that sites can easily switch between submitting data via paper CRFs and electronically via DFexplore. It also means that CRF designers need to realize that they are simultaneously designing the paper CRFs and data entry screens for the study. For example, if a hidden data field is to appear (for specified users only) in DFexplore, white space must appear on the paper CRF where this field will be located. For a description of DFdiscover CRF design guidelines see CRF Design Guidelines. |
Plates |
In most studies some CRF pages are repeated at follow-up visits or on each occurrence of some event. In DFdiscover the term plate is used to refer to a unique CRF page consisting of a set of data fields and their layout on a CRF page. Each plate corresponds to a data entry screen in DFexplore and to a data table in the study database. When CRFs are imported into DFsetup (see Import CRFs), any title and instruction pages are typically discarded and one copy of each unique plate is preserved. The copy of each plate that is imported is used to define the data fields on that plate, and also as the background for that plate in DFexplore. If CRFs have different background types, such as translations, add the categories to the CRF Type Map before importing the CRFs. |
Key Fields |
Each CRF page must contain 3 key fields which together uniquely identify each data record in a DFdiscover study database.
|
Styles |
A style is one of the properties that must be specified for each data field. Styles include default specifications for all data field properties: type, name, description, legal values, coding, etc. Each of these properties may be locked in the style or left open so it can be changed at the field level. DFdiscover includes simple styles for each of the supported data types: check, choice, number, string, date, time and visual analog scale (VAS), and allow users to define study specific styles. Creating study specific styles with default and fixed property values is highly recommended because: it makes entering field definitions easier, ensures that fields which should have the same properties do, and makes it much easier to modify properties when the need arises. Styles are defined using the Styles dialog. See Styles for a complete description of styles and all data field properties. |
Modules |
Modules are a layer between plates and fields that allow grouping of fields. Each module has a unique name. Fields are defined within a module before mapping them to the plate layout. This work can be done before CRFs are imported. You can have as many modules as you like, but modules cannot contain other modules and fields cannot be part of more than one module. Modules can be used more than one time, even on different plates. Each instance of a module is assigned a module number that can be used to refer to a specific field on a plate with repeating modules. See Modules for a complete description. |
Data Fields |
DFdiscover supports the following data types:
For a description of DFdiscover data types and limits see Data Types, and for CRF design guidelines for each field type see CRF Design Guidelines. The properties of each data field are specified in the DFsetup Modules view. The location of each data field is specified in the DFsetup CRF window where the imported plates are displayed. A field is mapped to a plate by clicking its data entry boxes or dragging out a data entry widget to identify its location on the plate, and then selecting an unassigned field from a module. DFdiscover supports copy and paste of individual fields and field groups both within and across CRF plates, and allows style, module, and field definitions to be imported from other studies. See Defining Data Fields for instructions on defining modules and data fields. |
Visits |
Each study has different subject visit scheduling requirements. Some are simple with one series of visits from screening to a final follow-up for all subjects, while others have multiple visit cycles and conditions that determine whether a particular CRF page, visit, or cycle is required, that signal the end of one cycle and the beginning of another, or that mark the end of subject follow-up. A schedule comprised of all required and optional study visits and repeating forms along with all required and optional plates that may be collected at each visit must be specified for each study. This defines the subject binders used in DFexplore and also allows DFdiscover to create subject schedules and generate queries for overdue visits and missing pages. This user guide shows how to enter visit map specifications and explains all of the rules and describes all of the available options. To learn how to design a DFdiscover visit map see Subject Visit Scheduling. To learn how to enter your specifications see Visit Map. |
Sites |
Each participating clinical site responsible for subject recruitment and follow-up must be registered before data from that site can be entered into the study database. Each entry identifies the site ID and name, the contact person who will receive Query Reports, the subject ID numbers belonging to the site, and other optional specifications all of which are fully described in this guide at Sites. |
Edit checks |
Edit checks can be programmed to perform data consistency checks, use lookup tables, calculate total scores and unit conversions, generate queries, send someone an email message, log an event, etc. Edit checks are entered, checked and published using the Edit checks dialog described in Edit checks. A description of the DFdiscover edit check programming language is beyond the scope of this guide, but is fully described in Programmer Guide, Edit Checks Edit checks. |
Conditional Terminations |
Follow-up for some subjects may terminate early within one visit cycle or for all visits in all cycles, being signaled by some event recorded in a database field. Termination triggers are specified in the conditional termination map as described in Conditional Terminations. For a detailed explanation of conditional terminations see Subject Visit Scheduling. |
Conditional Cycles |
Some visit maps have more than one cycle of visits, each cycle being required, optional or conditional, and each starting with a new baseline visit. The conditions which make a cycle required, optional or unexpected are entered using the Conditional Cycles dialog as described in Conditional Cycles. For a detailed explanation of conditional cycles see Subject Visit Scheduling. |
Conditional Visits |
Each visit is defined as required or optional in the visit map, but this may be changed by rules specified in the conditional visit map using the Conditional Visits dialog as described in Conditional Visits. For a detailed explanation of conditional visits see Subject Visit Scheduling. |
Conditional Plates |
Each visit in the visit map may include a list of required and optional plates, but this may be changed by rules specified in the conditional plate map using the Conditional Plates dialog as described in Conditional Plates. For a detailed explanation of conditional plates see Subject Visit Scheduling. |
Page Map |
Each data record in a study database is uniquely identified by 3 keys: the subject ID, visit number, and plate number. Queries are further identified by 4th and 5th keys, the data field to which they are attached and the query category. When Query Reports are sent to the clinical sites queries are identified by these keys. The subject ID is meaningful and the field number is automatically replaced in the Query Reports by the field description so it too is meaningful. The visit and plate numbers may not be very meaningful to the sites and thus need to be replaced with descriptive labels. This can be done using the Page Map dialog as described in Page Map. In an EDC study, where the sites use DFexplore to enter data, a Page Map may not be required because DFexplore provides links between the queries and the relevant data fields which makes it easy for the site to review outstanding queries and jump to the relevant data fields to make corrections or enter an explanation. Page map labels also appear in DFexplore Data View where they replace the plate labels in the subject binder navigation list. In an EDC or paper-based study, where queries are sent to the sites in Query Reports, page map labels should be defined. |
Missing Map |
A list of missing value codes and labels can be specified using the Missing Map dialog as described in Missing Value Codes. Missing value codes may be applied to fields for which the 'need' property has been defined as optional or required, but can not be applied to fields defined as essential. |
Query Category Map |
DFdiscover includes a generic set of category codes for identifying queries and the problems that they identify. In most studies these are sufficient. However if more categories are needed, additional categories can be added with the Query Category Map dialog as described in Query Category Map. |
Sort Map |
In Query Reports, queries are always sorted in ascending order by subject ID. Within subject the default sort order is ascending by visit number, and within visit, ascending by plate number. But this within subject sort order can be changed using the Sort Map dialog as described in Sort Map. |
Lookup Tables |
Lookup tables are used in edit checks to retrieve information based on a specified string match. The name used to refer to each lookup table in edit checks, and the name of the lookup table file (stored on the DFdiscover server in the study lut directory) must be specified using the Lookup Tables Map dialog as described in Lookup Tables Map. DFsetup also includes a lookup table editor which can be used to add, modify and delete entries in each of the study lookup tables, as described in Lookup Tables. For a explanation of how lookup tables are used in edit checks see Programmer Guide, Edit Checks Edit checks. |
Query Titles |
The titles used in the standard DFdiscover Query Reports created by DF_QCreports can be customized using the Query Titles dialog as described in Query Titles. |
Query Covers |
A cover sheet can be included with each Query Report created by DF_QCreports. Different cover sheets can be specified for different clinical sites. Query Report cover sheets are entered using the Query Covers dialog as described in Query Covers. |
Query Messages |
Messages can be included at the bottom of Query Report cover sheets. Different messages can be specified for different clinical sites. Query Report messages are entered using the Query Messages dialog as described in Query Messages. |
Users interested in a level of detail that includes the underlying file formats for storing study setup specifications can consult Programmer Guide, Study FilesDFdiscover Study Files.
This section describes the steps needed to create a new study database, identifies dependencies between setup components, offers tips to help you avoid problems and make the process as efficient as possible, and describes what can and cannot be changed once a study is in production.
Study Setup Steps
Before anything can be done in DFsetup a DFdiscover administrator using DFadmin must:
register the study on the DFdiscover server specifying: a unique study number, a study name and a study home directory.
create at least one study role with permission to use DFsetup
grant this role to at least one user
These steps are described in DFadmin System Administrator Guide, StudyAddingAdding a New Study.
This step is optional. Study CRFs are not required for studies where there is no analogous paper CRF. In such studies, eCRFs are defined directly with DFsetup.
Study CRFs must be created in a word processing or graphics package, barcoded (if DFdiscover will receive faxed or scanned CRFs), and saved in PDF format for import into DFsetup. The CRFs are used to create the data entry screens used in DFexplore For CRF design guidelines see CRF Design Guidelines.
A visit map must be created for each study. The sequence of subject visits and repeating forms and the plates used at each visit define the subject CRF binders that appear in DFexplore and thus data entry cannot be performed until a visit map has been specified. The visit map refers to the visit and plate key fields that appear on each CRF page, thus CRF design and Visit Map design should go hand in hand. For a complete description of visit map components and rules see Subject Visit Scheduling.
The DFsetup program is available for Windows 8/10, OS X v10.11 or later, and Linux, and can be used by anyone with permission to connect to the DFdiscover server where all study setup information is stored. What a user can do in DFsetup is determined by the permissions granted to their study role by a study administrator, using DFadmin. Some users may have view only permission, others may be able to define and modify specific setup components, and others may have full permission for all components.
More than one user can access a study in DFsetup at a time but only one user at a time can edit each of the setup components. While one user has a configuration file open and locked, other users can open it in view only mode.
Users can choose to login in view only mode, or to edit configuration files only - without being able to change data fields. By selecting the minimum access mode necessary to accomplish the task at hand users can leave locks free for other users who may need them. Thus, an understanding of how DFsetup permissions and locking work will help you cooperate with other users who share study setup responsibilities (see Access Modes).
Global study specifications can be changed at any time, but should be set as one of the first things you do in DFsetup when defining a new study, because they include default values that have an impact on the definition of styles and data fields.
See Global Settings.
Modules are groups of fields. Before fields can be mapped to a CRF they must be defined within a module. Modules should contain variables that logically go together. For example, when recording adverse events all variables that are used to describe an event should be included in a module. If there is more than one event on the page, each event is an instance of a module.
See Modules.
Once modules are defined, plates are created. The definition and layout of a plate can be based upon a paper CRF, or an eCRF.
For a paper CRF, a blank copy of each CRF plate must be imported. Plates can be imported individually or many plates can be imported at one time. Title and instruction pages can be discarded during import and users can select which plates to import and which to discard. It is possible to import a revised version of a CRF plate to replace an old one.
The file to be imported must be a PDF and reside on the user's local computer. You can also import CRFs from the DFdiscover server if you have access to the file system where the CRF file is stored.
See Import CRFs.
For an eCRF, there is no blank copy to import. Simply choose > and assign a plate number.
If a plate already exists in another study all of the style and module definitions can be imported from that study. The import is just a copy that can then be modified in the new study. Before defining new data modules you should always consider whether it is possible to reuse work that has already been performed in another study.
You might also want to consider creating a special DFdiscover database to store predefined versions of frequently used modules or plates. Such a CRF Library database can provide one standard location where such modules or plates can be registered and tested, and where any necessary modifications can be maintained over time.
See Import Definitions.
Use this dialog to enter a descriptive label and other plate properties for each unique plate in the study. If plate definitions have been imported from another study the plate descriptive label and plate properties will be imported as well, and can then be modified in the Plates dialog if necessary.
See Plates.
Every data field definition begins with the selection of a style that specifies the data type (number, string, date, check, choice and VAS) and other properties. These properties can be locked in the style so they cannot be modified at the field level, or left as default values which can be over-ridden when a field is defined.
DFdiscover includes a number of Simple styles that should be reviewed and modified as needed for the study at hand. For example the SimpleDate style's format and legal range should always be modified as appropriate for the study.
You should also review the CRFs and decide what study specific styles are needed. Common examples include:
a YesNo style used to lock the coding for data fields consisting of Yes / No choice options.
a StudyDate style used to lock the format and legal range for events occurring after the study start date.
a SubjectID style used to lock all properties of the subject identification field that appears on each CRF page.
Time spent creating a complete set of styles will both simplify data field definitions and ensure that properties that should be consistent across a set of data fields cannot be entered incorrectly when defining individual fields.
See Styles.
It may be helpful to create annotated CRFs before beginning to define data fields. One version of the CRFs might be annotated with field numbers and style names, while another might be used for field level properties like field names.
If you do this remember to number the visit key field as field 6 if it is not in the barcode, and that subject ID must be field 7 on every CRF plate. DFdiscover includes 3 header fields you do not need to define: status, workflow level, and primary image, and 2 which must be in the barcode: study number and plate number, so the first 5 fields are always predefined.
The definition of a data field requires:
first locating the field on the CRF page,
then selecting the appropriate module and field.
This process must be repeated for each data field on each plate, but copy and paste can be used to reduce some of the effort. For example, the subject ID field must appear at the top of every CRF plate, and in some studies this is always followed by subject initials and the visit date. Such common fields can be defined on the first plate and then copied and pasted on all other plates.
Some CRF plates may be comprised of a repeating blocks of fields, e.g. allowing data on several medications or medical history items to be recorded on the same page. Here too copy and past can reduce the effort.
See Defining Data Fields.
Each clinical site that contributes subject data must be registered using the Sites dialog. A site will not appear in DFexplore and thus data entry cannot be performed for that site until it has been registered.
The required fields for each site include:
a unique site ID in the range 0-21460
name of the site coordinator or chief contact person
name of the clinic, hospital or institution
fax number(s) and/or email address(es) to which Query Reports are sent
list of subject ID numbers and ranges used by the site
All other site properties are optional but a "Replyto" email address is highly recommended if Query Reports will be emailed to the clinical sites.
The site properties, including the subject IDs that belong to a site, can be changed at any time during the study. If a subject ID is moved from one site to another (e.g. because the subject moved) all subject data and metadata records will appear under the new site in DFexplore and any outstanding queries will be included in the next Query Report sent to the new site.
See Sites.
The visit map determines how subject binders are organized and displayed in DFexplore and thus data entry cannot begin for any subject until a visit map has been specified.
The visit map includes all scheduled and unscheduled subject visits and repeating forms, when they are due and overdue, and which CRF pages are required and optional for each visit. In addition, conditional terminations, cycles, visits and plates may be specified in the corresponding conditional maps. Visit scheduling can be very simple or quite complicated and DFdiscover supports many options to handle the needs of different studies.
CRF and visit map design should be completed together and particular attention should be paid to the selection of visit and plate numbering. While a visit map can always be modified during a study to add visits or plates, changing the numbering of the plate and visit key fields is not possible as this would conflict with data and audit trail records that have already been created.
DF_QCupdate uses the visit and conditional maps to identify overdue, missing and unexpected visits and pages, thus this function also depends on these specifications.
It is not uncommon for changes to be made in the visit and conditional map specifications after a study has started. The new rules will be applied the next time DF_QCupdate is run, and queries for overdue visits and missing pages that are no longer relevant will be removed.
See Subject Visit Scheduling for information on designing a visit map and any required conditional maps, and the following sections for information on how to enter your specifications:
Documentation on DF_QCupdate can be found in Standard Reports Guide, DF_QCupdate.
The page map is an optional configuration file used to enter labels for the plate and visit numbers associated with each query on the Query Reports sent to the clinical sites. The page map can also be used to configure plate labels based on the visit number as displayed in the subject binder in DFexplore.
In an EDC study where the sites use DFexplore to enter data and respond to queries and Query Reports are not used, a page map is not necessary, but in a paper based study where Query Reports will be delivered by fax or email, the page map should be completed before the first Query Report is sent.
See Page Map.
The missing value map is an optional configuration file, used to register study sanctioned missing value codes and labels. In DFexplore these codes can be assigned to any optional or required data field, and can be thought of as pre-approved reasons for missing data. Data fields defined as 'essential' do not accept missing value codes.
If the missing values configuration file does not exist for a study DFexplore uses '*' as the one and only default missing value code. If the missing values configuration file exists but is empty then no missing value codes are allowed for any data field in the study.
New missing value codes can be added during a study but you should not remove or reassign missing value codes that are in use, otherwise you could render some data fields uninterpretable, and invalid. There is no harm in updating the label on existing missing value codes to correct mistakes or poor wording, as long as you do not change the meaning. It is only the code that is stored in the study database. Thus any change in the label will apply to both past and future use of that missing value code.
See Missing Value Codes.
Edit checks are optional but extremely useful. They can be programmed and tested as soon as the data fields have been defined on the relevant plates. They can be added and modified as needed during a study.
See Edit checks for a description of the DFsetup edit check editor.
Lookup tables are optional. They can be defined for standard queries and reasons, and for use in edit checks. They can be modified as needed during a study.
See Lookup Tables for information on how to create lookup tables, and Lookup Tables Map to register lookup tables for use in edit checks.
DFdiscover provides a basic set of query categories that can be assigned to queries. The optional query category map can be defined to extend the available categories, providing different criteria, perhaps study specific, to identify and group queries.
The sort map is an optional file used by DF_QCreports to determine the order in which queries are displayed on Query Reports. It is not used by DFexplore. It can be changed at any time and will only affect subsequent Query Reports.
See Sort Map.
The titles used on the standard Query Reports created by DF_QCreports can be customized and cover sheets and messages can be added and customized for different clinical sites. This is of course optional and can be added or changed at any time during the study.
See
Each study setup should be tested before it is put into production for data collection. This section provides some suggestions on what to test and when.
Plate Testing
Plate testing can begin as soon as the first plate is defined. Testing each plate after it is defined may detect problems to be corrected and avoided in the remaining study plates.
The first three tests below are performed in DFsetup, while the remaining tests are done in DFexplore. Before plate testing can begin in DFexplore, the visit map must be defined with at least one visit with the plate to be tested (see Visit Map), and the Sites definition must include at least one test site (see Sites).
Field Order
Examine the field number of each data entry widget to verify that they are in the desired order. If the visit number is a defined field on the plate (rather than included in the barcode or predefined in the visit map), it will be field number 6 and the subject ID will be field number 7. If the subject ID is field number 6, the plate property Sequence is not set correctly. Correct it using the Plates dialog as described in Plates.
In DFsetup switch from CRF View to Field List View using the button at the bottom of the screen. Scan down the columns to review the same property quickly across all fields on the plate. In addition to spotting field level problems, this may also suggest changes needed to the styles or module fields.
Verify All
Select > in DFsetup to run all of the DFdiscover study setup integrity-check reports. These reports can also be run individually in the DFexplore Reports view. For more information select > in DFexplore, select each report that begins with 'DF_IC' and click . See Standard Reports Guide, Alphabetical Listing, Legacy Reports for further details on these reports.
Open the plate in DFexplore and examine the color-coding of all blank fields. Optional fields should be yellow, and required and essential fields should be red. This step might identify fields that have been misclassified.
Starting with the first field, tab through each field on the plate to confirm that the cursor moves through the fields in the expected order and that any skip specifications work as expected.
Essential fields are required for a data record to be saved; neither a blank value nor a missing value code is acceptable. The visit and subject ID key fields fall in this category. Confirm in the bottom left corner of the screen is inactive for all essential fields.
Verify that all missing value codes needed for the study appear in the list.
Data Values
Test each field by entering both legal and illegal values. Fields turn white on entering a legal value and red on entering an illegal value. This might identify changes needed to the legal value property of styles or fields, and will also allow verification that each field has the correct format and length.
If edit checks have been defined, enter test values to verify edit check behavior. A separate test plan is recommended for each edit check, comprised of as many test cases as required to test each combination of data values that is expected to produce different edit check behavior.
If data will be collected on paper CRFs, submit a few example pages to test intelligent character recognition (ICR). Numbers, dates, choice fields, check boxes, and visual analog scales should be read correctly, provided the fields are legible. ICR errors may be due to unusual or unclear handwriting, but consistent ICR errors when the values look readable may indicate a problem with CRF design, the legal range specifications, or the location of data entry widgets in DFsetup.
Visit Schedule Testing
The visit map defines the subject binders used by DFexplore. All visits and plates must be included in the visit map in order to appear in DFexplore.
This report looks for problems in the visit map, conditional maps, and VisitDate fields. It can be run from the DFexplore Reports View or by selecting on the Visit Map dialog.
Enter one or more test cases in DFexplore for each condition specified in each of the conditional maps. Then run DF_QCupdate to apply the conditional rules. Check for overdue visit and missing plate queries using the DFexplore Query View, and check for unexpected visits and plates by running the DF_PTunexpected report. The DF_PTvisits report lists the status of all cycles and visits for each subject.
Query Report Testing
Query Titles, Covers, and Messages
Test these specifications by running DF_QCreports to create a Query Report for each site and then using DF_QCview to review each report. If different sites have different cover sheets specified, include test cases for each site. Note that a Query Report is only created for sites that have enrolled study subjects.
The standard subject schedule section of Query Reports includes the
date of enrollment, last follow-up and next scheduled follow-up.
Enter test cases, then run DF_QCupdate to update DFX_schedule.
Then create and review Query Reports to see if the expected scheduling
is reported.
Run DF_PTvisits to examine the entire visit schedule for each subject, including the dates of all completed and scheduled visits. This report also provides information on conditional events and terminations and is a good way to test different subject follow-up scenarios.
Test the labels specified for visit/plate combinations by reviewing the subject binder labels in DFexplore or by adding an unresolved query to the data record, running DF_QCreports and then DF_QCview to examine the query labels.
If the sort map is defined to reorder queries within a subject, examine the query order on Query Reports to confirm they are sorted correctly. Without a sort map the default order is by plate number within visit number (both ascending).
Query Reports come in 2 different formats depending on whether field descriptions are specified as short (25 character) or long (40 character) in the Study Global settings dialog. Short descriptions result in a more compact report.
Changing the global setting and rerunning DF_QCreports will show the difference. See Global Settings for further information on this setting.