Yes. Date fields can be included on the missed visit plates but they must not be defined using the special VisitDate style. The VisitDate style is reserved for dates on which subject visits actually occurred. By definition a missed visit does not have such a date. Misuse of the VisitDate style may lead to incorrect visit scheduling and overdue visit queries.

Yes. If you define a style for a choice field DFsas uses the style name as the value label name, but if the default SimpleChoice style was used DFsas must make up a value label name on the fly each time it creates a SAS job file, and it does this by sequentially numbering the names it creates, i.e. F0001v, F0002v, etc as it encounters each SimpleChoice field in the DFsas job file. So the solution is to always define a style for each choice field.

When setting up a study we recommend defining the missing codes you want to use in the Missing Map dialog in DFsetup. If this was not done you can get DFsas to recode the missing value codes using the MISSING global statement. For example: ‘MISSING all .’ will change all missing value codes to the SAS default which is a dot, and ‘MISSING all’ will change all missing value codes to a blank.

The conditional maps are used by Schedule View in DFexplore to identify overdue visits and missing plates – they are not used to control what appears in the subject binder. You can however control which visits and plates are displayed when a subject binder is opened using the special purpose edit check DFopen_patient_binder() and the edit check function dfneed() to control the display of visits and plates. You can also dynamically display new visits and plates when a user saves a data record by invoking dfneed() in a plate exit edit check.

NORMALIZE Visit "Visit Code" Item "Item Number" Indication "Indication" Medication "Medication" DateStart "Date Started" DateStop "Date Stopped"

RECORDS 16 6 10 13 9 14 15 6 18 21 17 22 23 6 26 29 25 30 31 6 34 37 33 38 39 6 42 45 41 46 47

To create a single task set in DFexplore containing all data records with pending queries and reasons use Select-By Data Fields in Data View as follows:

1. for Search check Reasons, then check Status Pending and click Build Set
2. next check Search Queries, open the Details section, click Pending and then Done
3. then select Add Set to merge the Query and Reason sets
4. finally select Done – the task set will then appear in DFexplore

To review the pending metadata select Field-Approve Queries and Reasons and position the dialog beside the main DFexplore window. This dialog shows only pending metadata. It allows you to edit or resolve pending queries, approve or reject pending reasons, and then save the changes. You can traverse the task set using the arrow buttons at the bottom of the DFexplore window without closing the Approval dialog. However, if you need to add a new query at any point you will need to click Done to close the Approval dialog and then select Field-Add Query – currently these dialogs can not both be open at the same time.

A DFdiscover server waits for 4 minutes before assuming that the connection has been lost for good and that the lock can be released. This allows DFexplore to preserve sessions in the face of brief internet disruptions, but it means that users who lose their connection will have to wait several minutes before attempting to reopen the same subject binder.

When a scanned document (fax, TIFF or PDF) arrives, DFdiscover first looks for a barcode at the top of each page. If a valid barcode is found the page is passed to the ICR module which reads the data fields and creates a data record. These records are stored in the DFdiscover ‘New Queue’ until someone retrieves them using DFexplore Image View, reviews the data and saves the data and each document page to the study database.

If a page does not contain a valid barcode or the barcode cannot be read, the page is stored in a separate folder until someone reviews it and identifies the keys (study#, plate# and visit#) using the DFexplore Image Router. After such a page is identified it is passed to the ICR module for processing and the data record is added to the DFdiscover ‘New Queue’.

ICR works by first locating the boxes around a data field and then trying to read what is printed inside them. If it can’t interpret the strokes inside any of the boxes making up a field it leaves the entire field blank. Thus, crossing out a field typically results in it being left blank, but it is also might lead to a misreading of the field. In either case it’s up to the user reviewing the record in Fax View to correct the data value for such fields before the record is saved to the study database.

This can’t happen when a site performs EDC using DFexplore but may happen (and practically cannot be prevented) on a paper form. When ICR sees more than one response for a choice field it leaves the field blank. The user reviewing the page in Image View might be able to tell that a correction was made and thus complete the data field with the intended value before saving the data record. If the correct value is unclear the user can leave the field blank and add a query asking the site to correct and submit the page again.

When the user reviews a retransmitted page in Image View DFexplore displays a dialog to notify the user that this is a new copy of an existing CRF page. When the user clicks ‘OK’ in this dialog the ICR is typically discarded and the existing data record is displayed in the data window. The user then compares the data record with the new CRF and corrects data fields as needed before saving the data record back to the study database. 

However, if the user has selected the ‘Merge’ ICR option in the DFsetup Plates dialog, the ICR values are retained for any fields that were blank in the data record brought forward from the study database. This can be useful for CRF pages that are filled out over time and retransmitted after each addition, e.g. a log form with multiple sections for drugs, events, etc. In either case it is important that the user compares the data record with the CRF page and makes any necessary corrections before saving the data record to the study database.

ICR reads a VAS field by measuring the length of the VAS scale (in pixels) and then determining the pixel at which the subject’s stroke crosses the scale. The measurement can then be calculated using the proportion of the distance along the scale at which the stroke occurs. This adjusts appropriately for both shrinking or stretching.

• In the DFsetup Plates dialog make sure ICR is turned on for this plate
• Was the file imported in DFsetup a little wider or narrower than the printed version of the plate that is being filled out and transmitted from the sites – they need to be identical. You can print and superimpose them and use a window or lightbox to determine if they are identical.
• Does this plate have anything in front of the visit or patient ID key fields that might be preventing ICR from locating the field boxes – lines, shading or text.
• Is there an undefined data field sitting in front of the visit or patient ID key fields? ICR uses a wide search area when looking for the first field on the page to allow it to adjust for any stretching or shinkage. If it thinks an undefined field is the first field it will assume the page has shrunk and adjust all field searching accordingly.

• Was the field created using the box sizes recommended for ICR in the DFsetup User Guide?
• Does the box location in DFsetup match the location in the faxed CRFs using a light box test?
• Are the box edges so thin that there are dropouts in the faxed image that might prevent ICR from clearly tracing the box edges?
• Are there any elements (text, graphics or shading) in front of the data field that might prevent ICR from finding it?
• If the field is comprised of more than one box were they clicked in the correct order (left to right, or top to bottom) when the field was defined?
• Was the field type correctly specified: number, date, check, choice or string?
• Is it a string field – ICR does not read text?
• Is the field format correctly specified?
• Is the field legal range correctly specified?
• If the field contains pre-printed digits in a single rectangular box, is there at least 2 pixels between each digit and are the digits in a font readable by ICR?

To delete a data record you must have permission to delete both the data record and any metadata (queries and reasons) associated with that record. Make sure you have all the delete permissions enabled in your study role.

When you change the keys on a data record DFdiscover creates a new record with the new keys and deletes the old one. The same is true for any metadata (queries and reasons) attached to the data record. So in addition to permission to delete data records you also need permission to delete queries and reasons.

• get, modify and save all data records at all levels
• create, modify and delete data, queries and reasons
• export and import data
• use DFexplore Reports View and to run DF_QCupdate

When defining the study role select the middle state in the check box for permission to modify data records. This allows users to change the status and level of a data record when they save it but blocks them from modifying data fields.

Yes. The Pending save button will be inactive if a user does not have permission to write data records to level 0.

DFdiscover uses the VisitDate style to identify the dates on which subject visits occurred, and expects the order of visits in the study visit map to correspond to the order in which subject visits occur.  Thus the latest visit in the visit map with a VisitDate field will be reported as the subject’s last follow-up visit. Adverse events are typically listed near the end of the visit map and so will be listed as the last follow-up if they include a date defined with the VisitDate style. To prevent this from happening you should not use the VisitDate style for dates on the Adverse Event plates. In fact, you should never use the VisitDate style to define any date that you don’t want DFdiscover to use in the subject scheduling report.

As long as the data fields are located in the same position relative to the barcode registration line on both CRF versions, it does not matter which version of the CRFs you use to setup the study. It also does not matter which version of the CRFs you receive by image from the sites. To ensure that data fields are at the same locations on the A4 and US Letter CRFs, it is a good idea to perform a light box match as a test. 

This is relevant only for studies in which DFdiscover receives an electronic image of the paper CRF and needs to read the data from that image. For EDC studies, this is not relevant.

1. using the Hidden field property in DFsetup will hide the fields from any user who has a study role that can not see hidden fields, or
2. edit check function dfaccess can be used to mask or hide fields from specified users or study roles.

MyFax (also known at ProtusFax) has a visual admin interface for users to monitor their fax traffic as well as a server interface that DataFax/DFdiscover uses for communication. Your MyFax account credentials allow you to see fax traffic in the visual interface. Those same credentials are used by DataFax to receive and send faxes. What has likely happened is that your new account password was applied in one place but not the other. 

To notify DataFax of the new password, use DFsystem/DFadmin. After login, choose the Traffic tab and then the Outbound pane. The Fax Service will already be set to Protus. Confirm that the User ID is correct and then enter your updated account password in the Password field. Save the changes. 

Your recently received faxes will resume their flow to DataFax for receipt processing and ICR. Note that faxes which were received more than 96 hours (4 days) earlier, will not automatically be forwarded by ProtusFax to DataFax – you will need to submit those manually in the MyFax interface.

DFdiscover is our updated name for DataFax. 

DataFax was created in the early 1990s as a software solution to increase the quality and timeliness of data collected for clinical trials. It’s novel approach was built around fax technology for efficient two-way communication of CRFs. The spirit of that solution has grown over the years to include additional methods of communication including email, document scanners, direct data import and electronic data capture. The effectiveness of DataFax continues to this day, renamed in 2016 to DFdiscover. 

DFdiscover’s edit check language is feature rich, facilitating the identification and handling of almost any condition that may occur in your clinical trial data or execution. It is far more advanced than the drag-and-drop edit check builders in other products. Writing edit checks for DFdiscover is programming and as such users will benefit from training and experience. There are few shortcuts. We do make available several resources which will increase your understanding and efficiency while writing edit checks. These include: 

• extensive programmer documentation 
• a global edit checks library containing examples for your learning and use
• webinar-based learning
• responsive, personal support
• Finally, it is also easy to get started.

Edit checks can be added as your comfort and expertise increases. DFdiscover includes a batch mechanism, making it easy to retrospectively apply new or modified edit checks to existing data.

1. All access to DFdiscover is restricted to users with valid credentials. These credentials include a verified username and password that are assigned and controlled by a secure DFdiscover administrative account. Requirements are set for password complexity, validity period and if users can individually reset their accounts.
2. User credentials may optionally require Two-Factor Authentication. This is also controlled by the administrative account.
3. Study / database administrators assign roles to user accounts, allowing access to the minimum amount of data and features for the user to fulfill their study role.
4. All user-initiated changes to study data are centrally and separately logged with a username and timestamp.
5. All communication between any DFdiscover user client application and the DFdiscover server is over a direct, encrypted communication channel. The client can always confirm validity of the server that they are communicating with. Communication uses only the most current TLS protocol versions and industry-standard ciphers.