DFUG 2004

Medtronic Cardiac Rhythm Management uses Business Objects as a rapid, flexible, web-based reporting tool in a variety of clinical study databases. To make this possible, DataFax data is routinely exported into intermediate relational database structures that populate Business Objects Universes. Medtronic uses Oracle for most relational databases, however the procedure could also be used with other relational DB products. Jim Johnson, Biostatistics Manager in the Heart Failure Management division, developed a methodology using the DFSAS utility to export data from DataFax into standard Oracle tables. The Clinical IT groups now use this method to create individual tables per plate and also per Case Report Form. The latter case requires merging plates, so important study team planning is required so variables are appropriately managed across any plates that get combined into a single table. The setup of the DFSAS scripts is straightforward and a method of documenting the process for 21 CFR Part 11 compliance was also developed. Medtronic uses the DataFax DFlite utility and the PL/SQL Developerb tool to validate the final data structure.

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 an peak incoming volume of approximately 70,000 pages per month.

SCHARP relies on a world-wide network of Internet ready fax machines to send these CRFs reliably and cost effectively via the Internet. This proven method provides for an economical and efficient method of sending large volumes of pages from distant areas to the centralized DataFax facility at SCHARP.

To augment and interface with the existing Internet ready fax machines, SCHARP is currently developing "Data Buddy." Data Buddy, a self-contained computer which resides at the sites, provides SCHARP with options to:

1. Encrypt, if needed, the transmission of CRFs sent as email attachments via the Internet.
2. CRF transmission telemetry from remote sites to report on the status of faxed CRFs.
3. Site based electronic filing and archive to CD-R of faxed CRF pages.
4. A simple web interface for interaction with the machine.
5. Ability to perform remote updates and upgrades.

When used with its companion, "Truck Buddy", the system also provides very remote and technically challenged sites the ability to scan CRFs to electronic media for transport to a central, more advanced site with a Data Buddy system. These electronic CRFs can then be uploaded via Data Buddy directly to SCHARP.

Electronic, rather than paper transport of CRFs from these remote clinics keeps the physical CRFs closer to the patients, prevents loss and damage to the CRFs, and can reduce the need for multi-part NCR forms.

This presentation will talk about the Data Buddy machine, how it works, and its benefits to CRF relay.

We recently finished a proof-of-concept trial with DataFax using a digital pen in place of faxing. The pen (described in a Clinical Data Care DFUG presentation in 2002) captures and stores in its memory whatever is written on paper pre-printed with a special pattern developed by Anoto.

HP developed a system for us that allows us to print our own Anoto-patterned CRF's on a standard HP printer. CRF data at a site is uploaded from the pen to one of our servers over a regular phone line. A composite image of the current penstrokes, along with any prior penstrokes and the background form, is emailed into DataFax.

We'd like to share the results of our in-house trial, outline where we'd like to go next with this technology and present some of the advantages and disadvantages of using the digital pen in place of faxing.

The development of DataFax-EDC continues to make significant progress with some important new announcements and features to report. DataFax-EDC is now a joint project between Frontier Science Technology and Research Foundation (FSTRF) and the Statistical Center for HIV/AIDS Research and Prevention (SCHARP). This collaboration provides a rich set of resources and the diverse environments necessary to advance DataFax-EDC from a proof-of-concept model to a production level product used in clinical centers. We will present details of the collaboration, progress to date and future plans for DataFax-EDC. In addition,we will present an overview of the latest version of DataFax-EDC, including new features with Acrobat 6.0 and advances in XML forms technology. In particular,we will present how DataFax-EDC incorporates XML technology, our assessment of Adobe's XMLForms Architecture (XFA) and Microsoft's InfoPath, and the impact of these technologies on electronic data collection.

Much has been (and will continue to be) said about system validation. My understanding of its principles and needs with regard to DataFax has evolved over time especially with the changing regulations from the FDA. Especially now with the risk assessment focus the agency has been taking a great deal of anxiety can be involved. I eventually found that if I applied westernized Zen ideas to validation that not only could I reduce my anxiety, but I could also pass audits and successfully satisfy my very anxious QA department. Application of principles such as "Less is more", and following the eightfold path to nirvana will be explored.

Over the years, I've had more than my fair share of DataFax validation experience, and have often struggled to fit what I consider a worthwhile task into what sometimes becomes a difficult framework. Even with the monumental efforts that these projects have taken, at the end of the day, I still had to ask "what have we really accomplished?"

Now that we are going down the path of our own data management company with our own needs to validate DataFax, I'm in the driver seat without the contraints that I've faced in the past. Although there have been many positive aspects of my experiences with validation, they have all had one thing in common. They were driven by regulatory compliance departments whose needs were different than my own as a DataFax Administrator.

In this talk, I want to get back to the core of what validation really means to me. Take the "good" out of what I've learned about validation and know about DataFax, discuss the "bad" which bogs down many validation processes I've seen, and propose that some of the "ugly" might be just plain busy work.

As a UNIX administrator, a DataFax administrator, and ultimately, the one responsible for ensuring that the data is correct, I would like to propose a fresh approach to "take back" the validation process. In this way, I hope to make it not only meet the needs of regulatory compliance, but also be a useful process for all. A process that allows me to sleep better at night with the knowledge that the DataFax system is not only "validated", but is truely valid.

It is very important for contract research organizations to provide their clients to access clinical data timely and flexibly. There are two methods used for providing information to clients or partners in general: pulling and pushing. DataFax system is a very reliable and secure system for collecting clinical data and generating needed reports within the system. In order to provide access to the data and reports outside of DataFax system, we need to build a middleware or gateway for directly extracting, transforming and publishing (ETP) from DataFax to dedicated sites or subscribers. This paper will introduce the DataFax middleware that we build and share our experience on extracting, transforming, loading and publishing DataFax data.

Based on the needs for loading DataFax data into a relational database, we developed DataFax-Oracle Bridge to extract, transform and load (ETL) data from DataFax to Oracle in 1999. This ETL engine allows us to mirror DataFax studies in Oracle database easily, but it leaves all the DataFax reports behind. We need a middleware to act as a publishing engine for new reports that we create based on data in Oracle database and all the DataFax standard reports. So we developed DFsrptr - a middleware for DataFax system to publishing its reports and new reports from Oracle data warehouse.

The DataFax Middleware (DFM) is only a pushing engine. It has the following capability: 1) configure for multiple studies; 2) publish DataFax reports (bypassing RDBMS) and new reports from data warehouse; 3) publish reports into multiple sites or based on subscription; 4) publish through different means such as ftp or email; 5) Archive all the historical reports; 6) flexible scheduling capability to allow the reports to be published monthly, weekly, daily or the combinations within one study. Detailed configuration and data flow will be demonstrated in presentation.

The Perinatal HIV Research Unit, based in Soweto, Johannesburg, has a DataFax installation in Africa. This was achieved with funding support under a Comprehensive International Program of Research on AIDS (CIPRA) grant.

This DataFax installation in Africa is significant because we had to overcome certain obstacles:

• Africa is a resource-impoverished continent. Skills and technology are expensive and sometimes difficult to source.
• Data Management in Africa has traditionally been handled offshore in one of the first world countries. This means that Clinical Research Data Management in Africa is underdeveloped.
• There is also a certain amount of resistance to developing a Clinical Research Data Management industry in Africa.
• As a consequence of not managing their own data African researchers have a poor understanding of what Clinical Research Data Management involves. It is often difficult to convince local researchers that significant amounts of money and time are required to handle Clinical Research Data in a responsible manner.
• Africa based researchers have a lack of confidence in local Data Management structures, skills and expertise. Part of our challenge is to demonstrate that an African Data Management Centre can handle data as effectively and responsibly as our first world counterparts .

Many of these obstacles have been counteracted only because of extensive collaboration and support from established first world organizations. However, there is an ongoing need for training and support, and therefore there is a need to 'twin' developing organizations in the Third World with those that are developed and established in the First World.

The future of DataFax in Africa is promising. Besides our PHRU installation there are other research organizations that are planning on implementing DataFax:

• CAPRISA: The Centre for the AIDS Program of Research in South Africa (Durban, South Africa).
• MRC: Medical Research Council of South Africa (Cape Town, South Africa).
• UZ-UCSF: University of Zimbabwe and University of California (San Francisco) collaboration (Harare, Zimbabwe).

There is hope that there will be strong collaboration between these developing Data Management Centres. A common information platform is envisioned for the region which would include laboratory, bioinformatics, and clinical data hubs.

While study closeout is a basic function of any clinical trial and accomplished by all in various different ways, it's still one of the most discussed topics that continues to be of interest for most Clinical Data Management staff. The approaches taken have a big impact on resources, timelines and final data quality.

The US AIDSVAX trial was a 5400 subject, 61-site, multi-country 3 yr trial. The subjects had at least 16 visits over a course of 36.5 months. The database was to be locked 6 weeks after the last subject visit. In preparation for locking the database, some of our objectives were to 'lock' data for subjects as they terminated the study, decrease the redundancy of clinical data review and not change the validation levels of records (multiple times) for these.

We accomplished this by creating a separate 'Clean Subject Database'. The clean subject database had two flags, one for Data Management and one for Clinical. A subject was considered clean for Data Management if all queries were resolved and a final review of critical forms revealed no outstanding issues. Clinical would then review the subjects considered clean by Data Management and, if there were not outstanding issues, the subject was flagged as Clinical clean. The future data review listings would exclude these subjects. This allowed us to minimize redundancy in data review and in effect 'close' database subject by subject. As a result, by the last subjects' visit, the majority of the database had been fully reviewed and the entire database was fully reviewed and ready for data lock within weeks.

There are many cases where you have to run clinical trials in more than one DataFax studies but would like to see aggregated data sets or reports. It is difficult to do this within DataFax system. The other hurdle is to collaborate with EDC systems, project management systems, and lab data sets. This paper will share the solution and tools that we develop for DataFax federation and collaboration with other systems using the federation and collaboration approach for our Best Pharmaceuticals for Children Act - Coordinating Center (BPCA-CC) as an example.

The integrated solution includes three areas:

1. Integration requires adopting a common standard. As we presented last year, we have adopted CDISC models as our standards for data sharing and publishing.
2. DataFax federation allows us to treat many studies as one study and generate aggregated reports.
3. DataFax collaboration enables us to integrate DataFax with other systems.

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, tracking individual problems is a labyrinthine process, and the problems frequently become acute before they are even identified. To help recognize problems early, SCHARP has developed the CRFometer: a system for monitoring, measuring, and displaying the numbers of CRFs received via DataFax over time.

The CRFometer is a collection of Perl and shell tools that harvests information from DataFax's fax_log file, compiles it numerically into an ASCII flat-file database, and displays this information via tables and graphs. Among other things, these tools can be used to:

1. Present routine information for monitoring DataFax traffic flow (e.g., CRFs per last hour/day/week/quarter).
2. Create custom tables and graphs upon demand.
3. Create a database retroactively, detailing a comprehensive data-flow history since DataFax's initial installation.
4. Monitor traffic over time for specific sites, and compute other relevant information (e.g., emailed vs. telephoned CRFs; rates of data-flow from different continents).
5. Send email or other alarms to warn of certain events (e.g., no incoming CRFs from a particular site for seven days).

Tables and graphs of CRF traffic can provide DataFax administrators and users with quick, intuitive information about the state of incoming data flow, and can be used to detect and troubleshoot problems, estimate workload, and make technical decisions.

This presentation will talk about the CRFometer, how it works, and its benefits to DataFax administration.

The wrap-up session will summarize the proposals for future DataFax software development that were raised during the meeting.