Your Source For Information and Answers
This frequently asked questions list is maintained by the DFdiscover support team to document replies to frequent or novel questions from users. The contents are updated regularly. We welcome your suggestions for additional topics to include.
We have created a Missed Visit plate for the site to submit whenever a subject visit is missed for any reason. Is it OK to include a Visit Date field on this plate to record the date the visit should have occurred?
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.
When we changed a DFsas job to include another plate the name for one of our value labels in the output SAS job file changed from F0020v to F0021v. Is there a way to force DFsas to use the same value label name for each choice field in all of our SAS job files?
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.
We used the DFdiscover default *(asterisk) as the missing value code in our study, but SAS does not recognize this as a missing value code. What should we do?
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.
We have defined conditions for visits and plates in the conditional visit and plate maps, but all visits and plates always appear when subject binder is opened. How do we get DFexplore to hide visits and plates which are not required when our conditions are not met?
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.
We have a medication CRF that allows several drugs to be recorded on one page. I'd like to create a SAS data set containing one record for each reported drug. Is that possible?
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
I need to review the replies that investigators have written to queries and any reasons they have added to data fields. I want to get all records with pending queries and reasons in one task set and then either approve each pending query and reason or create a query asking the site for additional information. What's the best way to do this?
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:
- for Search check Reasons, then check Status Pending and click Build Set
- next check Search Queries, open the Details section, click Pending and then Done
- then select Add Set to merge the Query and Reason sets
- 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.
One of our DFexplore users had a weak internet connection and lost her connection to the study server. She moved to a room with a stronger WiFi signal and logged back but then could not open the patient binder she had just been working on because it was still locked. Shouldn't the lock have been released when she lost her connection?
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.
CRFs contain many fields where the user is instructed to select only one of the available response options. What happens if they mark more than one box?
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.
CRF pages may be corrected and retransmitted by fax or using DFsend. I do not want ICR on the retransmitted page to over-ride the data that has already been entered into the study database without someone reviewing it first. How does this work?
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.
CRF pages might be stretched or shrunk and thus our 10 cm. VAS scales might end up longer or shorter than 10 cm. How does ICR adjust for this?
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.
ICR works as expected most of the time but is failing to read any of the data on one of our plates. What might cause this?
- 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.
ICR reads most data fields but fails consistently on one particular data field. What might cause this?
- 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?
I have a Data Manager role that has almost no restrictions. However, in DFexplore 'Page-Delete This Page' is unavailable. How do I enable this permission?
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.
We reserve record level 7 for data records that have undergone the necessary reviews and need to be locked. We have therefore excluded level 7 from all user permissions. However, it appears that users cannot run DF_QCupdate unless they have access to level 7. Can you suggest a solution that would prevent level 7 records from being changed but allow users to run DF_QCupdate?
- 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
Our site monitors need to be able to add, modify and delete queries and change the status of data records to 'Incomplete' if they have added a query, but we don't want to give them permission to change any of the fields on the data records. Is this possible?
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.
We want DFexplore users to select Final or Incomplete when they save a data record. We never want them to use the Pending status. Is this possible?
Yes. The Pending save button will be inactive if a user does not have permission to write data records to level 0.
I need to restrict DFexplore access for study monitors to allow them 1) to view all data and queries, and 2) to write, modify, and resolve queries on records at any level, and 3) save any changes to level 4 only. How should I go about doing this?
When Query reports are generated it seems that if a subject has had an Adverse Event, the Adverse Event date is always displayed as the Last Follow-up visit on the report. Why is the Adverse Event date being displayed instead of the date of the subject's last follow-up visit?
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.
I have a study for which I have both A4 and US Letter-sized CRFs. Does it matter which size I use to import CRF backgrounds into DFsetup?
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.
We need to increase the size of a numeric field from 4 to 5 digits. I have changed the CRF so that the field now consists of 5 boxes instead of 4. However, there are already many records in the database containing data for this field. When I make this modification in DFsetup will the existing data be preserved?
We are revising some plates for an ongoing study and want to remove several data fields. However, most of these fields contain data in the database. Can we safely delete these fields from DFsetup or is there a different way we should handle this modification?
- 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
- edit check function dfaccess can be used to mask or hide fields from specified users or study roles.
DFexplore shows the data fields I've defined for one of our CRF plates, but the CRF background is not being displayed, even though I can see it in the DFsetup tool. How do I get DFexplore to use the CRF background I imported?
We recently updated the account password for our MyFax account. However, now we are unable to receive faxes into DataFax. How do I fix this?
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.
- 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.
- User credentials may optionally require Two-Factor Authentication. This is also controlled by the administrative account.
- 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.
- All user-initiated changes to study data are centrally and separately logged with a username and timestamp.
- 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.