Description

Present detailed information of the plates and fields that define the study database. The presented information is a combination of visual plate layout, together with tabular information of the plate and field properties.

The visual presentation is linked in many places to facilitate easy navigation between plate, module and field level properties. information.

In the plate layout, each individual field is displayed in it's default on-screen position. Fields are grouped by layout to display module information. Fields belonging to the same module also share the same color.

Clicking in the background area of any plate updates the tabular information to display the values of each plate level property. Clicking any field updates the tabular listing to display the values of each field level property. Clicking in the background area bounded by a module layout area updates the display to a tabular listing of all instances of that specific module.

Navigation controls to navigate between plates are available via the Previous and Next controls or by selecting a plate from Go To Table View.

Options

None.

Description

Report enrollment numbers on per site, or per country, basis. Enrollment numbers are aggregated on a monthly interval. Enrollment numbers are graphed by summing the monthly interval values.

By default, subjects are deemed to be enrolled if the plate containing the visit date for the baseline visit is present in the database. These visit and plate defaults can be changed via report options.

Options

Description

Report the volume of new data entering the database over time, categorized by data source, either CRF or EDC. The time interval can be one of week, quarter or year. Quarter is an approximation: weeks 1 through 13, inclusive, are quarter 1, weeks 14 through 26 are quarter 2, weeks 27 through 38 are quarter 3 and weeks 39 through 52 are quarter 4.

Volume is displayed as volume for the interval, as well as accumulated volume since start.

Options

None.

Description

Display simple counts and statistics for all fields on the requested plate. This report is similar to DF_stats - the underlying data is the same but the presentation style is different.

The first part of the output is a summary table. Each data field is a row in the output table. The properties of each data field are presented in columns of the table. For each data field, the first 3 columns are properties defined by the database setup:

The remaining columns contain derived / calculated results summarizing the data values in the database. These results include:

The second part of the output is a simple chart view of the values meeting each of the data criteria. The length of each row in the output is the same as the Total value for the matching row in the table.

Options

Description

This report provides a detailed listing of which required CRFs are missing, which scheduled visits are overdue, and which queries are unresolved and outstanding. It has the same purpose as Schedule View in DFexplore and the DF_QCreports legacy report.

The output is split into 3 sections: the subject schedule, correction queries and clarification queries. The subject schedule is presented for each subject with at least one CRF in the database, unless one of the -site # or -id # options is also specified. If -internal is set, any queries identified as being for internal use are included in the correction and clarification queries lists.

Unlike DF_QCupdate, this report does not insert missing page and overdue visit queries in the database. Instead it generates an up-to-date list each time that the report is run.

Options

See Also

Description

This report applies the visit scheduling and CRF page requirement rules to determine which required CRFs are missing and which scheduled visits are overdue. It has the same purpose as Schedule View in DFexplore and the DF_QCupdate legacy report.

The output lists each required CRF that is missing and each scheduled visit that is overdue. If the determination is influenced by a condition other than the study visitmap, the condition(s) are identified in the last 3 columns.

Unlike DF_QCupdate, this report does not insert missing page and overdue visit queries in the database. Instead it generates an up-to-date list each time that the report is run.

Options

See Also

Description

DFdiscover maintains a change history of every data value or metadata value that is added/modified/deleted during the course of the study. This report outputs the change history in tabular format, for one specific subject ID. The output includes:

By default, all data and metadata changes are reported. To view only the changes to data, queries or reasons, select the desired view using Change Records in the Options drawer.

The report output can be quite lengthy if there are many data points collected per subject. To further filter the output, include only a specific visit (-visit #), plate (-plate #) or field (-field #). The filters are typically nested so that a specific visit can included (-visit #), a specific plate within a specific visit (-visit # -plate #), or a specific field of a specific plate of a specific visit (-visit # -plate # -field #). However, it is also possible to view the change history for a specific field across the entire database, as well as other combinations of options.

It is possible to search the output by selecting the field of interest in the Search by dropdown list and then specifying the value to search for. Each column can be sorted in ascending or descending order by clicking the column heading. Each click reverses the previous sort order.

This report is similar in behavior to Plate > List History of All Changes on this Page (use -plate #) or Field > List History of All Changes on this Field (use -field #) available in other views.

Options

See Also

Description

This report lists a summary of the subject schedule. The summary includes for each permitted subject ID:

If the next visit is overdue, and there are outstanding queries, the overdue visit status is prioritized for display.

Any row in the tabular output can be clicked to present the detailed scheduling information for that particular subject ID. This detail includes the kwown visit schedule for the subject and includes the schedule date and status (incomplete, final, overdue and/or days off-schedule) for each visit (calculated from the available visit dates and the visitmap), and the actual dates of visits that have been received.

It is possible to search the output by selecting the field of interest in the Search by dropdown list and then specifying the value to search for. Each column can be sorted in ascending or descending order by clicking the column heading. Each click reverses the previous sort order.

Options

See Also

Description

This report lists unexpected visits and plates found in the study data. It is possible to filter the listing to include only a specific site or specific subject ID; by default, all unexpected visits and plates for permitted data are reported.

Visits are unexpected when:

Plates are unexpected when:

The tabular output includes:

It is possible to search the output by selecting the field of interest in the Search by dropdown list and then specifying the value to search for. Each column can be sorted in ascending or descending order by clicking the column heading. Each click reverses the previous sort order.

Options

See Also

Description

Present a tabular listing of detailed site information. The listing is a read-only presentation of site details defined in DFsetup.

The detailed site information is grouped for display purposes into:

If basic site information is included in the display, it is possible to search for specific site ID, Name, or Subject. When searching by subject, the search will search inside subject ID ranges.

Options

None.

Description

Report and graph workflow statistics for time to receive data, enter data and save data as final. Statistics are grouped by site, or optionally by county.

An optional view, Time to Final, is available that presents the percentage of records that have final status on arrival (did not require further editing or clarification) and the percentage of records that have final status now.

Detailed numeric values for any site, or any country, can be obtained by clicking on the corresponding chart entry.

Options

None.

Description

Report summary information about queries metadata in the database. Summary information can be reported by site (default) or country. Summary information is presented in chart and table form. Information is similar to results produced by DF_CTqcs.

Summary information is presented in 4 different views:

Options

None.

Description

Report the number of visits, by visit number, that have occurred at each site.

A visit is deemed to have occurred if there is at least one plate in the database with that visit number. The results are similar to the results produced by DF_CTvisits.

Options

None.

Description

Report summary information about the database status, summing over workflow level and grouping by the status of records, queries and reasons.

The summary information is similar to the information available in DFexplore via View > Status.

Options

Description

Tabulate and graph the number of queries, of each category, for each field in the database. The report purpose and numeric values are the same as the legacy report DF_qcsbyfield - the presentation however is different.

The output includes each data field that has at least one query. By default, output is sorted by increasing plate number, and field number within plate. Fields which have no queries are not presented.

Choosing Sort by Total produces output ordered by the most frequently queried data fields.

Note that missing plate and overdue visit queries are always attributed to the subject ID field on a plate.

Options

None.

Description

The study number and key fields (ID, visit, plate) associated with a CRF page may change over time, because the key fields were entered incorrectly and later fixed, or because the CRF page was moved to a different study. DF_ATcrfs tracks these changes by searching the audit trail of the current study, or optionally all studies registered in DFdiscover, for all journal records related to a specified CRF page. If the option to search all studies is enabled, all known studies are searched, whether the study is currently active or not.

For each journal record identified, DF_ATcrfs displays:

In addition to showing the above information from the journal files, DF_ATcrfs also checks the router and prints a message at the end of the report indicating that the CRF page is currently located in the router, if that is the case. A CRF page will be placed in the router on arrival if the barcode could not be read. It will also be moved to the router from a study database if Change Keys (in DFexplore) is used to change the study number. When this happens the data record and any metadata records (queries and/or reasons) are deleted from the original study database, and the CRF image starts over when it is routed to the new study database.

Options

Examples

DF_ATcrfs: Track keys associated with a CRF page over time.   Jul 28,2015 13:04

Keys history for CRF page 1525/0016001
yyyy/mm/dd hh:mm:ss DBN  study         id visit plate  level status user
2015/06/21 14:25:59 253    253       1019     0     1      0 new    datafax
2015/06/21 14:49:51 253    253       1019     0     1      1 final  user1
2015/07/28 13:02:17 253    253       1019     0     1      2 delete user2
2015/07/28 13:03:28 252    252       1019     0     1      0 new    datafax
2015/07/28 13:04:16 252    252       1019     0     1      1 final  user2

Limitations

DF_ATcrfs is really an administrative report and for maximum benefit should be restricted to user datafax.

See Also

Description

DF_ATfaxes displays the validation history of each page in selected documents. The output includes:

Document arrival dates can be specified in either yy/mm/dd or format. If the former is used, the study start date (recorded in DFschema) is used as the pivot year for date imputation. A single date may be specified to select documents received on that date, or a date range may be specified to select documents received between the two dates, inclusive.

Documents may also be selected by document name using -f, such as -f 1805/0012 which selects the 12^th document received in the 5^th week of 2018, and -f 1752/0001 selects the 1^st document received in the 52^nd week of the year 2017. Every document received by DFdiscover is given a unique name, composed from the year, week, and document number. Pages entered by EDC data entry also use this naming scheme, thus gaps may appear in the document names retrieved from fax_log.

When -f is used only one document name may be specified, but the match is performed anywhere in the document name, thus -f 1805 will match all documents received in the 5^th week of 2018 (and the 1805^th document received each week, if any), and -f 1805/004 will match image numbers 0040 through 0049 of the 5^th week of 2018. Be aware that a pattern like -f 0001 will match all documents received in the first week of 2000 and all first documents received in any week.

Fax machines include a sender ID, if programmed by the sending site, which identifies the fax machine that sent the fax. For emailed documents, the sender ID is the sender's email address. For documents sent with DFsend, the username of the sender is the sender ID. This is stored in the fax_log and can be used to select documents. If the sender ID includes spaces it must be enclosed within double quotes, e.g. -s "555 111 1234". The match on sender ID is performed anywhere in the sender ID string. Thus -s 555 will also match this sender, as well as any other sender with 555 anywhere in the sender ID.

The -j option is used to display journal entries for all CRF pages in the selected documents, but only those documents that contained CRFs for the current study will be in the study journals, thus only these documents will be displayed when -j is used. Output can include all or selected journal entries. Any combination of the selectors 0, 1, 2, and 3 can be specified with -j. Use:

For example:

When -j is not used, the document name, number of pages in the document, arrival date, time and sender ID are displayed for the selected documents from the fax_log, and will include documents from all DFdiscover studies being conducted.

When -j is used, the status of each journal entry is coded as a single letter key, from the following legend:

Primary Records:   f=final, i=incomplete, p=pending
Deleted Records:   -=deleted

The status is followed by the validation level, where 0 represents the ICR step.

Options

Examples

-t 980116

Reading fax log
DF_ATfaxes: Audit trail for documents.  DFstudy 7.  Feb 10,2018 23:03         PAGE 1

document 1803/0024  pages 1     2018/01/16 00:01:34  sender: 61 3 93422947
document 1803/0025  pages 7     2018/01/16 09:35:45  sender: 215 402 9234
document 1803/0026  pages 1     2018/01/16 10:18:16  sender: 905 546 1231
document 1803/0027  pages 3     2018/01/16 10:46:59  sender: 715 387 7317

-f 9803/0027 -j 0123

Reading fax log
Reading journals
DF_ATfaxes: Audit trail for documents.  DFstudy 7.  Feb 10,2018 23:04         PAGE 1

document 1803/0027  page 1/3    2018/01/16 10:46:59  sender: 715 387 7317
     65565     4   7    0  2018/01/16 10:49:40  
     65565     4   7   i1  2018/01/16 12:41:55  jack                 (1)
     65565     4   7   f2  2018/01/16 15:43:37  jane                 (2)
     65565     4   7   f3  2018/01/18 11:52:49  mary                 (3)

document 1803/0027  page 2/3    2018/01/16 10:46:59  sender: 715 387 7317
     65565     4   8    0  2018/01/16 10:49:40  
     65565     4   8   i1  2018/01/16 12:42:02  jack                 (4)
     65565     4   8   f2  2018/01/16 15:43:06  jane                 (5)
     65565     4   8   f3  2018/01/18 11:52:43  mary                 (6)

document 1803/0027  page 3/3    2018/01/16 10:46:59  sender: 715 387 7317
     65565     4  14    0  2018/01/16 10:49:40  
     65565     4  14   i1  2018/01/16 12:42:07  jack                 (7)
     65565     4  14   i2  2018/01/16 15:45:41  jane                 (8)
     65565     4  14   -3  2018/01/18 11:53:24  mary                 (9)

See Also

Description

DF_ATmods creates an audit trail report showing modifications (additions, changes, and deletions) made to data fields, queries and reasons over time.

A full trace of all changes made to a study database can generate thousands of pages of output. Using the available options to limit the report to show only those changes made during a short time period, or by specified users, or to data for specified subjects, visits and plates, is highly recommended.

The report's format is illustrated in the following example output:

DF_ATmods: Database Changes For Study 253  Jul 25,2016 16:56           PAGE 1 (1)
           -din 8-22 -N data -t 20160725 -I 1003 -P 2  (2)

--------------------------------------------------------------------------------
ID=1003  SEQ=1  PLT=2   (3)
2016/07/25 13:52:55 jack          DATA: NEW RECORD at level 1, incomplete   (4)
  8. Patient Initials = CCC
     REASON new at level 1: Set by edit check SetInitials
  9. Entry Date = 03/07/06
 10. Does pt. meet eligibility = 2 (Yes)
 11. Eligibility: Explain = blank
 12. Medication Code # = 2543
 13. Date of Birth = 15/06/44
 14. Weight in kg = 075.3
     REASON new at level 1: Set by edit check CalcWeight
 15. Weight in lbs = 166.0
 16. Height in cm = blank
 17. Height in in = blank
     Query new at level 1: external, missing, status = new
 18. Pulse beats/minute = 062
 19. Smoking Status = 1 (Never smoked)
 20. Exercise = 2 (1-2 times/week)
 21. Date of First Follow-up = blank
     REASON new at level 1: a date was not set, patient will call back to make
     an appointment
 22. DFdiscover Screen Status = 2 (incomplete)

2016/07/25 14:53:21 susan         DATA: MODIFIED at level 1, final   (5)
 16. Height in cm: blank -> 180
     REASON new at level 1: Set by edit check CalcHeight
 17. Height in in: blank -> 071.0
     Query modified at level 1: external, missing, status = resolved corrected
     Query Status: 1 (new) -> 5 (resolved corrected)
 21. Date of First Follow-up: blank -> 03/08/06
     REASON modified at level 1: a date was not set, patient will call back to
     make an appointment -> appointment date has been set.

2016/07/25 16:43:51 bill          DATA: NO CHANGE   (6)
 21. Date of First Follow-up:
     REASON approved at level 1: a date was not set, patient will call back to 
     make an appointment

Options

Examples

The examples demonstrate how different combinations of options can be used to filter the audit trail information for particular purposes.

-d new,mod -q new,mod -t 20171201~today

-u jane -t 20151201~20151224 -d none -q mod,ex

-v 6 -d mod -q none

-t today -w 080000~090000

-t 20150101~20151231 -d none -q mod,ex -qin 15~18,22

-t 20150101~20151231 -d none -q new,mod,ex -qin 15~18,22 -N qcs

-v 4~7 -t 20150701~today

-f 6 -u jane -t 20150101~today

See Also

Description

DF_CTcrfs reports a summary of the time required for database processing of records received, during a specified time period, from each study site including the error monitor site. Time periods can be selected:

Only visits and plates defined in the study visit map are included in this report.

The tabular report displays for each site (row) columns that contain:

Options

Limitations

Only visits & plates defined in the visit map are included.  This report focuses on time since each subject visit and thus only includes visits and plates that are defined in the study visit map. Both required and optional plates defined for each visit (or sequence) number are included.

Only records with valid dates are used in the time calculations.  The denominator for the mean time between visit and image arrival requires both a visit date and a image arrival date. If either is unavailable that record will not be included in the calculation of the mean. If the site has no subjects with usable visit dates, N/A is output for the DB Entry and DB Clean columns. Similarly, if none of the CRFs for the current site can be found in /opt/dfdiscover/work/fax_log, N/A is output for the Fax In column.

See Also

Description

DF_CTpages reports the number of data records in the database that arrived within a specified time window (i.e., between 2 dates). The document arrival date is represented by the arrival date stored in the DFdiscover faxlog file. If an arrival date is not available, the record creation date is used. This should only apply to EDC data entered records and records that have been imported (using DFimport.rpc) without a matching image in the faxlog, but could also be applied if the faxlog is incomplete.

DF_CTpages gets its information from the DFdiscover timing summary files and DFX_dfin. If necessary, DF_CTpages first executes DF_XXtime to update these 2 files.

The output from DF_CTpages includes 6 columns of data: 3 for primary records (final, incomplete, pending), 1 for all secondary records, 1 for returned Query Reports (plate 501), and 1 for the total number of records present in the previous 5 columns. Missed records are not counted, because they simply identify pages that did not arrive and are no longer expected to arrive.

New records, which have not yet been entered into the database, and records sitting in the router are not included in the report, because the record keys (ID, visit and plate numbers) and site ID have not yet been verified and are thus not known with certainty. However, DF_CTpages does print warning messages at the bottom of the report if any records are found in the new record queue and/or in the router that arrived during the specified time interval. Since the record keys and site ID are not known with certainty, any related filter options are not applied when counting these records.

Options

Limitations

See Also

Description

DF_CTqcs reports a summary of the user-created, external queries added during data validation. queries are selected by their creation date from a specified time period that may include one of:

The following queries are not included in the report:

The summary is in the form of two tabular reports. The first report displays for each site (row), columns that contain:

        TOTAL    TOTAL    RATE/  RESOLVED QRYS  STATUS & TIME TO RESOLUTION
  SITE  RECORDS  QRYS    100 REC    #     %     Correct   N.A.   Irrel.  DAYS  Pending
        (1)      (2)     (3)      (4)            (5)                      (6)   (7)

The second table displays for each site (row), columns that contain:

           AGE (DAYS) NEW/UNSENT QUERIES(1)   AGE (DAYS) SENT/UNRESOLVED QUERIES(2)
  SITE    00-10  11-20  21-30  31-60  > 60     00-10  11-20  21-30  31-60  > 60

An alternative report format can be requested with -a. This report format is a single table that is a hybrid of the two, already described, tables. Rather than displaying the status of resolved queries from the first table, the hybrid report displays the age of unresolved queries from the second table, so that the column headings read:

        TOTAL    TOTAL   RATE/   RESOLVED QRYS  AGE (DAYS) OF UNRESOLVED QRYS
  SITE  RECORDS  QRYS   100 REC     #     %     <=10 11-20 21-30 31-60   >60

DF_CTqcs uses summary file which is created by DF_XXtime. DF_CTqcs checks the summary file DFX_time1 against the study database and sites database to see if either database has changed since the file was last created. If either or both databases have changed, DF_XXtime is executed to rebuild DFX_time1, otherwise this step is skipped. If DF_CTqcs is run with the option -x, the results will reflect the state of the database on the last time that DF_XXtime was run.

If subject IDs exist in the database which do not correspond to any of the sites in the sites database, they are assigned to the ERROR MONITOR. By default, DF_CTqcs includes such subjects when making this report. If -v (for verbose mode) is used, such cases will be listed at the end of the report.

Note

The count of primary records and queries created during the specified time period are not necessarily related, as some or all of the selected queries may have been added to previously created records (which would not be selected). Thus this report may reflect both coordinating site activity as well as site performance. An increase in querying by data staff could make it appear that CRF problems are rising when it is really just an increase in the search for problems. Also an increased focus on some sites could make the quality of CRFs arriving from those sites appear worse than that from sites under less scrutiny. However under most circumstances the relative number of queries and primary records created during the specified time period should generally reflect the quality of the original CRFs being received from each site.

Options

Limitations

See Also

Description

DF_CTvisits tabulates, by site, the number of subjects who have reached each specified visit. The list of visits to tabulate is given by the required -S #, #-# option. From that list, all visits that have been registered in the database with status final, incomplete, missed or pending are included if -w all is specified; or only visits with a legal Visit Date are included if -w VisitDates is specified (default).

Options

Examples

-c 1~20 -S 0~2,4 -l 3 -n 4
DF_CTvisits: Study Visits Received by Site.     DFstudy 7. Apr 22,2017 23:21


DF_CTvisits  Number of Visits Received for Study Example
         only visits with legal VisitDates are included

Site          0     1     2     4

1 Vanc       21    21    21    21
2 Calg        2     2     2     2
3 St.        16    15    15    15
4 Univ       19    16     9    10
5 Roya       16    16    16    16
6 Sout                        
9 Sieb       28    27    27    26
10 Univ      58    57    57    53
11 Sunn      18    18    18    16
13 The       43    42    42    39
14 McMa      32    32    31    31
16 Otta      29    29    28    24
20 Mont      35    35    35    32

TOTAL       317   310   301   285

Limitations

Visit Date attribute.  -w VisitDates can not select a visit number unless that visit number appears on a plate containing at least one variable with the Visit Date attribute.

Visit Map.  -w all uses DFX_keys which contains the keys for each required plate that has been received or registered as missed. Thus DF_CTvisits can only be used for visit numbers that appear on one or more of the required plates defined in the study visit map.

Site label.  The site label selected with -l will only be displayed if -n is also included with a value greater than 0. It is not possible to have the site label sized automatically by omitting -n.

See Also

Description

DF_ICcenters checks the sites database for common errors and inconsistencies, reporting both errors (problems which will definitely impact the ability to communicate with the sites via DFdiscover) and warnings (problems which may impact communication).

DF_ICcenters should be used to detect errors after DFcenters has been defined but before study setup testing is complete. Ideally, DF_ICcenters will list no errors or warnings at the time data collection begins and thereafter.

If DFcenters is defined using the Sites view dialog in DFsetup, there are already some syntax checks in place that will detect inconsistencies such as out of range values. DF_ICcenters applies additional checks to the sites database that are not applied (or not known) in the Sites view editor. All site definitions that fail these checks are listed as the report output. Each failed check is categorized as either ERROR or WARNING. The ERROR categorization indicates a site definition that will definitely lead to problems in communication. A WARNING categorization indicates a site definition that may or may not lead to problems in communication, and hence should be investigated further.

When inconsistencies are detected by DF_ICcenters, each problem is identified with the beginning of the offending record in DFcenters followed by the ERROR or WARNING tag and a brief description of the problem. If multiple problems are detected within the same record, the offending record is only displayed once followed by a list of ERROR and/or WARNING problems. The exception to this is if problems are detected with the Subject ID entry. DF_ICcenters checks the Subject ID field separately from other fields in DFcenters. Hence it is possible for the offending record to appear more than once in the output if it has problems with both the Subject ID and other fields.

DF_ICcenters can be executed from the DFexplore Reports View, by using Verify available in the Sites view dialog in DFsetup, or by using File > Verify All also from DFsetup.

Options

Description

DF_ICimages checks that the CRF image name contained in each database record can be found in the study pages directory (where all documents are stored), and conversely, that each file in the study pages directory is referenced by exactly one database record.

Each database record contains the unique CRF image name corresponding to the submitted CRF page for that data record. DF_ICimages retrieves these image names from all data records and also retrieves the names of all documents stored in the study pages directory. It then compares these 2 lists looking for any cases where there is no one-to-one correspondence between the lists. The result is that this report identifies any database records for which the corresponding image is missing, and any images stored in the study pages directory for which there is no corresponding database record.

DF_ICimages processes the data records first and thereafter processes the CRF images. If the database is receiving new documents at the time that the report is run, it is possible that the results of these two sequential steps will not accurately reflect the database status. To account for this, you may chose to use -x.

Without -x, the database remains read-write for the duration of the report, and DF_ICimages can erroneously report an inconsistency where there is none. This can occur when new documents are being received at the instant that DF_ICimages is running and the timing of the new pages and data interleaves the execution of DF_ICimages. You may hence choose to ignore inconsistencies that deal with documents received, say today or this week, or run the report with -x which will guarantee consistency of results.

With -x, DF_ICimages will attempt to place the database server into a read-only state for the duration of the report. If successful, other tools that modify the database, such as DFexplore and incoming document processing, will not work until read-write access is restored by DF_ICimages.

Options

Description

DF_ICkeys checks each id for consistency with the sites database, each visit with the visit map, each plate with the list of legal plates, and optionally checks the consistency of subject initials across all database records within subject.

DF_ICkeys exports the keys for each database record and checks them as follows:

By default, DF_ICkeys checks all 3 keys (id,visit and plate) in records of all statuses (primary, secondary and missed) in all study plates, except for plate 501. It does not check initials by default because there is no default field in which subject initials can always be found.

A subset of the defined plates can be checked using -P #, #-#. This option can also be used to change the order in which plates are checked. This is important when used in conjunction with -I # because that option uses the first selected plate as the source of the correct subject initials. Queries can be checked for consistency of keys by including plate 511 in the list of plates in -P #, #-#, but subject initials will never be checked on that plate.

By default, each of the id, visit, and plate keys is checked. However, by using -K, a subset of the keys can be selected by including combinations (with no intervening spaces or commas) of the letters I for id, V for visit, and/or P for plate, in the option string.

-V is used to select the source(s) of legal visit/sequence numbers for each plate to use. Any combination (with no intervening spaces or commas) of the letters v, s, and p may be used but they must be specified as a single string. The letter v specifies that the legal visit/sequence numbers for each plate can be determined from the study visitmap. Similarly, s indicates that the legal range from the study schema should be used, and p indicates that the entries in the study page map should be used. When more than one source is used, the combination of sources is used with precedence given first to visit map, then schema and then page map, when a conflict occurs.

By default, records of all statuses are selected. Use -R to select only records of specified statuses. Any legal status keyword from the list: final, incomplete, pending, missed, all may be used. Multiple keywords must be separated by spaces and the entire string enclosed in "".

DF_ICkeys creates a DRF named ^[3] which lists the records, if any, that had key inconsistencies. This file can be used in DFexplore Data View to retrieve and review the problem records. The specific error (id, visit, plate or initials) is written to the 5^th field of each record in .

	Note
	DF_ICkeys reports the number of records with errors for each plate and also reports the number of errors in ids, visit numbers, plates and initials. Some plates may have more than one type of error, and as a result, the number of plates with errors may be less than the sum of the the different types of errors.

Options

Examples

-P 1~3 -I 8
DF_ICkeys: Check Key Fields (ID,SEQ,PLT,Initials) DFstudy 7. Apr 22,2017 23:44

Plate 001:    26 errors in  1664 records (26 Initials)
Plate 002:    60 errors in  1675 records (60 Initials)
Plate 003:    44 errors in  1333 records (1 Seqs, 43 Initials)

    Total:   130 errors in  4672 records
Use DF_ICkeys.drf to review problem records.

-R "final missed" -P 1~10
DF_ICkeys: Check Key Fields (ID,SEQ,PLT,Initials) DFstudy 7. Apr 22,2017 23:48

Plate 001:     0 errors in  1143 records
Plate 002:     0 errors in  1106 records
Plate 003:     1 errors in  1139 records (1 Seqs)
Plate 004:     0 errors in  1092 records
Plate 005:     0 errors in  1096 records
Plate 006:     0 errors in  1147 records
Plate 007:     0 errors in  1143 records
Plate 008:     0 errors in  4242 records
Plate 009:     0 errors in  1123 records
Plate 010:     0 errors in  1079 records

    Total:     1 errors in 14310 records
Use DF_ICkeys.drf to review problem records.

-I 8 -K "" -R "primary" -P 11~20
DF_ICkeys: Check Key Fields (ID,SEQ,PLT,Initials) DFstudy 7. Apr 22,2017 23:51

Plate 011:     0 errors in  1101 records
Plate 012:     4 errors in  1101 records (4 Initials)
Plate 013:    14 errors in  1063 records (14 Initials)
Plate 014:    30 errors in  1974 records (30 Initials)
Plate 015:    19 errors in   914 records (19 Initials)
Plate 016:     8 errors in   926 records (8 Initials)
Plate 017:    11 errors in   926 records (11 Initials)
Plate 018:    10 errors in   923 records (10 Initials)
Plate 019:    16 errors in   921 records (16 Initials)
Plate 020:     1 errors in    57 records (1 Initials)

    Total:   113 errors in  9906 records
Use DF_ICkeys.drf to review problem records.

-P 1~2 -L s
DF_ICkeys: Check Key Fields (ID,SEQ,PLT,Initials) DFstudy 253. Feb 11,2017 15:07
Plate 001:    30 errors in    53 records (30 IDs)
Plate 002:    11 errors in    26 records (11 IDs)

    Total:    41 errors in    79 records
Use DF_ICkeys.drf to review problem records.

Limitations

It is not possible to compare subject initials across plates where the subject initials variable is not the same variable number on each checked plate.

Description

DF_ICqcs checks the Query database for free-floating queries (i.e. having key fields that do not match an existing data record), duplicate queries (i.e. more than one query attached to the same data field), and unresolved queries bound to final database records.

DF_ICqcs only checks field level queries. It does not check code 21 (missing plate) or code 22 (overdue visit) queries created by DF_QCupdate or code 23 (missing plate) queries created by edit check function dfaddqc. Code 21 and 22 queries are removed when the missing plate is entered into the database, or by DF_QCupdate if the plate or visit is no longer missing or overdue, or by the database server when it shuts down, if the subject ID to which the query refers is no longer present in the database. Code 23 queries are only removed when the missing plate is entered into the database. These queries are not touched by DF_QCupdate or by database server shutdown. It would be legal for example, for an edit check to create a code 23 query for a subject that did not exist in the database but should exist according to the study protocol (e.g. when subject IDs must be used in sequence and a gap is found in the subject IDs).

In addition to reporting the number of query inconsistencies found, DF_ICqcs creates a separate output file, containing the problem queries, for each type of query inconsistency found. Each of these files has the current date and time as a common suffix and a prefix matching the type of inconsistency:

The -r option can be used to repair 2 of these inconsistencies. When this option is used free-floating queries are deleted and unresolved queries on final records are changed to "resolved, corrected" with the current user and timestamp inserted into the query's resolution field. No attempt is made to resolve duplicate queries.

Duplicate queries can be resolved by using the qcdup output file, changing the status field to the value 7 (delete) on the queries you wish to delete, removing the queries that you wish to keep, and then importing the records to be deleted using DFimport.rpc.

Options

Limitations

This report only checks field-level queries (code 21-23 are ignored), and the repair option is not able to correct duplicate queries.

Description

DF_ICrecords verifies the structural integrity of data records for all or specified plates of the database, including any pending records. Specifically, DF_ICrecords checks each record for:

This is not an exhaustive list but has been shown to detect structural problems in database records where they exist. The utility program DFcmpSchema should be used to exhaustively check individual data values against the study schema.

DF_ICrecords also checks for:

A DRF containing the key fields for each data record that fails this structural consistency check can be created by including -d. The DRF is named ^[4]. This DRF can be subsequently used in DFexplore Data View to retrieve and revalidate problem records. Note however that DFexplore will only be able to locate the records referenced by the DRF if the record keys are still usable despite the structural inconsistency.

For greater detail than is offered by -d, data files with inconsistencies can be exported into 2 files by including -s. Each data file that has an inconsistency is exported so that consistent records are written to plt###.ok and inconsistent records are written to plt###.bad. These files are created in the unique directory $WORKING_DIR/split.$$ (where $$ is the program process id). If necessary, the records in plt###.bad can be corrected via a manual process and then merged back into the database with the DFimport.rpc program.

DF_ICrecords can not check for orphaned secondary records unless records of all statuses are exported (which is the default).

	Status keywords
	If -r status is used, be careful not to include the Query database -p #, #-#. The available status keywords are intended for data record statuses and are not equivalent to query statuses. By default DF_ICrecords includes records with status pending. It is not possible to check pending records separately, but they can be excluded by specifying status primary.

Options

Examples

-r primary -p 1-5
DF_ICrecords: Check Data Records.                 DFstudy 7. Apr 23,2017 21:04

plt001.dat (NF= 28)     1179 Records:     1179 Ok        0 Bad
plt002.dat (NF= 74)     1149 Records:     1149 Ok        0 Bad
plt003.dat (NF= 53)     1151 Records:     1151 Ok        0 Bad
plt004.dat (NF= 40)     1150 Records:     1150 Ok        0 Bad
plt005.dat (NF= 72)     1147 Records:     1147 Ok        0 Bad

-p 511 -s
DF_ICrecords: Check Data Records.                 DFstudy 7. Apr 23,2017 21:07

DFqc.dat   (NF= 22)    10466 Records:    10466 Ok        0 Bad

Description

DF_ICschema checks the database schema for common errors and inconsistencies, reporting both errors (schema definitions that will definitely lead to problems) and warnings (schema definitions that may lead to problems).

DF_ICschema should be used as a companion to DFsetup during study schema development. While DFsetup attempts to identify errors as they are made, it cannot catch everything; thus it is important to run DF_ICschema after the setup is complete. It may also be useful to run DF_ICschema periodically during a study setup, for example after setup has been completed for each plate. Ideally, DF_ICschema should report no errors or warnings before the study is started, and thereafter.

All schema definitions that fail DF_ICschema checks are listed in the report output. Each failed check is categorized as either Error or Warning. An Error categorization indicates a definition that will definitely lead to problems. A Warning categorization indicates a definition that may or may not lead to problems, and hence should be investigated further.

Options

Description

DF_ICvisitdates displays any errors detected during the last execution of DF_XXkeys including:

The source for the report output includes the three files:

that were created by DF_XXkeys. DF_ICvisitdates does not create these files itself - it simply formats their contents into a readable report. The check for dates that may be out of order is performed by reading the intermediate file DFX_visit.dates, which is also created by DF_XXkeys.

Options

None.

See Also

Description

DF_ICvisitmap detects syntactic and semantic errors in the visit map, and checks for adherence to DFdiscover visit map rules.

It also checks the definition of all dates defined in the study schema, checks the syntax and validity of page map entries, and checks any of the conditional maps (cycle, visit, plate and termination) that have been defined.

The following checks are performed on the visit map:

The following checks are performed on the conditional maps, if used, for: conditional cycles, visits, plates and termination:

The following checks are performed on the page map, if used.

Options

None.

Examples

DF_ICvisitmap: Check Visit Map Specifications.    DFstudy 245. Jan 18,2018 15:24

Study Schema                = /Users/Shared/studies/s245/lib/DFschema
Visit Map                   = /Users/Shared/studies/s245/lib/DFvisit_map
Conditional Cycle Map       = /Users/Shared/studies/s245/lib/DFccycle_map
Conditional Visit Map       = /Users/Shared/studies/s245/lib/DFcvisit_map
Conditional Plate Map       = /Users/Shared/studies/s245/lib/DFcplate_map
Conditional Termination Map = /Users/Shared/studies/s245/lib/DFcterm_map
Page Map                    = /Users/Shared/studies/s245/lib/DFpage_map

Checking All Date Fields in Study Schema

Checking VisitDate Fields in Study Schema

Checking Visit Map

ERROR at line 7: 93|X|Screen 3|1|10|14|0|1|11|12
      screening visits are only allowed in the screening cycle

Checking Conditional Cycle Map

Checking Conditional Visit Map

ERROR at line 4: |101-100+value
      syntax error, expected: [+-~]|visits(s)

Checking Conditional Plate Map

Checking Conditional Termination Map

Checking Page Map

ERROR at line 10: S|1001-1003,1101-1103|Visit #%{S.1.2}.%{S.3.2}
      label is 12 characters long, the maximum = 10
      example: Visit #10.01

See Also

Description

DF_PTcrfs lists all assessments received for each subject with the date of the assessment and the status of all pages of the CRF received for that visit, including both required and optional pages.

Each row of the output displays the subject ID, the visit number, the visit date if known, and a list of plate numbers received for that subject ID and visit. Each plate number has an optional suffix that identifies the highest priority problem on that plate, if any. The code and meaning of each suffix is shown in the figure. Those in the first column are not mutually exclusive and are listed in priority order. For example, a plate which has both an unresolved Q&A note and an unresolved internal query will have the suffix ? because the Q&A note takes precedence. A plate number that has no suffix is considered to be final.

QUERY CODES (ordered by priority):             OTHER CODES:
r = outstanding refax request               - = missing page
? = unresolved Q&A note                     x = registered as missed
i = unresolved internal query               * = error status (missing keys)
+ = incomplete but no unresolved queries    p = pending status
                                            NA = visit date is coded Not Available

The - suffix used to identify missing plates is determined from the Query database where missing plate queries are inserted by DF_QCupdate. DF_QCupdate must be executed to update the Query database before running DF_PTcrfs if the status of missing plates is likely to have changed, generally because new records have been validated since DF_QCupdate was last run, or the visit map was changed.

Options

Examples

-c 99
DF_PTcrfs: CRFs Received at Each Visit.           DFstudy 254. Dec 09,2014 14:39

Complete CRF Log by Subject :  Acceptance Test Kit

QRY CODES (ordered by priority):            OTHER CODES:
r = outstanding refax request               - = missing page
? = unresolved Q&A note                     x = registered as missed
i = unresolved internal query               * = error status (missing keys)
+ = incomplete but no unresolved queries    p = pending status
                                            NA = visit date is coded Not Available

     SUBJECT    VISIT   DATE     CRF PLATES

          99001     0 03/03/97   1
          99001     1 06/03/97   2 3 4
          99001    21 06/04/97   5
          99001    22 06/05/97   5
          99001    23 06/06/97   5
          99001    24 06/07/97   5
          99001    30 06/07/97   6- 7
          99001    51            8
          99001   201            11
          99001  1011            9

          99002     0 04/01/97   1
          99002     1 08/01/97   2 3 4
          99002    21 08/02/97   5
          99002    22 09/03/97   5
          99002    23 10/04/97   5
          99002    24 07/05/97   5
          99002    30 07/05/97   6 7
          99002    40 12/06/97   10
          99002    51            8
          99002  1011            9p

          99003     0 07/01/97   1

          99004     0 01/06/97   1
          99004     1 03/06/97   2 3 4
          99004    21 04/07/97   5
          99004    22 05/08/97   5
          99004    23 06/09/97   5
          99004    24 06/10/97   5
          99004    30 06/10/97   6 7
          99004   201            11

          99006   201            11

          99007     0 23/04/97   1
          99007     1 25/04/97   2p 3 4x

See Also

Description

DF_PTlist is a simple subject-listing program which displays subject data in a spreadsheet-like format. The columns are selected variables (e.g. age sex, diagnosis, etc.), and the rows are individual subject ID and visit number combinations on which the data was collected. DF_PTlist is simple to use, but also limited. It is not intended to be a general-purpose report generator and will not replace your need for more sophisticated reporting software.

DF_PTlist relies heavily on the ability to specify field and plate numbers. As a result it is useful to have a current listing from DF_SSschema or DF_SSvars available when constructing the option list.

The diversity of uses for DF_PTlist is best learned by following the examples.

Options

Examples

These examples are based upon study 254, the DFdiscover Acceptance Test Study. The number of records in the database has been intentionally limited so that the examples can demonstrate the input with very little output.

-X 1 9 21~25 -X 5 10 12
DF_PTlist: Subject Data Listings.                 DFstudy 254. Nov 11,2017 08:10

   SUBJECT VISIT  AGE S2SBP1 S2DBP1 S2SBP2 S2DBP2 S2SBP3 FSBP1 FSBP2

     99002     0   64    172    098    168    096    166     .     .
     99002    21    .      .      .      .      .      .   154   150
     99002    22    .      .      .      .      .      .   150   146
     99002    23    .      .      .      .      .      .   144   140
     99002    24    .      .      .      .      .      .   136   138

-x 1 8 %10s 9 %12s
DF_PTlist: Subject Data Listings.                 DFstudy 254. Nov 11,2017 08:12

   SUBJECT VISIT      PINIT          AGE

     99002     0        JAM           64

-X 1 21 22 -R 1 23 24 -R 25 26
DF_PTlist: Subject Data Listings.                 DFstudy 254. Nov 11,2017 08:29

   SUBJECT VISIT  S2SBP1 S2DBP1

     99002     0     166    094
     99002     0     168    096
     99002     0     172    098

-X 1 21 22 -H SBP DBP -R 1 23 24 -R 25 26
DF_PTlist: Subject Data Listings.                 DFstudy 254. Nov 11,2017 08:44

   SUBJECT VISIT  SBP DBP

     99002     0  166 094
     99002     0  168 096
     99002     0  172 098

-S "if(x[5]==1)" -X 5 10-14
DF_PTlist: Subject Data Listings.                 DFstudy 254. Nov 11,2017 08:52

   SUBJECT VISIT  FSBP1 FDBP1 FSBP2 FDBP2 FARM

     99002    21    154   092   150   090    1
     99002    23    144   090   140   086    1
     99002    24    136   082   138   080    1

-X 1 8-10 -I 99000-99999
DF_PTlist: Subject Data Listings.                 DFstudy 254. Nov 11,2017 08:55

   SUBJECT VISIT  PINIT AGE SEX

     99002     0    JAM  64   1

-b lines 50

-X 1 3 9 -X 2 3 9 -v 1 3~5 -I 1101 1103 -p -b cases 1
DF_PTlist: Subject Data Listings.                 DFstudy 253. Nov 11,2017 08:57

   SUBJECT VISIT STATUS     DFRASTER    edate     DFRASTER vdate002

      1101     1    1f6 9532/0040005 07/08/95            .        .
      1101     1    2f6            .        . 9532/0054001 07/09/95
      1101     3    1f6 9533/0177004 07/14/95            .        .
      1101     4    1f6 9533/0177007 08/10/95            .        .
      1101     5    1f6 9540/0098002 10/04/95            .        .
pagebreak

   SUBJECT VISIT STATUS     DFRASTER    edate     DFRASTER vdate002

      1102     1    1f6 9532/0035007 07/24/95            .        .
      1102     1    2f6 9532/0035007 07/24/95 9532/0035001 07/24/95
      1102     3    1f6 9534/0119003 07/27/95            .        .
      1102     4    1f6 9534/0125007 08/25/95            .        .
      1102     5    1f6 9542/0105002 10/20/95            .        .

-X 1 9~12 -X 2 15 12 16
DF_PTlist: Subject Data Listings.                 DFstudy 254. Nov 11,2017 09:25

   SUBJECT VISIT  AGE SEX RACE             RACEOTH  HTIN  WTKG PULSE

     99002     0   64   1    1                         .     .     .
     99002     1    .   .    .                   . 072.0         056

-x 1 8 %5s 9 %12s -c 12~14 22 -I 6001 -v 1 51~59 -b lines 50

-S "if(x[1]==1)" -X 5 12~16 -e -X 8 21 22

-S "if(x[1]==1)" -X 5 12~16 -S "if(x[1]>140 || x[2]>90)" -X 8 21 22

-X 1 9 10 -s "if(x[1]>0)" -x 7 9 %9s 10 %9s 11 %20.15s -R 7 12~14 -R 7 15~17

-S "if(x[1]>50)" -X 1 9 10 -S "if(x[1]>0)" -x 7 9 %9s 10 %9s 11 %20.15s -R 7 12~14 -R 7 15~17

-S "if(x[1]>50 && x[2]==1)" -X 1 9 10 -e -X 2 13~17

See Also

Description

DF_PTmissing reads the Query database and lists missing plate and overdue visit queries for all subjects, or for subjects from specified study sites.

Missing plates and overdue visits are identified by the most recent execution of DF_QCupdate and are simply reported by DF_PTmissing.

If none of -o, -m and -e are selected, overdue visits and both types of missing plates are listed. Any combination of these 3 problem types may be listed by selecting the appropriate options.

Options

Examples

-c 1
SUBJECT ID  VISIT  PROBLEM

         6      1  Overdue Visit:  Initial Assessment
         6      2  Missing Plates: 4 8 9 10 11 12 13 14 15 16

-c 1 -p
SUBJECT ID  VISIT  PROBLEM

         6      1  Overdue Visit:  Initial Assessment
         6      2  Missing Plates: 4M Page 1 of 6
                                   4M Page 5 of 6
                                   4M Page 6 of 6
                                   Nurse/Diet. Summ.
                                   4M FIT QOL Pg 1
                                   4M DQOL Pg 1 of 5
                                   4M DQOL Pg 2 of 5
                                   4M DQOL Pg 3 of 5
                                   4M DQOL Pg 4 of 5
                                   4M DQOL Pg 5 of 5

Limitations

DF_PTmissing lists the missing plate and overdue visit queries added by the previous execution of DF_QCupdate. It does not automatically execute DF_QCupdate.

See Also

Description

DF_PTqcs is identical in function to DF_CTqcs but it groups data by subject id range (required) whereas DF_CTqcs groups data by site.

DF_PTqcs reports a summary of the user-created, external queries added during data validation. queries are selected by their creation date from a specified time period that may include one of:

The following queries are not included in the report:

The summary is in the form of two tabular reports. The first report displays for each subject (row), columns that contain:

SUBJECT TOTAL    TOTAL   RATE/   RESOLVED QRYS  STATUS & TIME TO RESOLUTION
ID#     RECORDS  QRYS   100 REC     #     %     Correct   N.A.   Irrel.  DAYS  Pending
        (1)      (2)     (3)        (4)             (5)                      (6)   (7)

The second table displays for each subject (row), columns that contain:

SUBJECT    AGE (DAYS) NEW/UNSENT QUERIES(1)   AGE (DAYS) SENT/UNRESOLVED QUERIES(2)
ID#       00-10  11-20  21-30  31-60  > 60     00-10  11-20  21-30  31-60  > 60

An alternative report format can be requested with -a. This format displays results in a single table that is a hybrid of the two tables described above.

SUBJECT TOTAL    TOTAL   RATE/   RESOLVED QRYS  AGE (DAYS) OF UNRESOLVED QRYS
ID#     RECORDS  QRYS   100 REC     #     %     <=10 11-20 21-30 31-60   >60

DF_PTqcs uses summary file which is created by DF_XXtime. DF_PTqcs will run DF_XXtime first, if necessary, to update unless -x is used, in which case the results will reflect the state of the database on the last time that DF_XXtime was run.

Options

Limitations

See Also

Description

DF_PTschedule shows the first visit, last completed visit, and next scheduled visit for each subject. It also shows if there are any outstanding problems, i.e. unresolved queries.

This report uses DF_QCreports to produce an internal Query Report listing the status of subjects from the specified sites. The purpose of DF_PTschedule is to provide a simpler mechanism (than DF_QCreports) for obtaining subject status information only. The only additional functionality added by DF_PTschedule that is not offered by DF_QCreports is through the -p done option.

Options

Examples

-c 10 99 -p fup -dtfmt "mmm dd, yyyy"
DF_PTschedule: Subject Visit Scheduling.          DFstudy 254. Apr 23,2017 22:28

SUBJECT STATUS SUMMARY  (* identifies subjects with outstanding data queries)

SUBJECT                ENTRY VISIT         LAST FOLLOW-UP         NEXT FOLLOW-UP

     10100*    Day 1: JAN 01, 2016    3 Mo.: APR 01, 2016    4 Mo.: MAY 03, 2016
     10101*    Day 1: OCT 01, 2016    3 Mo.: JAN 01, 2017    4 Mo.: JAN 31, 2017
     10102*    Day 1: JAN 01, 2016    3 Mo.: APR 01, 2016    4 Mo.: MAY 03, 2016
     10103*    Day 1: JAN 01, 2015    3 Mo.: unknown         4 Mo.: MAY 03, 2015
     10104*    Day 1: NOV 01, 2015    3 Mo.: JAN 01, 2016    4 Mo.: MAR 03, 2016
     10105*    Day 1: OCT 01, 2016    3 Mo.: DEC 30, 2016    4 Mo.: JAN 31, 2017
     10200*    Day 1: JAN 02, 2016    Day 1: JAN 02, 2016    1 Mo.: FEB 01, 2016
     10300*    Day 1: JAN 02, 2016    Day 1: JAN 02, 2016    1 Mo.: FEB 01, 2016
     10400*    Day 1: JUN 01, 2016    1 Mo.: JUL 02, 2016    2 Mo.: AUG 01, 2016
     10500*    Day 1: JUN 15, 2016    1 Mo.: JUL 15, 2016    2 Mo.: AUG 15, 2016
     10600*    Day 1: OCT 01, 2015    4 Mo.: MAR 01, 2016      End: JAN 31, 2016
     10601*    Day 1: OCT 08, 2016    Day 1: OCT 08, 2016    1 Mo.: NOV 07, 2016
     99002*    Day 1: MAR 06, 2015    Day 1: MAR 06, 2015    1 Mo.: APR 05, 2015

Limitations

The total space allotted for the visit label and date is 23 characters. Allowing a maximum of 6 characters for the label, 2 characters for ": " between the label and the date, and 2 characters for space between visits, leaves a maximum size for date formats of 23-6-2-2 = 13 characters.

See Also

Description

This report lists unexpected plates and visits found in the study database by DF_QCupdate. The report output appears as illustrated in the following example.

DF_PTunexpected: Unexpected Data by Subject.      DFstudy 2. Jan 25,2016 12:08

     99010 Visit  1019: Phase I: 1-Mon, Extra Visit 9
           Plate(s)   : 24,30-33,35-36
           Problem    : unexpected visit: 18 days post termination

     99011 Visit  1020: Phase I: 2-Mon Visit
           Plate(s)   : 30-34
           Problem    : unexpected plate: excluded by plate condition 24

     99011 Visit  1020: Phase I: 2-Mon Visit
           Plate(s)   : 75
           Problem    : unexpected plate: not required, optional or conditional

     99011 Visit  1021: Phase I: 2-Mon, Extra Visit 1
           Plate(s)   : 20,24,30-36
           Problem    : unexpected visit: excluded by visit condition 5

The output for each problem consists of 3 lines. The 1st line identifies the subject ID, visit number and visit label. The 2nd line identifies the plate or plates that were unexpected at that visit. The 3rd line describes the problem as follows:

Options

If no options are specified DF_PTunexpected lists all of the unexpected records identified by the last execution of DF_QCupdate. The following options can be used to focus the output on selected cases.

Limitations

See Also

Description

This report shows visit scheduling and status information for subjects and visits meeting the specified selection criteria. The report output appears as illustrated in the following example.

DF_PTvisits: Visit status & schedule. DFstudy 245. Mar 20,2016 11:35   PAGE 35

      1064 0:SCREENING (required) -terminated 03/09/07
      1064    91 X Screen #1          0  0  rD ~03/08/31   
      1064    92 X Screen #2          7  0  rT  03/09/07   
      1064 
      1064 1:IN-STUDY VISITS (required)
      1064    51 P Pre-entry         -2  0  rD ~03/09/11   
      1064     0 B Baseline           0  0  rD  03/09/13
      1064     1 O QOL form           -  -  rD  03/09/13   CV1r
      1064    61 r Lab Test           -  -  x.             CV2x
      1064     3 S Month 3           91  5  rL                   
      1064     6 S Month 6          183  5  n* ~04/03/14   DOD=6
      1064     9 S Month 9          274  5  r. ~04/06/13   
      1064    12 T Month 12         365  5  r. ~04/09/12   
      1064    81 E Early Term         -  -  o.             
      1064   210 R Clinical Eval      0  0  r. ~04/09/12   
      1064   211 R Patient Eval      30  0  ?.             
      1064 
      1064 2:REPORTS (end)
      1064    80 A Death Report       -  -  o.
      1064   101 O AE Report #01      -  -  o.

The output for each subject is displayed as a block of records beginning with the subject ID (1064 in the example above).

Cycle Records.  Each cycle begins with a record showing the cycle number, label, type, conditions that affect cycle requirement (if any), and the cycle termination date (if it has terminated). The termination date may also identify an abort date that precedes the scheduled cycle start date. If the cycle requirement is affected by a conditional cycle map entry the condition number and action is displayed using the following format:

CC# (required | optional | excluded)

where # is the condition number determined by the order in which the conditions are defined in the conditional cycle map.

Visit Records.  Each visit starts with the visit number, the single letter visit type acronym, visit label, visit scheduled due day, and the overdue allowance, all of which come from the study visit map. For optional visits, which cannot be scheduled, due day and overdue allowance appear as - (dash). These visit map specifications are followed by visit status and scheduling information in the following order:

Visit Tags.  After the visit date additional information may be displayed:

Options

The options for this report are grouped into 4 categories. Subject and visit selection options determine which subjects and visits are included in the report, visit tag options determine which information tags are displayed, and the formatting options allow limited control over the report output format. By default all subjects enrolled in the trial and all visits defined in the visit map are included in the report. If more than one subject and/or visit selection option is specified, only those subjects and visits that meet all of the selection criteria are included in the report.

"%10d %5d(1) %s(2) %-15.15s %4s %2s  %2s %-11.11s(3) %s"

Examples

-c 40-44 -itime e10 l10 o30 oU

-itime done -v 101-199

-vtype BST

-cneed excl -cdone inpr term abort

-tag all sday

Limitations

See Also

Description

DF_QCfax converts Query Reports into PDF documents, includes DFdiscover bar coding, and transmits them to the clinical sites and/or other destinations by fax or email.

Often, DF_QCfax will be run shortly after creating a new batch of Query Reports, to send them to the clinical sites. When this is the case, it is not necessary to specify the reports to be sent. The default is to send all reports listed in file reports/QC/QC_NEW, which is re-created each time DF_QCreports is used to create a new batch of external Query Reports. If some of the reports listed in this file have already been transmitted by a previous run of DF_QCfax they will be skipped, and not sent out again.

When not sending a batch of newly created external Query Reports, the reports to be transmitted must be specified explicitly using one of 5 options, only one of which can be used at a time. The -s and -u options are used to identified previously sent and unsent external Query Reports respectively, and the -i option is used to identify internal Query Reports, whether previously sent or not. Each of these 3 options must be followed by a space delimited list of the report names to be transmitted.

The 4^th option, -b, is used to re-transmit the backlog of transmission failures (if any) from a previous run of DF_QCfax for a set of external Query Reports created on a particular date. The -b option is followed by a single report date in yymmdd format. This identifies the creation date of the set of Query Reports to be re-tried if they have not yet been successfully transmitted. (Note: This is the date included in the Query Report name. It is the report creation date and may be different from the date on which the Query Reports were transmitted by DF_QCfax). This is the option to use to ensure that Query Reports are re-transmitted to all of the destinations listed for each clinical site in the sites database. While re-running DF_QCfax with no options will keep trying to send any Query Reports listed in file reports/QC/QC_NEW which have not been delivered, it only does this for the primary destination for each external Query Report. The -b option will do it for the secondary destinations as well.

The 5^th and final option, -a, is used to transmit all unsent reports, residing in the QC directory. Use this option carefully. Each time DF_QCreports is run, Query Reports are created in the study QC directory. If any of these reports are not transmitted using DF_QCfax, or marked as sent using DF_QCsent, they remain in this directory. Subsequently running DF_QCfax with the -a option will fax all of the Query Reports found in the QC directory. This could result in sending old Query Reports that are no longer relevant. In many cases the -b option will be a better choice.

Use of -b

The backlog option relies on finding a record of all previous transmission attempts in file , a journal of Query Report transmissions maintained by DF_QCfax. Thus changes to the sites database to modify or add destinations for any of the clinical sites, will not be used by the backlog option. Only destinations registered in are considered for re-transmission. Changes to the destinations listed in the sites database only become effective for Query Reports sent by DF_QCfax after the changes were made. DF_QCfax needs to know whether any given transmission is bound for a primary or secondary destination. Thus when the backlog option is used it looks for at least one entry in with the PRIMARY keyword, and will not attempt to re-send any of the FAILED Query Reports unless this keyword is found.

When sending external Query Reports to the clinical sites, it is not necessary to specify the destination fax number or email address for each site. By default, DF_QCfax will send the external Query Report created for each clinical site to all of the fax or email destinations listed in the Primary Fax field of the sites database for that site. This field can contain one or more fax numbers and/or email addresses. The first fax number or email address in the field is considered the primary destination for the clinical site and all others are secondary destinations. However, it is also possible to override the destination(s) specified in the sites database by using the -f option followed by a space delimited list of fax numbers and/or email addresses. With this option, each of the specified reports is sent to all of the specified destinations. Since there is no site ID automatically associated with internal Query Reports, the -f option must be used to specify at least one destination fax number and/or email address, when sending internal reports.

When sending an external Query Report to multiple destinations, the first fax number or email address in the list of destinations is considered the primary destination for that site, and all others are considered secondary destinations. This is true whether the destination list is specified explicitly using the -f option, or is obtained from the Primary Fax field of the sites database. On successful transmission of an external Query Report to a primary destination DF_QCfax runs DF_QCsent which marks all of the queries in the report sent, and moves the report to the QC/sent directory. This does not happen on successful transmission to secondary destinations. Reports which could not be transmitted to their primary destination remain in the QC directory, and their queries retain their old status of in report.

If a transmission is successful the report name, date, time and fax number is registered in with the keyword FAXED, and if it failed it is registered with the keyword FAILED. The keyword PRIMARY identifies those transmissions bound for the primary destination for a clinical site.

Emailing Query Reports

Due to the limitations of email technology, it is not always possible to accurately determine the final status of emailed reports, and thus they are always considered to have been successful, and are registered in with the keyword FAXED. Since emailed Query Reports are always considered successful, DF_QCsent will always execute if the primary destination has an email address, and thus it is possible that query status may be changed to sent and the Query Report moved to the sent directory even though the Query Report was not delivered. It is recommended that a fax number be used as the primary destination for a site whenever one is available, and email address(s) (and additional fax numbers) be used as secondary destinations. Use an email address as the primary destination when it is the only method available.

	Since both DF_QCfaxlog and the -b option rely on the existence of information in , it is critical that this file not be deleted or modified in any way. Using DF_QCfaxlog to check the transmission status of Query Reports is the safe way to review the records in .

If transmission is by email, DFdiscover converts the Query Report to PDF format (if it is not already in that format) and then sends it as a MIME attachment to the specified email address. This PDF attachment can optionally be password protected and encrypted using the -p password to specify a password, or the -P option to use the user's default password.

When emailing an external Query Report the email return address is taken from the REPLY TO field of the sites database. The -F option can be used to override this value or to add a return address when emailing an internal Query Report. If a return address is not supplied in either of these ways the email will be identified as coming from user datafax and any reply sent to this address will be delivered to the DFdiscover problem mail recipient.

In Query Reports sent via email, the subject line of the email has the following format: Query Report for studyname: site site #, year/month/day where studyname is determined from /opt/dfdiscover/lib/DFstudies.db. If studyname cannot be determined, the subject line of the email has the following format: Query Report for study #: site site #, year/month/day

By default reports are sent immediately. The -w option can be used to delay transmission to a specified time. This option accepts the following values:

The complete list of values which are legal for this option matches those available for DFsendfax and can be found in Programmer Guide, Delayed Sending.

Sending documents manually

If for some reason you decide not to distribute Query Reports using DF_QCfax, but instead to send them to the clinical sites some other way, remember to run DF_QCsent to register these documents as having been sent. Otherwise and the queries will not be updated. As a result, DF_QCfaxlog could not be used to track report transmissions, the -b backlog option could not be used, the -o of DF_QCreports would not operate as intended, and the true status of queries would not be accurately reflected in DFexplore or DFexport.rpc.

Options

Examples

-u 120-040815 122-040815

-w 02:00 -f 555-1212 -i test -F dan@hotmail.com

-r 1 -d 30 -u 123-040603

-s 150-040625 -f mailto:dan@hotmail.com

-b 041003

-u 123-100808 -f mailto:dan@hotmail.com -label "Please review and sign"

See Also

Description

DF_QCfaxlog displays journal entries from the study

A journal entry is written to for each Query Report transmission, by fax or email, that is attempted by DF_QCfax. If transmission is attempted to multiple destinations a separate record is written for each destination.

When a Query Report is sent to multiple destinations, the first destination in the list is considered to be the PRIMARY destination, and all others (if any) are considered to be secondary destinations. This is true whether the destination list is set in DF_QCfax using the -f option or by using the destinations listed in the Primary Fax field of the sites database. The keyword PRIMARY in a entry identifies a record for a primary destination.

For each destination, whether primary or secondary, a record is written to after all retries have been completed, that shows whether the transmission was successful. The keyword FAXED identifies a successful transmission, and the keyword FAILED identifies a failure. If the transmission to the primary destination is successful the log also shows the number of queries included in the report, and indicates that they have been updated to status sent in the Query database.

	Warning
	Query Reports sent by email are always considered successful, because there is no accurate way to determine the ultimate success or failure of an email transmission.

The following excerpt from displays entries for a single Query Report that was successfully faxed to two different fax numbers and one email address.

001-170820  FAXED  to PRIMARY   905-555-9999  Mon Aug 20 11:14:38 2017 (marked 8 queries)
001-170820  FAILED to   905-444-1111  Mon Aug 20 11:15:38 2017
001-170820  FAXED  to mailto:dan@hotmail.com  Mon Aug 20 11:16:38 2017

These entries indicates that the Query Report, named 001-170820, was successfully sent to the first and third destinations, but failed to the second destination. Successful faxing to the first (PRIMARY) destination also caused the 8 queries in this report to be marked as sent.

If a Query Report is successfully sent to the primary destination, but it contains no queries, the log entry would indicate (marked 0 queries).

Records can be selected from with the -l and -m options. If both selection criteria are used, they are applied in the order specified; altering the order can produce different results, as illustrated by the last 2 examples below. If no selection criteria are specified, all reports listed in QC_NEW (i.e. reports created by the last execution of DF_QCreports) are selected.

Options

Examples

DF_QCfaxlog: Transmittal Status for Query Reports.      DFstudy 7. Apr 01,2017 14:55

013-170322  FAXED  to PRIMARY    ###-####  Wed Mar 22 13:34:43 2017  (marked 100 queries)
013-170323  FAXED  to PRIMARY    ###-####  Thu Mar 23 13:06:51 2017  (marked   6 queries)
026-170323  FAXED  to PRIMARY    ###-####  Thu Mar 23 13:45:24 2017  (marked   4 queries)
009-170323  FAXED  to PRIMARY    ###-####  Thu Mar 23 14:16:56 2017  (marked  37 queries)
010-170323  FAXED  to PRIMARY    ###-####  Thu Mar 23 15:27:42 2017  (marked  84 queries)

DF_QCfaxlog: Transmittal Status for Query Reports.      DFstudy 7. Apr 01,2017 15:00

009-170323  FAXED  to PRIMARY    ###-####  Thu Mar 23 14:16:56 2017  (marked  37 queries)
010-170323  FAXED  to PRIMARY    ###-####  Thu Mar 23 15:27:42 2017  (marked  84 queries)
013-170323  FAXED  to PRIMARY    ###-####  Thu Mar 23 13:06:51 2017  (marked   6 queries)
026-170323  FAXED  to PRIMARY    ###-####  Thu Mar 23 13:45:24 2017  (marked   4 queries)

-m FAIL -l 20

-l 20 -m FAIL

See Also

Description

DF_QCprint formats the specified Query Reports into a PDF document including DFdiscover barcoding and sends the reports to the study printer.

Reports to be printed may reside in one of three directories. The three directories, all under the study reports directory are:

If no options are specified, the reports listed in QC_NEW (that is, those reports created by the last execution of DF_QCreports) are printed.

Options

Examples

-u 120-910815 122-910815

-s *-990415

-u 123-100808 -label "Please review and sign"

See Also

Description

DF_QCreports is used to create reports containing subject scheduling information and data queries. It can be used to create both External Query Reports, designed for transmission to the clinical sites, and Internal Query Reports, which might contain subject data from more than one clinical site or include internal data queries not intended for the clinical sites.

DFdiscover Query Reports can be created with any or all of the following content:

This chapter describes the 2 types of Query Reports, the content and appearance of each section of a Query Report, the study configuration files on which Query Reports depend, the many options available to control the content and format, and some important limitations and recommendations.

External & Internal Query Reports

External Query Reports are designed for transmission to the clinical sites participating in the trial. They are named using the site ID and creation date in ccc-yymmdd format. For example, 012-170715, 5120-170715 and 21460-170715 identify external Query Reports created for sites 12, 5120 and 21460 on July 15, 2017. This identifier is printed at the top of each page of the report along with the name of the individual responsible for Query Reports at the clinical site and the name of the site, as specified in the sites database. When a Query Report is created an ASCII file containing the report contents is written to the study reports/QC directory. When Query Reports are printed using DF_QCprint or sent to the clinical site using DF_QCfax they are first converted to PDF for a more attractive appearance. Each external Query Report that is successfully transmitted to its clinical site is moved into the study reports/QC/sent directory, where it will remain unless removed manually. If an external report is never transmitted to its clinical site it will remain in the reports/QC directory unless removed manually.

Internal Query Reports are assigned a name by the user when they are created and are written to the reports/QC/internal study directory. If a name is reused the previous version of the report will be overwritten. Like external Query Reports, internal Query Reports may also be printed using DF_QCprint and faxed using DF_QCfax but because the report name does not automatically link them to a specific clinical site, the way external Query Report names do, a destination fax phone number must be specified.

The Contents of Query Reports

Query Reports have 3 main sections, the subject status list, the refax list and the question and answer list. They may also include a 1 page cover sheet.

QUERY REPORT # 003-040323-01  ( Jane Smith, Dundas Valley Health Clinic )

SUBJECT STATUS SUMMARY  (* identifies subjects with data queries in this report)
   
   SUBJECT                 ENTRY VISIT            LAST FOLLOW-UP            NEXT FOLLOW-UP
      1081*     SCREEN #0: DEC 03,2016     Visit 06: JAN 26,2017     Visit 07: APR 26,2017
      1082*     SCREEN #0: not done        Visit 05: MAR 24,2017     Visit 06: APR 23,2017
      1083*     SCREEN #0: unknown         Visit 02: unknown         Visit 03: ?
      1084*     SCREEN #0: MAR 08,2017     Visit 03: APR 07,2017     Visit 04: MAY 07,2017
      1085*     SCREEN #0: overdue         Visit 03: APR 28,2017     Visit 04: MAY 28,2017
      1086*     SCREEN #0: APR 15,2017     Visit 04: MAY 15,2017             : done       
      1087*     SCREEN #0: APR 22,2017    SCREEN #0: APR 22,2017    SCREEN #1: APR 29,2017
      1088*     SCREEN #0: APR 26,2017    SCREEN #0: APR 26,2017    SCREEN #1: MAY 03,2017
TOTAL CASES = 8

FAX/REFAX LIST  (Please locate/correct and then fax the following pages of the CRF)
                 BE SURE TO INITIAL AND DATE ALL CHANGES.

SUBJECT   CRF FORM & VISIT  PROBLEM
_____________________________________________________________________________________
2035      PLT 6, SEQ 0      (Missing Page)
2035      Form 2            Pulse beats/minute =  (Missing Value)
2035      Form 5, 3 Month   Other Medication names =  (Inconsistent)
                            This field should not be blank given the answer to the
                            previous question.
2035      Form 5, 4 Month   Number of Pills Returned = 45 (Other Problem)
                            This is the number of pills dispensed. If the patient
                            took none of the study medication a compliance problem
                            report is required.
2035      Form 8, Page 1    1. Date of Change =  00/JAN/2017 (Illegible)
                            Please print the day more clearly, was it 17 or 12?
_____________________________________________________________________________________
2049      Form 4, Page 1    2. Start Date or Duration = 02/000/2018 (Illegal Value)
                            This is not a valid date. Please correct or clarify.
2049      3 Month Follow-up (55 days Overdue)
2049      4 Month Follow-up (25 days Overdue)

QUESTION & ANSWER LIST  (Print your answer below each question and fax back this page)

SUBJECT   CRF FORM & VISIT  PROBLEM
_____________________________________________________________________________________
2035      Form 2 Baseline   Date of Birth = 30/05/48 (Inconsistent)
                            Age (53) on Form 1 does not match age (52) calculated
                            from date of birth (30/05/48) on Form 2. Please explain
                            the correction below and fax back this report along with
                            the corrected CRF page.




_____________________________________________________________________________________
2035      Form 7, 3 Month   Investigator's Signature = J. Smith (Illegal Value)
                            J. Smith is not a registered investigator. Please explain.

STUDY REPORT # 001-170724-01 for: Jul 24,2017 at 03:55:34 PM
TO: Jane Smith, Dundas Valley Medical Center

PLEASE NOTE:
The next BLOOD PRESSURE Study investigator's meeting will be held on Oct. 9-10,
2017 in Orlando, Florida.
Location and times will follow at a later date.

IMPORTANT!
We have not received any corrections related to the Quality Control reports we
have faxed 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.

Configuration Files Used By Query Reports

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

12|*|1

# TITLE AT THE TOP OF EACH PAGE OF AN EXTERNAL QUERY REPORT
<EXTERNAL font="^P12 fB">
ACE 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 QUERY REPORT: <NAME>  page <PAGE>  created: <YEAR>-<MON>-<DAY>
</INTERNAL>

# SUB-TITLE ABOVE 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. Re-fax all corrected pages. 
</REFAXLIST>

# SUB-TITLE ABOVE QUESTION & ANSWER LIST (Part 3 of a standard external Query Report)
<QALIST font="^P10 fB">
QUERIES: Print your answer below each question and fax back this page.
</QALIST>

<FOR site="#list">

<FOR site="1~19,30~300">
<TEXT font="^P12 fB">
_______________________________________________________________________

PLEASE DELIVER THIS DOCUMENT TO THE STUDY COORDINATOR

TO: <WHO>

Site <SITE>: <WHERE>
Fax <PRIMEFAX>

<DATE>

</TEXT>
</FOR>

<FOR site="20~29">
<TEXT font="^P12 fB">
_______________________________________________________________________

DONNEZ CE RAPPORT AU COORDINATEUR DE RECHERCHE, S'IL VOUS PLAIT

TO: <WHO>

Centre <SITE>: <WHERE>
Fax <PRIMEFAX>

<DATE>

</TEXT>
</FOR>

<FOR site="#list">

<FOR site="1~300">
<TEXT font="^P12 fB">
_______________________________________________________________________

PLEASE NOTE:
</TEXT>
<TEXT font="^P10 fCW">

The next study investigators meeting will be held at the time of the

American Heart Association meeting in Orlando, Feb 12-15, 2018.

The exact date and location is yet to be set.

</TEXT>
</FOR>

<FOR site="1,4,22~24,127">
<TEXT font="^P12 fB">
_______________________________________________________________________

IMPORTANT!
</TEXT>
<TEXT font="^P10 fCW">

We have not received any corrections related to the Query Reports we have faxed

to your site over the last 2 months. Please try to resolve the outstanding

data queries as soon as possible. Some of this information is very important.

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>

Options

Examples

-c 15 21~24 -i rq

-o 30

-f stat.911015 -i s

-p 3