DFUG 2000

1. a quick overview of the setup basics
2. CRF design tips
3. Date handling
4. Setup tool tips
5. Files involved in the QC report process
6. Visit maps
7. Defining data validation tasks/roles
8. Using DataFax reports
9. Testing plate and variable definitions
10. Using cron to automate routine tasks, and
11. Edit checks

Do you want the functionality of the edit checks language without the interactive environment of the validation tool? Do you need to re-apply your edit checks to all of your existing data? Then you need batch edit checks.

This presentation will cover:

1. What are batch edit checks?
2. Implementing batch edit checks
3. Examples of batch edit checks
4. Applications for batch edit checks

XML has received more than average press as a better HTML. Why is this - there must be more to it. Can XML be the next saviour?

This presentation will focus on the emerging standards involving XML and how they will affect not only web publishing, but also document content, data storage, and data exchange. The questions answered will include:

1. What is XML and why all the hype?
2. What is the industry doing with XML? the CDISC initiative
3. What is CDSI doing with XML?
4. What are CDSI's plans for XML in the future?

DataFax 4.0 is being planned as a significant upgrade in functionality to DataFax 3.X. As a proof of concept testbed for these new functional areas, DataFax is developing the DFlite tool.

This talk will present DFlite in the contexts of:

• Project goals
• Remote access support
• What can it do for me?
• How does it fit into the existing and future DataFax systems?
• Demonstration

It is evident that internet e-mail is emerging as the next commonly used communication tool. Many clinical investigators have the same easy access to an e-mail connection as they have to a fax machine.

One of the best parts of the DataFax systems is that no special equipment is required at the clinical sites. A G3 fax machine is all that is needed. However, for a large DataFax installation (many studies and investigative sites) the yearly telecommunication costs might be considerable. Secondly, because of the progress in e-mail technologies there seems to be little innovation in fax based solutions.

Since the release of version 3.4 DataFax is capable of receiving CRF pages (TIFF format, 100 x 100 dpi) that are sent by e-mail. At the sites, CRFs must be scanned and e-mailed to an e-mail address provided by the sponsor. On the receiving end the sponsor system must allow e-mails to reach user 'datafax' at the UNIX server.

Recently we have tested at Thorin a new user-friendly device from Hewlett-Packard, the HP 9100C digital sender. The digital sender connects directly to a network, allowing people to send paper documents without the need for a dedicated PC to any e-mail address. The resolution of the TIFF files transmitted by the digital sender is 300 x 300 dpi. This required a modification of the DataFax inbound programs to convert the incoming digital sender pages into files of 100 x 100 dpi before further processing. After successful testing, one digital sender is now installed at the subsidiary of one of our DataFax clients. There is will be used by the local monitors to send DataFax CRFs which have been collected at the sites to the company HQ.

There are some limitations to the use of digital senders at the average clinical site. It is not a stand-alone internet connected e-mail device. The device should be installed in a network which includes an e-mail server. As a next step we are exploring the possibilities of using a PC scanner based solution bundled with scan/e-mail software to send DataFax CRFs to the sponsor. This should be a low cost "one touch" solution that matches the user-friendliness of the standard fax machine.

As all Datafax users know, designing a new DataFax study starts with designing the CRF. At Thorin, we have added a step before this. Using a program build in Access (called XS2DataFax), we first start with designing the study outline. First step is selecting Plates from a library of standard plates or adding new study-specific plates to the new study. Next step is defining all of the Visits in a study. After that, by adding Plates to each Visit, we create the CRF-layout for a study.

Once the CRF-layout has been defined, this information is used for different purposes:

• CRF design - it creates a report with the structure of the CRF: which Framemaker Masterpage has to be used for each Bodypage; - it creates a Frame macro which adds the correct Visit barcode to each bodypage; - it prints the barcode values on each CRFpage to visually check that the correct barcode has been assigned to each page of the CRF.
• Study Setup - it creates the Visit map, the Page map and the QC note sort order file; - if a standard Plate is used, it knows which Edit Checks or Lookup Tables are associated with a given Plate and automatically exports them to DataFax.
• Testing - using XS2DataFax we can create a test scenario to test QC reports, XS2DataFax automatically creates a test data set to simulate missing Visits or Pages.
• Documentation - after importing additional information from DataFax we can automatically create all of the DataFax Study Setup Worksheets.
• CRF Annotation - by importing the information contained in the DFtips file, it creates an Annotated CRF where each field is overlayed with a box with the Variable name.

We have experienced three advantages of using this program. Main advantage is better Quality Control. Since each piece of information is only entered once and used for multiple purposes, this has helped us in reducing the points of failure when designing new studies. Secondly, and related, the program has a lot of built-in checks and knowledge. For example, when creating a conditional plate map, it will check that the conditional plates are optional. And finally, it has helped us to limit the workload in creating a Validated Study Setup.

The HOPE study was a large (n=9,541), simple, randomized trial that utilized a 2x2 factorial design to evaluate the effects of two promising agents (ramipril, an angiotensin converting enzyme-inhibitor, and vitamin E) in preventing major cardiovascular endpoints. The study was conducted in 267 centres in 19 countries. A common close-out of all patients was to occur in November 1999. However upon recommendation of the independent Data and Safety Monitoring Board, the Steering Committee decided to stop the study six months early due to clear benefit with one of the two treatments.

This presentation will address some of the key issues for consideration when a large, long-term follow-up study is unexpectedly stopped early and will include:

• The effect on a factorial design when one treatment is stopped early
• Balancing the need for confidentiality of outcome information versus the need for informing investigators and patients
• Database considerations including unexpected and rapid revisions, urgent need to adjudicate all events, accelerated database preparation for final papers and regulatory submissions.

Visits in all surviving patients were completed in less than 3 months. Vital status was ascertained in 99.9% of all patients, event status was ascertained (and adjudicated) in 99.9%. Presentation of preliminary results occurred 19 weeks after study close-out began. Presentation of final results and publication of results occurred in the 29th week.

Although stopping is unexpected, there are efforts that can be taken throughout the study such as careful monitoring of data quality and patient follow-up, which lead to a better state of preparedness for such an event. These issues will also be discussed.

FrameMaker's powerful features can help you create complex DataFax CRFs which, in a few keystrokes, can be customized for a variety of purposes.

As SCHARP (formerly the HIVNET Statistical Coordinating Center) continues to expand with additional studies and new sites, we have used FrameMaker's advanced features to streamline CRF production and distribution. Conditional Text and other FrameMaker features allow us to use a single FrameMaker file as the template for a multitude of products: a DataFax-disabled draft or pilot CRF, a site-specific final CRF, a DataFax background screen with custom coding that is not printed on the sites' CRF, or a blank CRF background screen for annotated SAS reports.

In this User Presentation, I will highlight some of the challenges SCHARP has encountered in CRF design and production. I will present a basic overview of how FrameMaker's Conditional Text, Variable, and Import Format features work, and show examples of how SCHARP has used these features to create customized CRFs.

Attendees of this presentation will gain a basic understanding of:

• FrameMaker's Conditional Text, Variable, and Import Formats features
• how to temporarily disable the study barcode and signature line on a form not intended for data collection, such as forms distributed at large for review or pilot testing
• how to create site-specific forms which are customized with site name and site ID number
• how to plan and create customized DataFax background screens with items that are "invisible" to sites but which appear on the DataFax background screens

This session is intended to demonstrate how third-party tools, such as Brio Query can be used to access a DataFax derived database. Through this demonstration, it is hoped that attendees will gain insight into the use of On-line Analytical Processing (OLAP) tools for reviewing and analyzing data. We will show the usage of Brio Query against DataFax ASCII data.

Last year we presented a format for describing a complete DataFax study set-up that included study conventions, staff permissions and other items which are not currently stored in or reported by DataFax. This year we have developed a graphical user interface which simplifies end-user creation and duplication of such information, control over the creation of CRF images annotated with Field Numbers, and built-in review / verification of the MIF (Maker Interexchange Format) code produced. It also includes help messages, display widths, cutoff-year and date imputation now reported by DataFax 3.4. This tool is available to all DataFax users under a licensing agreement with Fred Hutchinson Cancer Research Center. By planning and documenting your study set-up, you can facilitate communication within your organization and anticipate issues before they become problems.

How does DataFax impact the landscape of clinical trials in reality? KeraVision, Inc. purchased a DataFax system three years ago to handle a Phase III Clinical Trial. This has since expanded to include international trials and market research. Besides having an impact on SOPs, CRF review and monitoring visits, DataFax helped redefine tasks such as source document verification and projects such as study close-out. Naturally, FDA guidance documents and GCPs had to be incorporated into this process.

This presentation will give answers and proved valuable tools from the perspective of a CRA who has lived through it all, from study implementation through bioresearch audits.

Many times personnel require access to the reports tool in DataFax, but are not in the office. The report tool desired provides information regarding the status of the study that, in short, is the barometer of progress. Current records levels and numbers of CRFs residing at each level are just some of the information one can glean from these metric driven tools. Many times, access to this tool is not possible. An intermediate tool, which allows access to the reports through a web browser, is therefore required. The linkage to the information helps provide the knowledge required for project managers, data coordinators, functional managers and senior management to gain access to the reports without having to access DataFax.

One of the key benefits of enabling the reports through a web browser is the gathering of studies. Through gathering/clustering, multiple studies can be accessed and their respective data can be merged together to allow for a high-level view of the study data. The web interface will allow traveling project managers to access their study information quickly and without hassling someone to run the reports for them. Quick responses to clients' questions can then be enabled. This information can be accessed via any standard web browser (IE 4.0/5.0) on any Internet enabled personal computer. In addition, this report information can also be accessed internally to help minimize network traffic and allow for better response time for users entering and validating case report forms. Special precautions must be taken to ensure only authorized users can access this information.

The mobility and usability of the reports provides a vehicle for ease of use across multiple studies. This web reporter will provide the mechanism required for today's busy employee to gain access to all DataFax report functionality without having to gain access to DataFax.

The SCHARP statistical center carries out a wide variety of HIV-related studies, some of which involve adverse experiences (AEs) that must be coded for analysis. In the past, the COSTART system has been used to perform this coding within DataFax. However, COSTART had many limitations so a new system was developed, using perl and perl/tk, to implement and automate coding of AEs into Medical Dictionary for Regulatory Activities Terminology (MedDRA). This implementation occurs at two points in the validation process: after second-pass data entry (automated) and at a higher-level AE review and final coding (interactive).

The interface between DataFax and MedDRA utilizes the capabilities of the DataFax edit check language and two Perl programs. During the second-pass data entry, a DataFax edit check, executed at plate exit, calls a Perl program that attempts to match the AE verbatim code (written at the site) with a MedDRA lower level term. If it succeeds, the program returns the corresponding MedDRA preferred term (PT) and system organ class (SOC) and these are placed in a DataFax pt/soc field. If no match was made, the program returns the string "No exact match" instead of the PT and SOC.

When the pt/soc field is entered during the higher level review and coding process, a DataFax edit check reads the value of the field and if it contains "No exact match", it automatically calls a perl/tk program consisting of an interactive windowing system designed to allow the user to select an appropriate PT. Otherwise, the edit check code displays a dialog box that asks the user whether they want to use the windowing program and if so, calls the program.

This program first attempts a "fuzzy match" where each PT is searched for any of the words in the verbatim code. Those that contain a matching word are displayed in a menu box for the user to select the appropriate one (if there are no results to the "fuzzy match", then all PTs are displayed). There are also other search options available within the program: search by SOC, search by word, and search by a word starting with a series of characters. While navigating between search options, each PT's complete mapping (higher level term, higher level group term, and SOC) is displayed as an aid in determining the most appropriate code for the AE. Once the user selects a term, the program returns the PT and SOC to DataFax and the edit check code places these in the DataFac pt/soc field.

After conversion of the DataFax data into SAS, the AE dataset can be merged with the MedDRA files (also converted into a SAS database) by PT. Since the PT is the entry point for the MedDRA system, the codes can then be classified in whatever way is deemed necessary, thus utilizing the flexibility of the MedDRA hierarchical coding system.

KeraVision has invested considerable resources in running training sessions for their Phase III clinical trial coordinators. The planning and preparation of these events has had the beneficial side-effect of internal training of clinical and data staff. The sessions have been received favourably and their efficacy has been demonstrated by relatively clean data collection and quick resolution of data which are "dirty" (in the DataFax sense!). The "state" of the database has, in turn, reflected well on DataFax and has led to its implementation outside of the traditional clinical realm. This presentation will review the structure of these training sessions as well as a brief discussion of departmental accretion via the DataFax medium.

It is standard procedure for centers conducting clinical trials to receive specific data quality feedback from their Clinical Research Assistant. Overall quality of data collection can be improved by periodic review of the database to identify problem areas that are common to one or more centers. Such a review process has been used to select examples for use in group training sessions at KeraVision. This presentation will outline how the material may be categorized and demonstrated to clinical staff.

A lot of documents, data sets, staff training records, and other information related to a clinical trial are collected in an electronic format from a variety of sources. With the web development, it is important and possible for all the data coordinators, clinical reviewers, investigators, and sponsors to get the relevant information through a single point. The goal of this presentation is to use web portal concept in clinical data and trial management and introduce web tools that we built to serve as a portal to access to DataFax and conduct e-business (e-research, e-service, e-audit, e-process, e-submission, etc.).

A clinical web portal includes but does not limit to the following aspects: profile, protocol, reports, audits, links, submissions, etc. The portal is based on a 3-tier architecture: database, web server and client browser. The backend database could be DataFax or any other relational database management system. Many tools are developed to help building such a portal. The web tools developed using Perl and JavaScript are interacted with DataFax through web server but also provide tools to convert DataFax plates into Oracle tables so that other advanced OLAP tools can be used. The interfaces that we will demonstrate include DataFax report runner, DataFax and Oracle Bridge, productivity reporter, journal file viewer, workflow forecaster, etc.

The dream of using DataFax remotely, over a slow, wide-area network is made possible with the configuration described in this presentation. This talk covers all of the hardware components and technical details needed to make this a reality.