DFUG 2005

The 2004/2005 DataFAX User Group (DFUG) Audit team was chartered at the 2004 DataFAX User's Group Meeting. The team, which consisted of one member selected by each of seven interested organizations, conducted a software vendor audit of Clinical DataFAX Systems, Inc. (CDSI) on November 9-10, 2004. The audit scope focused on the development practices and controls employed during the development and quality assurance testing of DataFax, Version 3.7.

The team did not identify any conditions, practices or processes that would adversely affect the integrity of any clinical trial, but made observations which have been categorized in terms of importance. It was concluded that, while issues were identified which should be corrected in a timely fashion, DataFAX version 3.7 was developed and manufactured with adequate level of quality for application in clinical operations governed by GxP and other applicable regulations.

The full text of the report is available.

As a study gets close to the end there are a number of steps that must be completed before sites can be closed and database lock can occur. Depending on the study these steps will include some or all of the following: completing patient final visits, cleaning data and ensuring there are no outstanding queries, coding data, reconciling SAEs, adjudicating endpoints, verifying lab normal ranges and completing a comparative review of the CRFs at the site.

As these steps are completed it is important to identify the sites that are ready for close-out visits so that database lock can occur in a timely manner. Tracking all of these steps can be over whelming for a large study with multiple sites. In order to address this need we developed a clean patient tracking process to manage this crucial stage of a large multi-site and multi-national trial.

The inspiration for this process came from a presentation by VaxGen at DFUG 2004 entitled "Approaching Database Lock". We have made some modifications to the solution presented by VaxGen and will share our experience with this process.

Our "Clean Patient Tracking" approach was developed to accommodate a complex trial that had data being managed by highly specialized teams within our department. In order to minimize the amount of programming outside of DataFax, a clean patient CRF was created and setup in the study database. Each person responsible for his/her area, identified the criteria that would deem a patient clean. These criteria were then used to create data retrieval files which identified a patient that could be marked as clean. In addition, edit checks were created to control access to the clean status fields and study specific reports were used to monitor changes to data after a patient was declared clean. Changes to the clean patient status fields are tracked by the DataFax audit trail and the data are exported to SAS with all of the other plate data during our regular exports.

The advantage of creating a CRF for this clean patient tracking process has allowed all team members to enter and update clean patient status fields and run clean patient summary reports as needed on either a site or by-patient basis. We have been able to provide regular reports of our data cleaning progress of our sponsor. This process, as well as access to the clean patient data has also allowed us to identify bottlenecks in our own internal procedures and streamline our overall data cleaning processes.

When data discrepancies are discovered during a monitoring visit, how do they get recorded and tracked?

At Medtronic Gastroenterology/Urology, we have developed a process to record monitoring discrepancies as QCs in DataFax. By using this process, we are able to track and report these discrepancies along with system-generated QCs.

The process starts with a special "Monitoring QC" plate that is used to record the details of the discrepancy. This plate captures all the information necessary to create a QC (plate, variable, problem code, etc.). The plate is not printed; rather it is implemented as a PDF form that can be completed electronically.

Our monitors take the PDF form with them on their laptop computers. At the site,they fill out QCs without being connected to DataFax. The next time they connect to the network, they fax in the pages without having to print them.

When the Monitoring QC pages are validated in DataFax, an edit check uses the data to create a new QC on the discrepant field. This is done by calling a Perl script which ultimately uses DFImport.

In this presentation, I will step through this process including the code of the edit checks and Perl script.

A major concern of our data management staff is reconciling what is entered on the CRF vs. what ends up in the SAS data sets. Mapping the data from the SAS data sets to their origin on the DataFax screen can be a very tedious process. We have developed a set of utilities that automates this process. It consists of two main components: a PERL script that creates the annotated CRF and a SAS application that creates the patient profile report. This talk will be geared to both data managers as well as technical people.

The ACRF PERL script generates a text document based on the SAS proc contents and the DFSAS job files. Each record ACRF text file contains attributes for each variable on a plate-by-plate basis. These variable attributes are used by a SAS program to create a report for our data processing staff. This report allows for the verification that what is entered on the CRF is what is in the SAS data set. The report is designed to match the flow of the CRF book. The end result is a patient profile generator that is quick to set up and works for all DataFax studies.

DataFax journal files are unexposed golden mines in DataFax system. It records when images arrive in the systems and who did what at what time. The journal files are the most important audit trail for the lifespan of CRF fax image and CRF record, but they are the least used and reported files in the DataFax system.

The Clinical DataFax System Inc (CDSI) provides two reports: DF_ATfaxes and DF_ATmode. They are helpful in tracking and reviewing individual faxes and changes but could not provide detailed records and get high level reports from the rich data contained in the journal files.

This presentation will introduce the DataFax journal file viewer (DFjfv) that we developed and the ETL (extract, transform and load) application that we developed and used to build our audit trail data warehouse. The DFjfv is a web-based interface allowing users to retrieve journal file records by study, DataFax user, record type, record keys (PID, plate, visit, image id, status, and validation level), time range, and any field and its value.

The ETL application is a Perl module which can be easily used. As we know each plate in DataFax has different number of fields, and they may have different type definition for the same fields in different studies. The ETL application only extracts 18 common fields from the journal files and builds the columns consistently for the audit trail data warehouse. With the audit trail database, we can generate various reports to show the history of the CRFs and productivity of DataFax users.

The Statistical Center for HIV/AIDS Research and Prevention (SCHARP) provides clinical and statistical coordination for HIV vaccine and prevention studies taking place in both domestic and international settings. With dozens of concurrent studies in as many countries around the world, SCHARP has a peak incoming volume of approximately 70,000 pages per month.

With such a high incoming volume from a large number of sources, we have placed a priority on developing new tools to assist us with day-to-day maintenance, and to identify problems quickly, so they may be rectified before becoming acute. The latest of these tools is the logViewer.

The logViewer is a collection of Perl and shell tools that:

1. Allows the user to view the fax_log in real time with a web browser.
2. Displays the important information sorted in legible columns.
3. Translates the fax-machine ID information into a user-readable description (with the help of a configuration file).
4. Allows the user to browse the actual pages of a fax, with each page legibly displayed as a JPEG image (with the help of ImageMagick graphical utilities).
5. Sort the display by fax-machine ID, so you can view the log entries exclusive to a single site.

Having immediate, legible access to the fax_log can allow DataFax administrators and users achieve a better understanding of their incoming data flow, and the ability of viewing the content of actual faxes online proves to be an invaluable aid in troubleshooting the data-flow process in a timely manner. Additionally, the logViewer was built to integrate with our other data-flow monitoring tools, which altogether provide a complete, detailed picture of our international, around-the-clock data-flow dynamic.

This presentation will talk about the logViewer, how it works, its benefits to DataFax administration, and the role it plays in SCHARP's data-flow management process.

Synteract is a leading provider of clinical research services to the pharmaceutical and biotech industry. As a Contract Research Organization (CRO), we are often asked to provide clients with live access to their data. With DataFax, there are inherent problems that make this difficult. Record locking and security are among the top issues. In addition, more and more frequently, clients are requesting the ability to print remotely from DataFax.

Synteract has provided its clients with remote access for nearly 6 years. Our latest addition is a dedicated DataFax server running Citrix for UNIX. This provides our DataFax clients with DFlite for quick access and remote printing, all via a web browser. In this presentation I will outline our remote access solution to DataFax, and how it has evolved over the years.

SynCapture - Multiple Data Capture (MDC) is a proposed system that allows for a clinical study to be performed using the following modes of entry: paper, fax, and electronic. For one study, a mode of entry can be assigned to each site within the study, depending on the qualifications of the site. This allows for better handling of site logistics when setting up a study. Hypothetically, within the same trial, a site without an Internet connection can use paper or fax CRFs, while a site with computers and an Internet connection can use electronic (web-based) data entry.

MDC acts as a central interface (or gateway) to studies with multiple modes of entry. There is only one database developed for these multiple-mode sites, and this database is the central data repository. The underlying database engine of the system is the DataFax system, which takes full advantage of the fax and DDE capabilities already built into the software. The MDC layer adds in the web-based mode of data entry and management.

Other features of SynCapture-MDC include development of one set of edit checks (converted for use with web data entry), electronic sign-off of forms, data imported from web directly to DataFax database, and patient/query/report management functionality built into the web interface.

We will present the results of the DataFax-EDC Pilot study. The presentation will include details about the study, the computing configuration, the clinical setting, and most importantly, the error rates, validation cycle times and user acceptance. We will also present the new features in DataFax-EDC and announce the availability of DataFax-EDC.

Purpose: To investigate different avenues of CRF design to improve ICR functionality in DataFax.

Methods: A CRF was developed to capture the CDC classification of pediatric HIV patients. These categories were summarized in a table format. Two versions of the same form were then defined in DataFax: one version with the table ruling visible and the other without. After plate definition, different forms were then faxed into the database to test the behavior of the ICR with 10 boxes randomly ticked. Twenty plates with a visible table ruling and 20 plates with an invisible table ruling were faxed to the defined plate with a visible table ruling. Likewise, 20 plates with a visible table ruling and 20 plates with an invisible table ruling were faxed to the defined plate with the invisible table ruling. Further investigations were then launched by faxing 20 plates where the table ruling was dotted and 20 plates where the table ruling was in 50% grayscale (to a defined plate with invisible table ruling). Outcomes were assessed by the 'hit rate' (number of correctly identified/read tickboxes).

Results: The 20 plates with a visible table ruling faxed to the defined plate with a visible table ruling showed a 91% hit rate, while the 20 plates with an invisible table ruling showed a 99% hit rate. The 20 plates with a visible table ruling faxed to the defined plate with an invisible table ruling showed a 90% hit rate, while the 20 plates with an invisible table ruling showed a 99% hit rate. Additionally, the 20 plates with the dotted ruling table showed an 89% hit rate and the 20 plates with the 50% grayscale ruling showed a 92% hit rate. The ICR had the highest number of missed ticks/fields on the top right corner of the CRF where the table ruling was visible. The highest incidence of inappropriately added ticks was among the plates where the table ruling was dotted.

Conclusions: Using tables with visible ruling decreases the hit rate of the ICR and in turn, increases overall workload. Although tables are still extremely useful in CRF design it is suggested that rulings should either be invisible or at = or < 50% grayscale.

Validation. Just the thought of it makes one cringe. Validation can be both time consuming (read "expensive") and a pain at the same time. If the validation is not done correctly, a company can be exposing itself to a huge risk. We have developed a validation procedure that takes some of the validation "pains" away. There are three major components to our DataFax validation procedure: the Installation Qualification (IQ), the Operation Qualification (OQ) and the Production Qualification (PQ).

The IQ focus is on the DataFax server and hardware components. Our DataFax administrator runs the IQ. The OQ concerns itself with the features and functions of DataFax. A major component of the OQ is the DataFax ATK. We have created additional tests to incorporate the full set of features that we routinely use. The PQ checks that DataFax functions as expected within the environment of intended operation for pre-defined and/or user-specific parameters. It performs checks on our studies that are currently running, i.e., DataFax integrity reports as well as snapshots of study data before an upgrade and after an upgrade. Documentation practices will also be discussed.

Good system administrators constantly monitor the status of their computer systems. Any DataFax administrator can explain the significance of the number of new records received in the previous 24 hours or the successful completion of backups. Most habitually check those and other factors every day, but few leave any record of such vigilance. Few have even thought about how to do such a thing. But, it's time to start thinking of simple ways to create an audit trail of key system factors. Checklists are one such tool. Carefully constructed checklists can be used to demonstrate 1) that we understood the architecture of our systems and 2) that they were functioning as expected over time. By describing dependencies in advance and providing a place to quickly record the fact that significant requirements were met at regular time points, checklists can provide better evidence of validation than reams of GAMP--and at a much lower cost.

The MedDRA dictionary has become the standard for reporting and analyzing adverse event (AE) data. Since MedDRA is delivered as a set of ASCII files, a program is needed to load the MedDRA terms into statistical datasets for analysis, another to auto-encode AE's, and a third to provide a GUI interface to browse for and select the appropriate code for a given AE. The auto-encoder and GUI interface need to be usable from within DataFax and may also be needed for processing a list of AE's from legacy data. The Clinical Coding Software (CCS) package has been developed to meet these needs.

CCS is a Unix-based, Perl/PerlTK program that contains both an auto-encoder and a browser. The auto-encoder receives the AE verbatim (written at the site) as a parameter and attempts to match it with an existing low level term. If a match is found, the auto-encoder returns a string containing the match type (in this case 'M' for match), the MedDRA version number, the low level term code, the low level term name, the preferred term code, the preferred term name, the system organ class code, and the system organ class name. If no match is found, it returns only the match type ('N' for no match) and the version number, with the remainder of the fields left blank.

The browser uses various windows and buttons to allow a user to search for and select the appropriate MedDRA low level term. It contains a variety of search modalities to narrow the list of low level terms and can display the entire primary MedDRA mapping for a given low level term (the user determines whether to set this on or off). The browser also receives the verbatim as a parameter and returns the same types of information as the auto-encoder.

The auto-encoder and browser can be called from within DataFax (integrated coding) or called from the command line to code a list of AE's contained in a text file (batch coding). The integrated coding is triggered from the AE plate using the DF Edit Check Language DFRun function to call CCS and pass the necessary parameters. The batch coding function is included for coding legacy data and will eventually (in a future upgrade) allow re-coding from an older MedDRA version to the latest version for delivery to the appropriate agencies. Both the integrated and batch coding allow for up to three levels of coding; e.g. auto-encoding, manual coding, and review. The user can define the coding levels according to their specific requirements.

The entire CCS package also includes sample INPUT statements to load the MedDRA terms into SAS datasets and sample DataFax edit checks for calling the program.

Planned future enhancements for the program are: synonym list processing, additional match algorithms to increase the auto-encoder hit rate, re-coding of older MedDRA versions into the most recent version, compiling into an exe file (so the user doesn't have to have Perl and Perl/TK installed), reports about version, settings, matching algorithms, etc., used by CCS (to accompany the data), a report of the individual AE's (and totals) to be re-coded for a MedDRA version upgrade, and the addition of a drug coding dictionary.

The product development team was using a demonstration copy of a software package to collect and analyze stability data for our company's product. The version of the demonstration software was about to expire and the product development team was trying to decide whether to purchase the software, or use other products available in house such as MS Access, SAS Frame or DataFax.

After analyzing what type of data was being collected and the method of collection, it became obvious that DataFax system could not only collect the data necessary for analysis, but was also a validated software system.

We created a test log book that is very similar to a patient CRF book. The test log book allows us to collect stability data for multiple lots and test conditions over the duration of the test protocol. If a test was not performed on schedule, it's easy to modify the test month from month 6 to month 7 without modifying the database. In the event of a re-test, we used a retest log that is similar to standard log pages such as Adverse Events or Comments. The data was downloaded into SAS datasets and then analyzed by our in-house statistician for eventual inclusion in our company's NDA.