Agenda

ClinEDC, formerly DataFax-EDC, has undergone significant changes in the last nine months. Originally written in Adobe Acrobat and JavaScript, it has now been completely rewritten in Java. Several factors influenced this decision, but the most compelling were Adobeb's change to its forms technology and philosophy that made further development increasingly difficult and impractical, and the robust multi-platform, data handling, and security features provided by Java. We have also added several new components to improve implementation and manageability. In particular, there are two new tools for the project office/coordinating center:

• A "Study Configurator" for converting DataFax studies into ClinEDC studies and generating and managing the corresponding eCRF libraries; and
• A "Study Controller" for managing the exchange of data and quality control queries with the clinical sites.

Together with two new tools for the clinical site:

• A "Study Administrator" for setting up a study on the site's computer system, including creating user accounts and managing the eCRF library; and
• A "Study Manager" for creating and maintaining electronic Subject Binders, and for managing the exchange of data and quality control quires with the project office/coordinating center.

We will present these tools and other major features of ClinEDC, review the technologies used, and discuss the impact on clinical sites and DataFax. In addition, we will give a demonstration of the major ClinEDC components.

Companies and organizations throughout DFUG spend tremendous resources creating Validation Protocols. While there are differences between hardware, networks and SOPs, DataFax requirements are very similar for every organization. Each is using DataFax to collect, review and manage clinical data. Each needs to satisfy the requirements of ICH and major governmental bodies. There are also similarities in test strategies, especially the ATK. So, why not use those common purposes and practices as a foundation for quality? By creating a common list of foundational requirements and a traceability matrix linking each of them to existing or additional proposed tests, the user group could 1) create standards for DataFax implementation and 2) reduce the workload of individual organizations.

Case Report Form design for a study with 17 different languages presents many challenges. My presentation will chronicle some of the best practices learned during this trial. Included will be the following:

• The vision: It's essential to have a clear plan of translation and back translation at the very beginning of forms design and to follow through with that plan for each site. Xhosa-to-English is not an option on the Babelfish website, so site communication is critical. The process for translation and back translation is always more time consuming and complex than you would expect.
• The mechanism: How FrameMaker's conditional text was used to manage all languages within a single FrameMaker document. With conditional text, the text on a form can "magically" change from Bemba to Setswana to Zulu and back again. Keeping control within one document was critical in managing inevitable forms changes.
• The logistics: How a medical term that's one word in English can balloon to 40 words in another language. You must plan ahead for inevitable girth.
• The practical: Version control is difficult enough with a single language. You need to develop a plan for handling versioning issues with different languages and how to recognize the differences in DataFax.
• The ridiculous: How to deal with site staff arguing about the spelling of the word "no"!

Applied Clinical Intelligence, LLC needed to create a DataFax CRF where half the page would be automatically pre-populated with ECG interval measurement data from a SQL database management system and the other half, manually filled out by a Cardiologist.

The ECG CRF Unique Plate was designed and created in Adobe FrameMaker as a typical DataFax CRF Plate using standard DataFax barcode, field and checkbox conventions. The FrameMaker designed plate was then saved as an Adobe Acrobat file and imported into DataFax as the validation screen background for the ECG CRF.

Next, using Adobe Acrobat Professional's built in Forms tool; form fields were created for every field and entry box that would accept a numeric entry. Each of the acrobat form fields were named (and their attributes set) to match field names in the SQL database containing the ECG measurement values.

The Acrobat Form Field properties were set with the Century Gothic font to enhance DataFax's ICR capability. This Hybrid DataFax CRF would be stored on one of ACI's file servers and the SQL Database containing the ECG values was configured to create a database view with fields matching the fields on the Hybrid DataFax form.

Using a commercial software application called PF-Merge we would then generate a CRF page for every record contained in the SQL Database (e.g. if there were 200 ECG records, the PF-Merge application would create 200 ECG CRF pages using the single page Acrobat Form).

The ECG pages would then be printed with the ECG measurement fields "pre-filled" directly from the ECG interval measurement system database. The primary purpose of this is to avoid errors from manual transcription and to allow the cardiologist interpretation and ECG measures to be available on a "single" CRF Page. The Hybrid DataFax ECG CRF would be provided to a Cardiologist along with the original ECG for morphology interpretation coding and sign off.

This process works equally well with any clinical data that otherwise would not be collected via a normal CRF page or is available only in an electronic database form. This approach also works with central lab data or patient diary information where the data is collected either electronically via a device; such as a hand held palm device (in the case of electronic patient diaries) or the clinical data needs to be evaluated by the investigator at the site and they need a record of the data for the patient's chart.

This presentation describes the process and technical approach that Applied Clinical Intelligence used for addressing the issue of creating and pre-filling DataFax CRFs with information collected and/or stores electronically in other clinical database systems.

This presentation will showcase our method of collecting, converting, tracking, and reconciling lab data. If a data link is built into the DataFax data, then running a SAS program to reconcile the lab data is possible. I will begin by showing what needs to be in place within the DataFax data. Then I will discuss the other components (sample labels, biosample shipping forms, and/or a predesigned spreadsheet) needed to ensure that the lab data contains the needed information to compare it to the DataFax data. Next I will highlight the process we use to convert and upload the data. Finally, I will show how we determine whether or not we received all samples expected (or if we received samples not expected).

Lab data handling for clinical trials can be very complicated, especially when labs are done with both central and local labs or for domestic and international sites. Different data collection systems can complicate the situation even more.

This presentation will demonstrate how we deal with lab data capture, handling, consistency checks, and data merges based on both domestic and international studies. We will share our experience on how to design forms differently depending on the ways the lab data are to be collected, how to program edit checks to check lab normals and CTC grading, how we reconcile our data with vendors' transfers, and how we merge our lab data at the end of the study.

Lab data collection is very common and is some of the most complicated in clinical trial data collection. This presentation is also meant to bring up discussions among members of the users group so that we can share our experience and may gather some new ideas in order to better utilize all of the tools available and get the best results possible.

Implementation of the CDISC standard is of increasing importance to the pharmaceutical industry. An effective and efficient plan must be devised to minimize the impact of the rather comprehensive standard on resources. Without a meaningful assessment and sufficient understanding of the standard, however, the creation of such a plan is not possible. To obtain such an understanding, an initial piloting of the implementation is required.

The presentation will describe such a pilot undertaken at ICON Clinical Research, outlining the general approach, reporting the findings, and discussing the lessons learned. A discussion of a general plan for the implementation of the CDISC standards within DataFax is also included.

This presentation will focus on two aspects of Validating Edit Checks (EC). First of all, how to make sure that they do what they are supposed to do, in other words how to validate that they comply with a Data Validation Plan (DVP). And secondly, not any less relevant, how to make sure that Edit Checks are defined at each relevant field.

We are using an inhouse developed application, called XS2DataFax, which guides us through all steps of creating a DataFax study. So as a first step in defining ECs, each EC will be defined in a table in XS2DataFax. And in order to identify each EC, we are using a unique Identifier called 'EC_ID' for each EC. Along with each definition, we are creating test records for each individual EC. Thus ECs and its testdata are "linked" to each other, creating a repeatable test procedure and allowing to document the test procedure. As a second step, XS2DataFax will be used to "link" ECs to variables, thus we define upfront which variable should trigger which Query.

Once defined, XS2DataFax will generate a general framework for the DFedits file, thus minimizing the amount of manual work to create this file.

The testing procedure consists of two parts. Firstly, XS2DataFax will use the test data to generate DataFax records which are imported into DataFax. It then executes the ECs in Batch mode and will read the resulting .XML file and automatically checks if each set of test data has triggered the corresponding Query (or not). Secondly, it will read the Setup file and read which ECs have been defined on which fields. By comparing this actual definition of ECs with the Table which holds the upfront defined links of ECs to fields, we are able to check that the actual DataFax setup matches our specification.

We found the text format used by the DataFax reporting system does not always present results in a convenient and comprehensible fashion, especially when looking for patterns, trends, or discrepancies as part of the clinical trials data management process. Instead, we suggest using graphs or tables representing some of the DataFax reporting results to be more readily recognizable, identifiable and understandable. However, earlier DFUG presentation showed that presenting the results in this format required significant additional resources, such as SAS, MSExcel software, or repeated handling and transferring of the data. So, we use the R- Project statistical software to produce graphs and tables for some of the DataFax reports. We can generate graphs showing received and validated fax rates, and accrual rates by individual or multiple clinical centers. In addition, we can produce a variety of graphs showing QC statistics, including QCs by clinical center, QCs by CRF, and a combination of the two. We can also produce graphs or tables displaying simple statistics for the study. In this presentation we will give examples of how to use R to produce these graphs and tables and how to incorporate R into the DataFax reporting system.

At our coordinating center, we often feel the need to view information about our DataFax system that isn't available in the regular reports. Many times, this information is about the health or business of the system, for example modem and fax traffic patterns. We have developed methods for treating DataFax system configuration files, user authentication and permission information, DataFax and HylaFAX log files, and files in the study lib and data directories, as read-only databases. This allows us to then use well-known data integration techniques to create and present meaningful customized views of the information. Limitations of this approach will be discussed, along with lessons learned for working around them. An example will be shown, in which a data manager views recent fax traffic, seeing only transmissions from her sites, and highlighting faxes with an error status.

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. In order to provide expedient clinical monitoring for Phase-I trials, SCHARP needs to be able to quickly run safety reports and track the related communications in DataFax as close to real-time as possible. Since these reports are generated by lengthy calculations using data stored in Postgres, it made sense to pull the DataFax data into Postgres to run the calculations for these reports.

Unfortunately, DFsqlload was missing some key features that we were looking for-- so we built our own: 'Slurp'. The Slurp system is an active mirror of the DataFax data using customizable, incremental updates that run by default about every ten minutes. By pulling incremental updates and including a few other bonuses, Slurp enables you to do some very neat things. The entire system can be customized to do whatever you need, theoretically including creating a duplicate to DFsqlload.

The Slurp has been invaluable to SCHARP for achieving near real-time access to our DataFax data in a relational database. This presentation will give some of the gory details of Slurp, and show how we've put it to use for our own nefarious, err..., altruistic deeds.

Closing out a DataFax study takes a lot of effort in planning and diligence in following your SOPs (if you have well-written SOPs). Archiving a whole study in study closeout, or even many years later, requires more dedication and some detective work as well.

This paper shares our experiences in conducting a data archiving project for one of our clients. It introduces the tools that I developed and used in the project and describes the plan for making these tools into an integrated application - DataFax Archiver which will be shared in DataFax user group.

The DataFax Archiver uses some common Perl modules for its web interface while using DataFax specific Perl classes developed for dealing with documenting and archiving tasks. The DataFax Archiver provides a three phase approach: 1) closing a DataFax study, 2) documenting files, and 3) indexing files. It covers the following documents: 1) DataFax users, 2) DataFax study configurations, 3) DataFax data files, 4) DataFax image files, 4) DataFax audit files, 5) project management documents, and 6) index files for various components. It also generates a main index file to tie all the files together. The Archiver preserves DataFax native files and also generates files in viewable formats such as HTML, PDF, CSV, XML, and YAML. For XML files, it will use CDISC standards whenever it is possible.

YAML is a new document format used mainly for configuration and data output for further processing. YAML is a human-friendly, cross language, Unicode based data serialization language designed around the common native data structures of agile programming languages. It is broadly useful for programming needs ranging from configuration files to Internet messaging to object persistence to data auditing.

One of my favorite aspects of DataFax is its extensibility. Being based on a UNIX platform, DataFax provides users with the ability to create their own DataFax "utility belt" out of standard system commands. Everything you need is right there in front of you-nothing is hidden away behind the scenes. Presented will be a collection of simple DataFax utilities. No big developments, just small tips, tricks, and simple programs that hopefully will make someone's day. Here's a selection of the ideas to be presented:

• Really need 8 modems? A simple script to parse your HylaFax faxlog files to report fax activity by modem.
• How good is your data entry? A simple script to compare first pass with second pass of data entry, reporting on differences.
• The all-powerful DFedits editing window letting you down? Here's a simple macro to edit and compile your edit checks using vi and/or Emacs instead.
• Using DataFax on multiple monitors and tired of constantly needing to resize windows? Have DataFax tools start automatically with the correct tool sizes based on your current monitor resolution.
• Need remote access to DataFax? How about secure high-speed connectivity in less than 5 minutes with almost no setup or extra hardware, using GoToMyPc from Citrix.