DFUG 2001

• the tools that are required to use batch edit checks,
• how they are implemented,
• implementation issues, and
• how batch edit checks can be extended to other uses.

The Statistical Center for HIV/AIDS Research and Prevention (SCHARP) focuses on HIV prevention research worldwide. In many cases, due to the nature of our research, our trials take place in some of the most remote nations on earth. Th e Information Technology group at SCHARP is charged with the task of designing data flow systems to transmit DataFax forms from field sites worldwide to our data management center in Seattle.

SCHARP employs several different data flow models beyond standard long distance faxing to receive images. Increasingly, SCHARP is using the Internet as a common carrier for the transmission of faxes. 2000 marked the first year in which SCHARP received more faxes using Internet transfer than with "conventional" faxing.

One particular data flow model in use at SCHARP makes use of a new breed of Internet-ready fax machines. These machines allow faxes to be sent and received both using regular telephone lines, and as attached messages to an Internet email address. SCHARP has found that certain machines can be used "out of the box" with out any special changes to DataFax.

SCHARP is discovering that these Internet-ready fax machines have applications beyond the collection of faxes from very remote countries. By eliminating the telephone line, many problems such as dropped connections, line noise, and fax quality issues are reduced. As well, in most cases, the Internet can be used to send a large number of pages at a fixed monthly cost, rather than a per page cost. This can save money over conventional long-distance faxing.

Adding network capabilities to a fax machine can provide new features and opportunities. This talk will explore in more detail some of the possibilities including regional fax forwarding, emailing QC reports to a fax machines, and remote programming. Also discussed will be some of the cost and security issues as well as some basic network requirements for the site or clinic.

Interfacing DataFax with SAS has several inherent difficulties:

1. If programming is done in a windows environment files will need to be FTP.d across
2. File references in the SAS file created by DFsas may not be the same as the location the SAS file is run from (although this is overcome with the latest version of DFsas)
3. The SAS file created by DFsas will create multiple warning and error messages if the .:o. (original) option is selected for dates and a partial date exists, the potential volume of these errors makes program validation extremely difficult.
4. DFsas uses the descriptive naming convention of .data001.sd2. etc. making dataset name standardization nearly impossible and disgruntling the programmers.

Although all of these problems can be circumvented it requires a multi-step process and at least a rudimentary understanding of both Unix and Windows environments. We found that this became a time consuming process diverting valuable resources.

Our goal was to simplify the process creating a single program that:

1. could be run from Windows
2. that would automatically interface with Unix
3. that would run the DFsas program
4. FTP the relevant files
5. make changes to the SAS program so that it will run cleanly from a windows environment and
6. run the SAS program

This makes it possible for programmers or datamanagers without Unix access to easily update the datasets and know that they have the most current data.

This presentation will summarize our goals with this process and give an overview of the techniques we used. Although the coding we used will be provided to users there will not be time to go into great detail about it.

Medtronic deploys a suite of tools for clinical study data management. The suite includes DataFax, SIR, ClinTrial, Oracle Clinical, MS Access and homegrown PowerBuilder/Oracle applications. For most of our clinical studies, a single software tool provides the data management support. For one study however, we successfully manage clinical study data using both DataFax and Oracle*s Industry Solution, Oracle Clinical.

The motivation for using DataFax and Oracle Clinical for a single clinical study is two-fold. First, we have long been committed to deploying a remote data-entry system. DataFax helps us meet that commitment. Second, we wanted to investigate using a single tool, Oracle Clinical, for clinical data storage regardless of which tool captured the data.

This presentation describes the procedures used to enable DataFax and Oracle Clinical to work together. The final part of the presentation describes the cost of using two tools on one study.

As the statistical data management center (SDMC) to three different HIV/AIDS trials networks, SCHARP is responsible for creating and distributing case report forms to a large number of study sites. Case report forms are created and customized electronically and distributed in hardcopy formats or on-line.

Through our formalized CRF development process and using Adobe FrameMaker ., our technical document staff create professional, consistent, and effective case report forms that are easily customized per protocol and study site. Forms are optimized for DataFax to ensure accurate data collection and ease of use for study sites and participants.

In this presentation, I will outline how to create effective, DataFax-friendly CRFs that can be easily customized and distributed both electronically and in hardcopy format.

By the end of this presentation, attendees will gain a basic understanding of: . the case report forms development process; . effective CRF design for DataFax systems; . how to use advanced FrameMaker tools used to customize CRFs; and . how to prepare CRFs for both hardcopy and electronic distribution.

Background:

To assess the safety of a medication and procedure for Coronary Artery Disease a dose escalating trial was instigated. The trial design required a safety review after every five patient cohort. There was a great deal of concern about our ability to have the data ready for presentation quickly enough to prevent interruptions in enrollment. As part of the investigator training our clinical group was planning to have the first two patients in the trial treated at the investigator meeting. In order to demonstrate our commitment and ability to handle the data preparation and analysis, we were asked to present data summaries at the investigator meeting for the first two patients treated that day.

Procedure:

There were three keys to making this work:

1. a clinical interface that wouldn.t require training (simple CRF.s)
2. Pre-planning the analysis and
3. creation of test data for complete system testing and validation.

During the testing phase of our preparation we identified key areas where we could front-load our work and created a backup plan.

Lessons:

Although we were able to produce the data summaries in record time and transmitted it back to the investigator meeting, there are several things that we would do differently if (when) we do this again.

Through the use of DataFax and front-loading labor for near time data presentation we were able to build investigator confidence, create enthusiasm among everyone involved in the study, secure quick enrollment and ensure the safety of study subjects. This presentation summarizes our experience and makes recommendations for anyone else considering a similar effort to produce near time data summaries and analysis.