DF_QCreports — Create Query Reports
DF_QCreports
{study}
[-i srqQPRc]
[-b v|p]
[-c #, #-#]
[-C #, #-#]
[
[-cd yy/mm/dd-yy/mm/dd]
| [-cd ]
]
[-f name]
[-q types,tag]
[-o #]
[-p 0|1|2|3]
[-e b|f|b1|f1|x]
[-l lastv|lastsv]
[-s no|yes]
[-P #, #-#]
[-S #, #-#]
[-T #, #-#]
[-v #, #-#]
[-V #, #-#]
[-F visitlist:platelist:fieldlist]
[-N "string1" "string2" ... ]
[-idfmt #]
[-dtfmt fmt]
[-probfmt 1|2]
[-rline]
[-rspace]
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:
Subject Status Summary. lists subjects and shows entry, last and next assessment dates
Fax/Refax List. lists data queries which require correction and retransmission of CRFs
Question & Answer List. lists data queries which require a written response
Cover sheets and messages. optional information which can be customized for each clinical site
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 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.
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.
This section of the report lists the subjects in the study and provides 3 subject scheduling time points. Each subject is described on a single line starting with the subject ID, which is tagged with an asterisk if the subject has any outstanding data queries, followed by the entry, last follow-up and next follow-up visits. An example is shown below.
Example 2.55. The Subject Status List
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
Each visit is identified by its page map label (as in the above example) or by the visit number if a label is not specified for the visit in the page map.
The visit displayed as the entry visit can be the first screening visit (as in the
above example), or the first scheduled or baseline visit from the first or most
recent cycle. This is selected using the -e option.
The last visit can be either the last scheduled visit or the last completed visit,
whether it was scheduled or not. This is specified using the
-l option.
The next follow-up visit is the next scheduled visit, whether required or optional.
Normally all scheduled visits are required, but it is possible, using the conditional
visit map, to indicate that a scheduled visit is optional.
The date format corresponds to the format used for visit dates,
but this can be overridden using the
-dtfmt option.
If the entry or last follow-up visit has been completed but the visit date is not
available, the phrase unknown is used.
If the entry or last follow-up visit has been registered as missed, or
a missed visit plate has been received for the visit, the phrase
not done is used.
If the entry visit has not yet been received, the phrase
overdue is used if the visit is overdue, and the phrase
pending is used if the visit is not yet overdue.
If the next follow-up visit date can not be calculated for any reason a
? is displayed.
The phrase done is used when there is no next visit
because all follow-up has been completed, or follow-up was terminated early.
This section of the report lists missing CRF pages, overdue visits, and data queries requiring a CRF correction or clarification. All of these problems are resolved by having the clinical sites fax the missing or corrected CRF pages to the DFdiscover system. In the case of corrected CRF pages, DFdiscover recognizes that the page is being resubmitted and allows the data management staff to enter the data corrections and resolve the data queries. All CRF images, old and new, are retained by DFdiscover and are available for review at any time. An example of this section of the Query Report is shown below.
Example 2.56. The Fax/Refax List
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)
The default fax/refax list, shown above, lists all queries for all subjects in a compact format that identifies the subject ID, the CRF page and/or visit and the problem. The CRF page and visit label come from the page map for missing pages and data queries, and from the visit map for overdue visits. If a label is not specified the plate and visit/sequence number are used. The problem type appears in brackets. For missing pages and overdue visits this is all that is needed, but for queries related to data fields the field must also be identified. This is done using the variable description as specified in the study schema defined using the DFsetup tool. The field description is followed by the current value of the field from the study database, if there is one. This is followed by the problem type and then by the query or explanation if one exists. In some cases, e.g. a missing value, the problem type (in brackets) is all that is needed to describe the problem and no additional query exists.
Overdue visits and missing pages are identified by DF_QCupdate and thus will only be accurate as of the the most recent execution of DF_QCupdate. For overdue visits the number of days the visit is currently overdue is shown if the visit due date is known. This is calculated using the visit due date calculated by DF_QCupdate and the current date obtained from the computer system clock on the date the report is run.
DF_QCreports includes a number of options that can be used to control the content and
format of the fax/refax list. In the example shown above the
-rline option was used
to draw a solid line between subjects. In addition,
queries can be selected by site, subject, visit, plate, type and validation level,
and each subject's queries can be put on a separate page.
This section of the report lists data queries which ask a question that requires a written response. In some cases these question and answer (Q&A) queries are created because we don't know which CRF page needs to be fixed and refaxed, and we need to know which page was corrected to resolve the problem (see the first query below). In other cases a Q&A query may ask for information that can not be collected by simply correcting and refaxing a CRF page (see the second query below).
Example 2.57. The Question and Answer List
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.
This section of the report is used to specify a cover sheet containing
headings and messages that can be customized for each site.
In the example shown below the report title has been customized to include the
date and time the report was created as well as the intended report recipient.
The cover sheet also includes a general message related to an upcoming
meeting, which would be included in the report for all clinical sites, and
another message that would only be included in the report sent to those sites
for whom this message was currently relevant.
This is done using the QCtitles, QCcovers and QCmessages
files.
Example 2.58. Titles, Cover Sheets and Messages
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.The visit map and other scheduling configuration files described in DFsetup Study Setup User Guide, Subject Visit Scheduling are used by DF_QCupdate to generate the scheduling information and queries for overdue visits and missing CRF pages, reported by DF_QCreports.
By default Query Reports identify queries by plate and sequence numbers.
These numbers can be replaced by more meaningful user-defined labels
using DFpage_map, which can be created using the Page map view in
DFsetup.
The purpose and use of DFpage_map is fully described in
DFsetup Study Setup User Guide, Page Map
MapsPagePage Map, and
its format is described in
Programmer Guide, DFpage_map - page map.
The sites database specifies the subject IDs belonging to each clinical site and the contact person, fax or email address and institution name for each site, all of which are used in creating Query Reports. It is important that the sites database be accurate and up to date. Always execute the DFdiscover report DF_QCupdate prior to creating Query Reports to ensure that the most recent sites database information is being used. Site information can be entered using the Sites view dialog in DFsetup. as described in DFsetup Study Setup User Guide, SitesSites, and its format is described in Programmer Guide, DFcenters - sites database.
Queries normally appear in a Query Report sorted by ascending subject
ID, by ascending visit number, by ascending plate number,
and finally by ascending data field number.
This sort order can be over-ridden through DFqcsort.
If defined, DFqcsort is used when Query Reports are created.
DFqcsort can be created through the Sort map view dialog in DFsetup.
The format of DFqcsort is described in
Programmer Guide, DFqcsort - Query and CRF sort order.
The following listing summarizes some of the capabilities:
12|*|1 (1) *|1|2 (2) 11|2|3 (3) 13|2|4 (4) 5|2|5 (5) *|2|6 (6) *|*|7 (7)
|
Queries on plate 12 of any visit appear first. | |
|
All queries for visit 1 appear next (order by plate number). | |
|
Then plate 11 of visit 2. | |
|
Then plate 13 of visit 2. | |
|
Then plate 5 of visit 2. | |
|
Then all remaining plates of visit 2 (ordered by plate number). | |
|
Finally, any queries that do not match any previous pattern are sorted in the default order of ascending visit number followed by ascending plate number. |
* may be used to match all visits for a specified plate, or to
match all plates for a specified visit.
In such cases queries are sorted on the unspecified field within the
specified field.
For example,
12|*|1
will sort all queries on plate 12 first. If such queries appear on plate 12 for 2 or more visits they will appear sorted by visit number.
Control is provided over plate and visit sort order only. Queries are always ordered by ascending subject ID, and by ascending data field number within each plate.
The standard title at the top of each page and above each of the 3 sections
of the report can be customized through the use of
the file QCtitles in the study lib directory.
This file can be created using the Query Titles view in DFsetup.
DF_QCreports checks for the existence of this file
and will use it if it exists; otherwise,
the standard titles are used.
The following example of a valid QCtitles file illustrates some of the
capabilities:
# 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>
The following rules are relevant to the QCtitles file:
Title specifications must be formatted exactly as shown.
The opening and closing tags for each section must appear on new lines by themselves
with no leading or trailing text outside of the tag.
Nothing can precede the "<".
No space is allowed within the opening and closing tag except before the
word font.
Anything entered outside of a tagged block is ignored.
A # character may be used to indicate a comment line
but # is not strictly needed, and has no special meaning
inside a tagged block.
For example, it is legal to include a line of #
as part of a title inside a tagged block.
Tags are only recognized if they begin the new line;
nothing can precede the "<".
No space is allowed within the opening and closing tag except before the
word font.
The font value must be enclosed in double quotes.
Limited font specifications may be included within the opening tag.
^P (control P, not circumflex P) sets the point size
(^P12 and ^P10 are recommended).
Available font types include:
fB for bold |
fH for normal helvetica |
fCW for constant width |
The font specification is optional.
Without it, font="^P10 fCW"
is used for internal and external report titles and
font="^P10 fB" is used for the sub-titles for the
three sections of the report.
The following variables may be included in the external and internal report titles which appear at the top of each page, but not in the sub-titles for the 3 parts of the report (status, refax and question & answer lists). The study name comes from the study configuration file maintained by DFadmin. The variables that describe clinical sites come from the sites database file maintained in the Sites view of DFsetup.
Table 2.2. Variables available for use in QCcovers, QCmessages, and QCtitles
| Variable | Use in External | Use in Internal | Meaning | ||
|---|---|---|---|---|---|
<STUDYNAME> | yes | yes | study name | ||
<SITE>
[a] | yes | no | site ID | ||
<WHO> | yes | no | primary site contact | ||
<WHERE> | yes | no | site affiliation | ||
<MAIL> | yes | no | site mailing address | ||
| yes | no | primary fax number (to which Query Reports are sent) | ||
<FAX2> | yes | no | secondary fax number | ||
<PHONE1> | yes | no | primary contact's phone number | ||
<PI> | yes | no | principal investigator | ||
<PHONE2> | yes | no | principal investigator's phone number | ||
<REPLYTO> | yes | no | email address to which replies made to emailed Query Reports will be sent | ||
<NUM> | yes | no | external report name composed of site ID, date (yymmdd), and page, e.g. 025-080115-01. | ||
<NAME> | yes | yes | external report name composed of site ID and date only, e.g. 025-080115 | ||
<PAGE> | yes | yes | page number of Query Report | ||
<DAY> | yes | yes | two-digit day of month | ||
<MON> | yes | yes | three-character month of year | ||
<YEAR> | yes | yes | four-digit year | ||
<WKDAY> | yes | yes | three-character day of week | ||
<TIME> | yes | yes | time of day (hh:mm:ss AM/PM), e.g. 01:12:22 PM | ||
<DATE> | yes | yes | date (ddd mmm dd hh:mm:ss yyyy), e.g. Tue Jan 15 14:34:07 2018 | ||
[a] The variable
| |||||
External report cover sheets can be included by defining them
in the file QCcovers in the study lib directory.
This file can be created using the Query Covers view in DFsetup.
A cover sheet begins with a
<FOR site="#list">
tag to identify the site(s) that are to receive the cover sheet whose definition follows. It is legal for some sites to receive cover sheets while others do not, and for different sites to receive different cover sheets.
The body of a cover sheet is defined in a <TEXT> block. Within <TEXT> blocks, variable substitutions may be performed as previously described for customized report titles. Aside from variable substitution, all other text appears exactly as formatted within the text block. Blank lines used to double space text will be preserved. The default font for cover sheet text is constant width.
Example 2.59. English and French version of a cover sheet
Sites 20-29 use the French version of the cover sheet, while all other sites use English.
<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>
If more than one cover sheet is defined and a site ID matches more
than one inclusion criteria specified by
<FOR site="#list">,
the TEXT blocks from all matching cover sheet specifications are
concatenated to form the Query Report cover sheet for that site.
Cover sheets may also include messages for all or specified sites.
Messages are stored in QCmessages of the study lib directory
and follow the same rules as QCcovers.
It can be created using the Query Messages view in DFsetup.
While messages could be added to cover sheets by putting
them in TEXT blocks within QCcovers, the use of a separate file for messages
makes it easier to keep the fixed, probably unchanging, cover sheet header
separate from the messages which will likely change throughout
the trial.
QCmessages may include more than one message, and each site may receive
none, some, or all of them, as selected by the
<FOR site="#list">
tag which must come at the beginning of each message. If a site is to receive more than one message, the messages will be printed on the cover sheet in file order.
It is not necessary to define a cover sheet in order to use messages. If a message is specified for a site which does not have a cover sheet, a blank cover sheet will be created onto which the message(s) will be printed. The default font for message text is constant width.
Example 2.60. Typical use of QCmessages
All sites (1~300) receive the announcement of an upcoming meeting. For sites 1, 4, 22 to 24, and 127 this is followed by an important message regarding their lack of response to data queries.
<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>
Example 2.61. Create reports with only Fax/Refax List and Question & Answer List sections for sites 15 and 21-24
-c 15 21~24 -i rq
Example 2.65. Create an internal subject status report using the first visit from the most recent cycle
-f temp -i s -e f
Example 2.66. Create an internal report including all internal queries plus external unresolved queries
-f sum -q I,eu
Example 2.67. Include the Fax/Refax List and Question & Answer List sections (but not the status list) and put Q&As on a new page for each subject
-i rQ
Example 2.68. Include a cover sheet and the Subject Status Summary for all subjects, and put all Refax queries only on a new page for each subject
-i csR
Example 2.69. Include the Subject Status Summary for all subjects followed by a new page for each subject with unresolved queries, with both the refax and Q&A notes together on a separate page for each subject
-i sP
Example 2.70. Include the Fax/Refax List and Question & Answer List queries (but not the Subject Status Summary) together on a separate page for each subject. Sequentially number the queries within subject ID and place the problem description first for each query.
-i P -probfmt 2
Example 2.71. Create a report for sites 10 through 15 only, containing only the cover sheet
-c 10~15 -i c
Example 2.72. Include only queries which are on plates 1 and 2 with sequence number 0 and which have reached validation levels 4 through 7
-v 4~7 -S 0 -P 1,2
Example 2.73. Create reports listing only the Fax/Refax List and Question & Answer List sections and that include only problem types 3, 4 and 21
-T 3-4,21 -i rq
Example 2.74. Create reports listing only refax requests on plates 1 through 13 inclusive that were created between April 1 and April 28, 2018
-cd 18/04/01~18/04/28 -i r -P 1~13
Example 2.75. Create reports for sites 11 and 23 through 30 inclusive that include only the Fax/Refax List and Question & Answer List sections
-c 11 23-30 -i rq
Example 2.76. Create an internal report named int that
contains query categories 1 through 6, refax and Q&A queries, for visit
3 and plate 11 only
-f int -T 1-6 -i rq -S 3 -P 11
Example 2.77. Create an internal report named int that contains
internal, unresolved queries of refax type
-f int -q iu -i r
Example 2.78. Create a report for site 10 that includes only the
Subject Status Summary section, subjects with ongoing follow-up, the entry visit
as the baseline visit, and the last follow-up
visit as any visit that has a Visit Date
-c 10 -e b -l lastv -p 1 -i s
To create the same report but using the last scheduled visit as the last follow-up date, use:
-c 10 -e f -l lastsv -p 1 -i s
Example 2.79. Create a standard 3-part Query Report for all subjects of Site 5 that have external, unresolved queries on field 9 of visit 0, plate 1, on all fields of visits 1-20, plate 5, and on all fields of all plates at visit 50.
-c 5 -F 0:1:9 + 1-20:5: + 50::
Example 2.80. Create an internal Query Report named monitor_rpt that
includes only internal queries having either or both of the strings
PI or COORD in their Note
field.
-q I -N "PI" "COORD" -f monitor_rpt
The following points are important to understand.
The content of Query Reports depend on DF_QCupdate.
DF_QCreports does not calculate the dates needed for subject scheduling
or identify the plates and visits that are currently missing and overdue.
All it does is report the results created by DF_QCupdate and stored in file
DFX_schedule in the study work directory. The only calculation DF_QCreports
performs is to update the number of days overdue for overdue visits recorded
in DFX_schedule.
Thus the reports created by DF_QCreports will only be as accurate as
DFX_schedule.
It is recommended that DF_QCupdate be run immediately before running DF_QCreports
when creating external Query Reports for transmission to the clinical sites.
Before running DF_QCupdate check internal consistency. DF_QCupdate has dependencies of its own and will only produce accurate results if:
the visit map and other configuration files used by DF_QCreports are up to date
all data received to date has been validated to at least level 1 in the study database
the key fields (ID, Visit, Plate) are correct for all records in the database
the VisitDate fields do not contain errors.
Corrections made to any of the files on which DF_QCreports depends take effect with the next batch of reports created after the corrections are made. However, since DF_QCreports only reads the output from DF_QCupdate it will generally be necessary to re-run DF_QCupdate as well. Before running either of these programs corrections should be checked for possible errors using DF_ICvisitmap and DF_ICschema.
If data remains in the new queue the Query Reports will not be accurate because some subject assessments, CRF plates and replies to previous data queries will not have been registered in the study database. As a result visits may be called overdue and plates may be called missing when in fact the sites have already submitted them. And queries, to which the sites have already responded, may be repeated. This can produce confusion and annoyance and should be avoided by scheduling the creation and transmission of external Query Reports at a time when all data received will have been entered.
If the database contains errors in the key fields, a visit or plate that belongs to one subject might be attributed to another, or to a subject that doesn't even exist, and incorrectly recorded visit dates can result in subject scheduling errors. Such errors are the bane of data management and procedures must be adopted to minimize their occurrence and catch and correct them when they occur. It is recommended that DF_ICkeys, DF_ICvisitdates and DF_PTunexpected be used before running DF_QCupdate to help identify such problems.
Database restrictions may limit a user's ability to create Query Reports . If a user has restricted database access, their ability to create Query Reports may be limited. The user is warned of such restrictions, if the exist, during execution of DF_QCreports.
Create and send at most one external Query Report per site each day. External Query Reports are named by site ID and date. As a result, there can be only one external Query Report per site per day. If DF_QCreports is run more than once on the same date it will overwrite any existing external Query Reports with the same name. It is not a problem to create an external Query Report, review it, perhaps correct some of the data queries, and then recreate the Query Report before sending it to the clinical site. However, before recreating external Query Reports on the same day there are 2 important limitations you must keep in mind.
If you use any of the selection options to limit which queries are written to the reports make sure you use the same options each time you recreate a report, or if you change the options, make sure you do so in a way that does not narrow the query selection criteria. Here's why.
When an external Query Report is created, the query fields which identify the current external report for each query are updated. These updates are never rolled back! Thus for example, if a report is created that contains all unresolved external queries, and then is recreated the same day using options that limit which queries are written to the new version of the report, some queries already registered as being in that report may not appear in the final version of the report created that day. To make matters worse, if the revised Query Report is then transmitted to the clinical site using DF_QCfax all of the queries DFdiscover thinks are in that report will be marked as sent, including any queries that were not written to the final version of the report. As a result the Query database may not contain the correct information regarding the most recent transmission of some queries. Then, if the -o option is used at a later date to specify that queries are not to be included in the report unless a specified period of time has elapsed since the queries were last transmitted, some queries may be omitted because they were mistakenly recorded as having been sent in the previous report.
Once an external Query Report has been scheduled for transmission to the site using DF_QCfax you should not create another external Query Report for that site until at least the next day. Here's why.
When a Query Report is scheduled for transmission using DF_QCfax DFdiscover makes a copy of the current version of the report and hands it off to the fax or email software (depending on how you deliver external Query Reports to each site). This is the version that will be delivered to the site. Once an external Query Report has been transmitted DFdiscover will block attempts to create another version of that report on the same day, but until then any new versions you create will overwrite the existing version. Such new versions will not be sent unless you run DF_QCfax again after creating them. But this does not replace the previous version and both will end up being transmitted to the site. You could schedule all Query Reports to go late at night and thus send many versions of the same Query Report to a site on the same day in this way.
In addition to confusing the clinical sites with more than one Query Report of the
same name, the other negative consequence is that only one ASCII version of the
report with the name ccc-yymmdd, for each site and date,
can live in the study reports/QC/sent
directory,
and it may not even be the one that was sent.
It will simply be the ASCII version of the report that existed in
the study reports/QC
directory at the time the last version of the report
to be successfully sent was being processed.
In general it is not a good idea to send external Query Reports to the clinical sites more than once a week, but in short studies external Query Reports might be sent daily. If it is necessary to send a second Query Report on the same day, it could be created using the internal Query Report option, and transmitted to the clinical site using DF_QCfax, but such transmissions are not recorded and the status of queries transmitted in internal reports are not updated in query records.
Do not rely on queries for Query Report history.
When external Query Reports are created
all queries which are written to the newly created reports are updated.
The query status field is changed to new, in report
and the fields which identify the location of the query in a report
(by report date, page and item number on the page) are updated.
When an external Query Report is sent to the clinical sites using DF_QCfax
the query status field is changed to sent.
These changes overwrite any previous values that existed in these fields.
Hence, each query holds information that can be used to identify the
most recent external Query Report to which it was written, but any prior report
history is lost.
Query history can however be traced using report DF_ATmods.
Use the -c and -C options carefully
.
The -c and -C options may be used together
in the same execution of DF_QCreports to specify that a subset of subjects
are desired for one or more of the specified study sites. However, it
should be noted that if a site is specified using -c and
-C is also used to specify only some of the subjects in
the same site, the -C option will be ignored because all
subjects from the site have already been requested with the -c
option. Thus, if a subset of subjects is desired, only the
-C option should be used and the same site should not be requested
with the -c option.
Use the -o option consistently.
The -o option is used to give the clinical sites a specified number
of days to respond to the Query Report before including the queries in a new one.
This works by checking the last Query Report date for all queries with status
sent.
However, if DF_QCreports has already been run without the
-o option, the queries
written to the newly created external Query Reports will have had their status
reset to new, in report and thus the
-o option will have
no effect on these queries.
To produce the desired effect,
the -o option must be used consistently in the creation
of DF_QCreports.
Use -F with -P and -S
options carefully.
The queries included in the Query Report will represent the intersection of these
specifications. For example, if the plate specifications in the
-P and -F options do not intersect (
-P 2 -F 0:1:8-15), no queries
will be included in the Refax/Q&A section of the report.
Run DF_QCsent manually if Query Reports are not delivered using DF_QCfax.
When DF_QCfax is used to fax external Query Reports, it automatically
runs DF_QCsent to
update the Query database, marking all queries in faxed Query Reports as sent.
However, if the Query Reports are distributed by some other means, this won't happen.
As a result, DFexplore will incorrectly show some queries as
in report, not sent, instead of sent.
Additionally, if the -o option is used to give the
clinical sites a chance to
respond to a previous Query Report before including the query on a new one,
DFdiscover won't know that these queries have been sent and thus will not wait the
specified period before writing them into the next external Query Report.
This limitation can be overcome by running DF_QCsent manually to register
Query Reports which are successfully transmitted to the clinical sites.
Only internal Query Reports can be created when in read-only mode. When the study server is in read-only mode, it will not be possible to make changes to the Query database, and will also, not be possible to execute DF_QCupdate or generate a full, 3-part external Query Report. It is possible, however, to generate an external Query Report containing only a cover page, messages, and/or the subject status summary as these do not modify the Query database in any way. Internal Query Reports can also be generated when the study database server is in read-only access mode.
Internal queries can only be included in internal reports. Internal queries are not included in external reports, and there is no option that allows this.
Resolved queries can only be included in internal reports. Resolved queries are not included in external reports, and there is no option that allows this.
Define cover sheets no longer than 1 page. DF_QCreports expects that the cover sheet and all messages will fit on a single cover page for each site. It does not create automatic page breaks. Also, it does not perform line wrapping on report titles or cover sheets. Each report title, section sub-title, and text block is printed exactly as it appears in the specification file. Be careful when choosing fonts and using variable substitution to ensure that text lines do not become longer than expected.
Make sure file QCmessages is still relevant.
Messages will continue to go out on each report until
the message file is changed.
If you want to keep a message for use later on, but do not want to
send it to anyone on the next batch of Query Reports, leave the site ID
string blank, i.e. use
<FOR site="">
Remove unsent Query Reports.
External reports will remain in the study QC directory
until they are registered as sent, at which point they are moved to the
QC/sent directory.
If a report is never registered as sent, the queries which it contained will
be put into the next external Query Report created for that clinical site.
The previously created and unsent Query Report then becomes irrelevant and should
be removed from the QC directory. This is not done automatically
and must be done manually by removing the file(s).
Failure to remove old external Query Reports may lead to
unanticipated results if DF_QCfax is run with the -a option.
This option requests the transmission of all unsent external Query Reports in the
QC directory. Thus, if this directory contains a lot of old Query Reports,
some clinical sites will receive a number of old and irrelevant Query Reports.