DFUG 2007 Agenda

One of the most crucial components of a clinical trial is the focus and full cooperation from the site. It is in the best interest of the sponsor to maximize the resources available to the site while concurrently providing flexibility and convenience in data capture possibilities. SynCapture-Multiple Data Capture (MDC) enables the sponsor to offer these options.

SynCapture-MDC enables the sponsor to have one protocol yet offer their sites three modes of data capture: Paper, Fax and Electronic.

From a data management perspective, the electronic mode demands minimal additional work beyond the normal study set-up. From a site perspective, the data entry and query resolution mimic the traditional processes and a moderate training regimen paired with data management assistance enables the site to electronically capture data accurately and efficiently.

In this presentation, we will discuss lessons learned from data management, site personnel, monitoring personnel and the sponsor. Tips will be shared for preparing a successful EDC study as well as some interesting metrics comparing SynCapture to traditional clinical trials.

The Case Study (CS) tool was conceived as a vehicle for delivering structured training to clinical sites via CRO monitors. It consists of the following five components:

• a Narrative that describes the CS subject
• a Visit Scheduler that calculates visit dates for the study
• a CS Subject CRF Binder fully annotated with realistic data
• a set of corresponding primary and secondary images in DataFax
• a series of QC reports that span the range of subject visits including closeout

Development of the CS tool has matured through use in six studies to date. The tool is now acknowledged as an important component of three aspects of validation:

• of the study flow as defined in the protocol
• of the design and printing of CRFs
• of the CRF Completion Guidelines

The tool also provides a secondary check of the database setup. The role of the CS in training has expanded to target the following areas:

• study flow (all users)
• general DataFax and CRF review (clinical site staff)
• monitoring review of study- and DataFax-specific issues (CRAs)
• data field particulars and edit checks (data management staff)

Technical aspects of preparation, construction, validation, and delivery will be reviewed.

Increasing interest in the DataFax reporting tools package (DfRTools) demonstrated at the DFUG-2006 meeting has convinced us to extend and further develop the capabilities of this package as a collaborative effort between Factory CRO and Frontier Science. DfRTools' main objective is to present reports in a comprehensible fashion, especially when looking for patterns, trends, or discrepancies as well as study metrics within the DataFax system itself. The advantages of using the DfRTools package, developed in the R Project statistical software, are no need to purchase additional commercially licensed software, and elimination of the exportation and transfer of the data from DataFax. More importantly, it allows us to display the DataFax reports in a comprehensible graphical and table format.

At Factory, CRAs often request detailed information regarding subject and center tracking, subject inclusion and QC note resolution rates, subject tracking, subject scheduling and missing pages/visits from Data Management. While DataFax provides most of this information through standard reports, patterns or trends are not always readily identifiable or observable. Therefore, we decided to deploy the DfRTools package within a prototype test study developed at Factory CRO. Focusing on replacing applications originally developed in SAS(r), removing the need to transfer data out of DataFax, and enhancing the information provided by standard DataFax reports, we developed additional functions in the DfRTools package.

Within this framework, a Test Study environment was build by Factory. First, a basic CRF set has been compiled to create a standard DataFax study setup. Subsequently, the database was populated with 14 fictitious subjects using fax/email capturing of completed CRFs and raw data entry. For testing purpose, approximately 50 QC notes of various types were randomly added to the database. Furthermore, the standard DataFax subject scheduling report is not sufficient for the CRA. Therefore, a custom SAS(r) program is used to generate the entire visit schedule with window information based on the patient's screening or treatment date. This SAS program was used as a template to create the corresponding R program capable of doing a similar job. Our efforts included the parallel implementation of the test study by Factory and Frontier Science, and monthly conference calls using the WEBEX conference system to update each other on the progress of this collaborative effort. Once the specifications for the new tools were agreed upon, the DfRTools package was extended to include new functionality.

In this presentation, we will demonstrate how we developed new functionality in the DfRTools package using R statistical software, and how we deployed this package within the DataFax system. We will also show comprehensible tables and charts for visit scheduling, and study metric data such as number of outstanding/resolved QC notes per site, number of visits received per site, and amount of CRF pages received by the DataFax system.

Accessing DataFax via local client software should be simple, easy to use and easy to deploy. Over the past few years, our internal users have been using Exceed onDemand PC X software to access DataFax. This software utilizes a small footprint on the users local PC and locally caches both the images and fonts during the users DataFax session to dramatically improve the overall connection performance.

Exceed onDemand Deployment Wizard enables Administrators to create and deploy installation packages that are placed on a web server, which allows end users to access DataFax and/or SAS using a link on their internal web server. This package automatically installs/updates the EOD software and connects the user to DataFax, SAS or any customized graphical application on either server. IT staff and end users can appreciate this automation.

I will present an overview of Exceed onDemand, how it works and discuss the core components.

For historical reasons, most DataFax users are using FrameMaker to design their CRF's. In this presentation, we will be discussing some of the possibilities of FrameMaker as well as share our experience with Adobe's Indesign.

One of the features of FrameMaker is its ability to use a MIF file, which allows saving a complete CRF as an ASCII file. And therefore opens the possibility to either read or write information to a CRF file. We will be presenting some examples of automated handling of a FrameMaker MIF file.

In combination with our in-house developed application, which stores relevant information on the CRF structure, this allows to automate the creation of a CRF. That is, as we know which plate (=Masterpage) is being used on which page of the CRF (=Bodypage), we are able to combine this into a generated CRF. So the application will generate a file with one Bodypage for each CRF page, with a reference on each Bodypage to the proper Masterpage and, as far as a Masterpage contains standard information, include all details on each Masterpage. We have also stored the barcode information into 256 files for each value of the Study barcode and into 512 files with the Plate and Visit barcode information. So whenever a CRF is Final, the application will automatically add the Barcodes to each page of the CRF. And another example of using the "ASCII capability" of a MIF file is the automated creation of an Annotated CRF.

In order to enhance the 'readability' of a CRF, we are using an external application to add Bookmarks to a .PDF file. So rather than browsing through a CRF to find the Lab page for Visit 3, a user can click on Visit 3 and then on the Lab page to get to a specific page.

As FrameMaker has a number of built-in limitations, we have recently started to work with Adobe's Indesign. We will be comparing some of the ins and outs of each package. As an illustration of this, we will discuss the example of the creation of multi-language CRFs. Ranging from using FrameMaker's conditional text to handle a 'limited-language' CRF to using Indesign for a multi-layered CRF of a 20+ language CRF.

DMU plays major roles in data management of the world's largest HIV vaccine trial conducting in Thailand. In this trial, all data management processes for over 25,000 screening volunteers and about 16,000 enrolled volunteers, accounting for almost a million case record forms during the 5 year study period, are performed within the DMU. As this is the first large trial in Thailand to maintain primary database subject to audit by the US FDA, the DMU has utilized the DataFax system to comply with 21CFR Part 11.

In order to maintain data quality, DMU has developed programs for clinical database quality assessment to be performed routinely throughout the study period and before database closeout. Data fields on a specified set (i.e. 10%, 25% or 100%) of randomly selected CRFs, that were faxed in during a preset period, are routinely verified by a data manager. To ensure timely and effective completion of the work process DMU developed an automated Database Quality Evaluation Program (DQEP) using MS-Access and MS-Visual Basic programs. DQEP randomly selects data records from SAS data sets, created using DFsas, and presents data values on the selected CRF template. The selected data values then appear as annotations on the original images of the particular CRFs. The program also allows the data manager to record the correct value for fields where discrepancies occur and then generates a listing of data discrepancies.

Finally, a Quality Evaluation report, giving error rates for each plate and the overall error rate, is automatically generated. The purpose is to check against the minimum error rate specified in the Data Management Plan. The program is flexible such that the user can set different checking parameters including percent, period, and types of CRFs. So far, the program has proven to be effective for assessing a large workload of more than 750,000 CRFs that have been faxed into the study database.

More Specifically What About: study conduct, sites, CROS, CRAS, consultants, data monitoring committees, regulatory documents, site trip reports, decisions, study tasks, upper management expectations, budgets, etc. How do we integrate the data that datafax gives us with the other 75% of STUFF that has to be done in order to quickly and efficiently complete a clinical trial.

This presentation will highlight and demonstrate the state of the art in Web Portal Collaboration Technologies that incorporate Document Management and Version Control, Metric Reporting, Event Alerts, Data Visualization, Internet Based Project Management and Distributed Task Management and Reporting while pushing Trial Data and Metadata from DataFax to the community of clinical project managers, data managers, CRAs, and Site personnel to realize the potential of on-line team collaboration tools and technologies.

Our coordinating center is required to collect hardcopies of informed consents (IC) and ensure that site personnel executed the IC documents correctly. This is an onerous task for project management due to the number of informed consents, as well as the time-consuming nature of tracking of unresolved problems, via email and telephone. Project management was looking for a more efficient method to handle the ICs.

We decided go with DataFax to track the ICs, mainly to tap into the QC report mechanism. We also wanted to test DataFax's utility, if expanded beyond the clinical data model, and see if it could handle administrative and/or regulatory tracking. We set-up the Informed Consent Tracking Log as a separate study in DF, and it is used by project management to log key issues regarding an IC. Each study has its own tracking log plate. This database is then imported into the actual studies' respective databases, and, through the use of batch edit checks, problems regarding the IC go out via QC Reports. This presentation will cover the evolution of the IC tracking project, current functionality, and the numerous lessons learned along the way.

At DFUG 2003, we presented the "MRF" solution for field monitors to use in closing the source-CRF-database triangle. While theoretically feasible, MRFs proved to be too much of a departure from standard monitoring practices, and the system was abandoned. Four years on, we now use the more flexible Visual Verification ("VV" method, available in a variety of flavours that address the demands of the study and the taste of the user as regards CRF volume, connectivity, and technical expertise. VV is now deployed using one or more of the following methods:

VV Direct

• All in-house CRAs monitoring DataFax studies perform VV within the firewall (in-house or via VPN).
• Contract CRAs connect via Citrix (RSA token) and XWin32 to use the DataFax Validation tool.

Third Party "VV-3" - Hybrid solutions Four years of "VV" experience has prompted a retreat from direct involvement of ClinOps in the DataFax validation process:

• Contract CRAs connect via Citrix (RSA token) and DFlite to view images and confirm changes initiated as part of monitoring. Results are reported to an in-house CRA who then moves the data from Validation Level (VL)4 to VL5.
• In one global solution, the contract CRA unable to connect directly is provided with password-protected PDFs of monitored images. Changes are confirmed and VV is performed by the CRO Project Manager with telephone support.

Third Party "VV-3" - One step back, two steps forward?

• Hope for the future (and material for discussion with fellow-DFUGers): The Source Document Verification (SDV) form is being streamlined with the intent that field monitors will submit the report for in-house VV-3 processing and that there will no longer be a need for remote access. The metrics component for monitoring will be improved with the addition of a screen-variable flag and batch edit-checks.

Associated tools (forms and reports) and a critical examination of the challenges and successes will be discussed.

Careful, consistent, and thorough documentation of DataFax study database setup is a necessity to meet the regulatory requirements for clinical studies, and essential to staying organized. While automated solutions can ultimately be the most efficient way to meet these needs, when resources and/or deadlines are tight, data managers often need low tech methods that can be implemented rapidly and maintained with little training and effort. The SCHARP Data Operations Group has developed a suite of Excel master documents and templates that are used to plan, track, test, and validate DataFax study database setup. This suite of tools documents requirements and testing procedures for plate and variable setup, edit checks and visit maps (including conditional maps) as well as providing tracking for other critical milestones. These tools were developed in conjunction with an overall quality management plan which uses a risk based approach for determining the level of documentation and validation required for DataFax database setup. This presentation will focus on providing examples of simple methods and tools that can be used to meet regulatory needs while increasing product quality and work efficiencies.

In the world of Clinical Data Management (CDM) it is customary (or required due to regulatory guidance) to perform an audit of the data to provide an acceptable level of assurance concerning the accuracy of the clinical database. One standard practice is to randomly select 10% of the subjects from a study to be audited. Usually, this 10% audit is conducted at the end of the study, causing a large burden on the CDM staff that must be completed in a short time frame; another approach is to perform the sample when 50% of the subjects have had their critical variables pass through 100% QC review-this will somewhat lessen the time crunch at the end, but not as much as might be desired.

ClinAudit is a software system designed to be an in-process SSP% selection mechanism (where SSP is 10 or any other specified percentage), so that once a subject is deemed "clean" by the CDM staff, it can then undergo randomization to determine if it will be part of the SSP% sample for the audit. This in-process subject-by-subject SSP% selection will provide the ability for the audit to occur concurrently with the data cleaning efforts of other subjects, thereby more evenly distributing the audit over the time from the first-Clean subject to the last-Clean subject. ClinAudit also has mechanisms to mitigate over-sampling or under-sampling of sites, and to also ensure that the desired number of subjects to be sampled is included in the audit. ClinAudit is intended to be an FDA auditable system and is therefore subject to 21 CFR Part 11.

The DataFax platform at H.Lundbeck A/S, which is a multi server Solaris host set-up with many interconnecting technologies, is a good example of a simple approach to embedded complexity transparency. End users and sites have single entry points to the platform and are not bothered in their daily task with the very complex IT-platform architecture that is supporting their interface to DataFax. Principle is that end users and site personnel must not be concerned with server locations or used technologies. Being able to perform a function well for any qualified user depends on the available IT tools "ease of use" capability. It is inherent here, that complicated 'IT-like' procedures are unacceptable and cannot be tolerated. H. Lundbeck A/S uses a variety of CDMS's of which DataFax is one. But actually only one CTMS is used to manage all clinical trials. All H. Lundbeck A/S clinical trials have global scope, meaning that numerous technology and supplier dependencies always exist when using a system like DataFax. These factors must be transparent to end users when using any system, hereby enabling swift and steady data flow processes that are not hindered by apparent 'IT issues'

This presentation is divided into two parts: The first one describes the numerous interfaces to the H.Lundbeck A/S DataFax platform. The interfaces span from Solaris inter host data exchange facilities to fax routing and email services and also contain export of DataFax logistics data to the CTMS system chosen by the company. The presentation focuses on end user satisfaction issues and where it can be difficult to fulfil expectations. The second part of the presentation introduces actual end user experience. An example of "steady" data flow processes is described in a case study, i.e. from the start up of a trial to the end. Pros and cons regarding the use of DataFax are detailed as well as the lessons learnt so far at H. Lundbeck A/S.