DFUG 2002

Last year Frontier Science presented a prototype for performing electronic data collection and submission to DataFax over the Internet. This prototype was built on two key concepts:

1. Replace the fax process (Hylafax), which receives the data via fax, with a Web server using Java servlet technology, which receives the data via the Internet using Hypertext Transfer Protocol (http).
2. Replace the fax data format (G3 TIFF processed by ICR), with Adobe's Forms Data Format (FDF), which allows the data to be collected using Adobe Acrobat Portable Document Format (PDF) forms.

We have now developed this prototype into a beta-level product tentatively named DataFax-EDC. This year, Frontier Science would like to offer DataFax-EDC to the user's group as an open source project. Our primary interest is to augment the data collection capabilities of DataFax by providing tools that support the implementation of electronic data collection in clinical trials. We strongly believe that releasing the DataFax-EDC source code will greatly enhance DataFax's capabilities and will ultimately benefit the entire DFUG community. To make this a reality, we are proposing the establishment of a self-directed DFUG subgroup with membership open to all interested individuals. The details of the DataFax-EDC product, potential subgroup organization and options for development and licensing will be discussed in the presentation.

The Sweden based company Anoto is developing a pen, equipped with a digital camera that is used together with special paper. The paper has a barely visible raster printed on it. The pattern from the raster is captured by the camera, as it is written and send via bluetooth to a cell-phone, laptop computer or similar. The captured information is then rerouted to the appropriate receiver over the Internet (e.g. clinical database).

The pen transmits what pen was used on what specific paper sheet and where on that paper it was written. Since also the pen movements are captured it is possible to make very accurate ICR engines to interpret what was written. Please look at http://www.anoto.com for further details.

Applied to a clinical trial, much of the benefits of DataFax are maintained. The Investigator still got the conventional pen and paper solution. The faxing procedure is how ever replaced by the bluetooth transmission.

The Anoto pen does not necessarily replace to faxing, but could serve as an alternative solution to fax at some sites. It could also be used to expand the area of which DataFax is operating, covering monitoring reports etc.

At Clinical Data Care we designed a small DataFax study together with Anoto. We printed the CRF on Anoto prepared paper. We completed the CRF using the Anoto pen and send the resulting TIF image via a bluetooth equipped cell-phone to DataFax as an email. The images were received and processed by DataFax from there. It worked nicely.

The presentation will cover:

• A brief introduction of the presenters and Clinical Data Care
• Anoto concepts and technology
• The DataFax test study setup
• Benefits and potential problems
• Questions and discussion

Synteract acquired a study that was already in progress. We received 2-years worth of SAS datasets along with TIFF images. Our goal was to convert the SAS datasets into the DataFax database structure, import the data into DataFax using DFimport.rpc along with the corresponding images for each dataset. In this presentation, I will discuss how Synteract achieved this goal.

The authors have agreed to make their code available to the DFUG community.

Why: One of our local trials was promoted to pivotal status, thus needing to meet international standards (based on a mainly paper-based CRF). We were asked to submit PDF versions of the fax images of the CRFs from DataFax .

The built-in PDF conversion utility in the validation tool in DataFax is sufficient for creating PDF files for a handful of subjects. However, we needed the ability to build PDF files for several hundred subjects fast and efficiently. We also wanted the flexibility to create PDF files from various subsets of the data.

Before: Before our buildPDF tool was created, data processors would retrieve subject records one by one, building PDF files as they went along. This process was tedious and time consuming.

After: With buildPDF, non-programmers now can, at the click of a button, choose any subset of subjects in the trial (such as all subjects from a centre, all completed subjects in the trial, all completed subjects in a centre) and buildPDF will create an individual PDF file for each subject.

How the tool works: BuildPDF selects each page from the CRF (in page order) and searches for a matching image based on the CRF ID, plate number, and visit number key. It builds an export file with all the images it finds and then uses the DFpdf utility to create the PDF file from the export file. The procedure is repeated for all selected CRF ID's. The tool is written in Tcl/Tk,. It is easily configurable, easy to use and flexible.

Future Development Plans: BuildPDF will be able to select subjects based on various criteria, such as all CRF IDs where an AE is marked serious and/or who have discontinued early due to an AE. This will increase the tool's flexibility.

The author has agreed to make his code available to the DFUG community.

During the past four years, SCHARP has experienced a 157% increase in active DataFax studies. To manage this growth, tools were developed to manage entry, permissions, CRF annotation, re-faxes, edit checks, styles, and a tool for management of personnel.

Data entry. Entry staff needed a clear policy for daily duties. We needed to identify the age of new records, number of records at each validation level, and the QC reports schedule. A table (created by new_records.pl) uses the FAX_LOG, DFstudies.db, and DFexport.rpc.

Study permissions. A GUI using DFuserPerms was developed to determine what users had permissions to the multiple DataFax studies.

CRF annotation program. Different functional groups find the program which annotates CRFs with setup information (Peter Dueber, DFUG 1999) highly useful, but are not comfortable typing a parameter list on a command line. A GUI to the annotation program was developed.

Re-faxes. Clinical sites may repeatedly fax in pages without changes: the page map is wrong, or site is not faxing in the correct page. To avoid frustration, refaxes_no_change.pl was developed to detect multiple refaxes where no data has changed.

Edit check detection/Style management. Searching for all of the occurences of an edit check within a study is facilitiated by edit_check_search.pl. Searching for styles (to know if a desired style exists elsewhere) across within/across DF studies is facilitated with style_search.pl.

Too MANY tools? The information the DO staff has to remember a lot to find/launch a desired tool. A DO tools' interface was written to allow DCs to view a program description and launch it without having to remember the location/name.

Staff Management Tool. With 44 active DF studies (and climbing), it became cumbersome to use DF_WFcrfs in monitoring staff validation efforts. To facilitate this monitoring, validation.pl was developed to look at DF_WFcrfs across all studies.

Almost all pharmaceutical companies maintain separate operational and safety databases. Consequently one of the banes of both data management and safety is ensuring that the two databases can be reconciled. This process is complicated by the fact that, at almost all companies, the data for the two databases is collected and audited independently with very few common threads. Generally, this means that the reconciliation process is done at the end of a study and requires a large input of resources to complete. At Pharmacyclics, Inc. we are utilizing DataFax to collect data for both databases in a single location. We share information from the operational database with our safety database. This creates a nearly seamless reconciliation process that can be largely automated. DataFax is a superior platform for this process enabling a single communication method for the site coordinator regardless of the information being sent.

Vendor Audits are expensive for both client and vendor. The client must bear the cost of sending auditors to the vendor's location and the vendor must invest time to prepare for the audit, host auditors and respond to findings. Working together, User Groups can reduce these burdens and increase the quality of the audit. Participating users pool their expertise to create an audit plan that meets the requirements of each organization and share the expenses, resulting in higher quality at lower cost. The vendor hosts a single audit and responds to a single set of findings. In preparation for the release of DataFax 4.0, the DataFax Users Group should mount such an audit.