Once the data warehouse is assembled, its customers will likely

Transcription

1 Clinical Data Warehouse Development with Base SAS Software and Common Desktop Tools Patricia L. Gerend, Genentech, Inc., South San Francisco, California ABSTRACT By focusing on the information needed by customers, it is possible to develop an effective clinical data warehouse using tools that already exist on a typical clinical programmer s desktop. The common tools base SAS, SAS macro language, SAS/FSP, UNIX, Microsoft Word, and file transfer protocol (FTP) can be harnessed to implement dependencies, scheduling, metadata dictionaries, documentation, and data mart generation. INTRODUCTION There has been considerable focus in recent years on optimal development of clinical data warehouses. As global pressure on timetables for new biotech and pharmaceutical products increases, so does the corresponding need to have meaningful clinical trial information available at the fingertips. In general, clinical trial data is entered into operational databases in a normalized fashion; data is stored in many different files in order to reduce redundancy and resulting update anomalies. While this approach has traditionally been successful for data entry, it has proven difficult for data analysis and reporting, which benefit from having all needed data in the same file for easy access. It is the need to have related data stored together as well as the need for derived information that drive the development of a data warehouse. Catering to the ways in which a person will want to examine the data should be the prime focus of development. In so doing, the developer is free to select whichever tools accommodate this focus, be they common desktop tools or sophisticated data warehouse products. It is often the case that common tools are inexpensive and do not require a significant learning curve, while sophisticated products are expensive and time-consuming to learn. However, sophisticated products can offer a level of process and output cohesion that is lacking in the less developed approaches. This paper describes a method for developing a data warehouse of clinical trials subject data that makes use of the following desktop tools common to most clinical programmers: Base SAS SAS macro language SAS/FSP UNIX Microsoft Word FTP Tips for developing a glue that holds the various processes and tasks together are provided. Once the data warehouse is assembled, its customers will likely

2 include the following: company scientists and statisticians, company programmers, Food and Drug Administration (FDA) reviewers, outside investigators, and industry/academic collaborators. These customers will be able to easily access the data with numerous tools common to reviewers, such as SAS, the SAS System Viewer, JMP, SPlus, and Microsoft Excel. QUALITIES OF A GOOD DATA WAREHOUSE Since the goal of a data warehouse is to provide information to customers, the best approach for its design is to focus on what the customers need before addressing which tools will be used to provide it. Below is a table summarizing the major user needs as well as features a developer must implement to meet these needs: Figure 1. Customer Requirements Customer Developer Must Do Needs Ease of use Good database design Good documentation Appropriate data marts Accuracy Dependency control Code validation Timeliness Scheduled data refreshes These user requirements and ways of achieving them are addressed in detail below. CUSTOMER NEEDS: EASE OF USE As with any product, the easier it is to use, the more likely customers will use it and do so correctly. It is critical that the data warehouse include information that customers need in structures that are easy to assimilate as well as documentation that helps them understand the data. Database Design Requirements The following requirements exist for designing the data warehouse: Provide appropriate and relevant data content Comply with FDA electronic submission guidelines (although this is not strictly required for information not being sent to the FDA, the guidelines are very reasonable for any clinical data warehouse) Mimic case report forms (CRFs) when grouping variables to match the customers preconception of the data s structure Minimize/eliminate the need to merge data sets since this step is quite error-prone for nonprofessional programmers Add stratification parameters to all data sets, such as age, sex, race, and treatment group Create a large one-recordper-subject data set with baseline and outcome information Minimize the need for calculations since this can also be error-prone and wastes the time of the customer Calculate a study day variable for all data sets Calculate other anticipated derivations Use consistent names and structures

3 Define consistent visit identifiers across all data sets Assign meaningful names to variables and data sets Eliminate housekeeping variables such as data entry operator Keep data sets comprehensive by including subsetting flags since it is easier to subset a data set when necessary that it is to merge or concatenate data sets when necessary Keep related data sets in the same directory so they can be found easily Implementation The requirements itemized above can be implemented through the following methods: Develop data standards for items involved in collecting, storing, and analyzing the data: Case report forms Operational database structures and names Derived data structures and names Standard data transformation programs that use base SAS data steps and procedures and the SAS macro language Utilize subsetting flags and standard directory structures to facilitate creation of data marts: Subsets within clinical studies Supersets across clinical studies Documentation Requirements By following the recommendations above for database design, the data will be self-documenting to the extent possible. However, since a data warehouse is not prose, this additional documentation of its content is needed: Alphabetized listing of all data sets, variables, variable attributes, labels, formats, and format values (Figure 3.) English documentation of derivation methods (Figure 4.) Data tips for nuances and major analyses Implementation The documentation requirements can be implemented in the following ways: Add labels to all data sets and variables Attach formats to all coded values Produce a report-quality listing of metadata using SAS PROC CONTENTS and PROC REPORT Type derivation methods into an MS/Word table Develop a derived data dictionary using base SAS and SAS/FSP to aid the data warehouse developer Data Marts Requirements It is common to encounter customers who don t need all the data from a given study as well as customers who need data from multiple studies. The data warehouse developer can tailor the delivered data sets to the needs of the customer: Limit data to customer needs; e.g., pharmacokinetic data only Store related data sets in the same directory

4 Implementation The following techniques make creation of data marts easy: Utilize subsetting flags to limit data to relevant subjects Create supersets of data across clinical studies, such as integrated safety databases, using standard data and directory structures Use standard directory structures to reduce confusion CUSTOMER NEEDS: ACCURACY Requirements At least as important as any other customer requirement is that for accurate data. The FDA has regulations governing data accuracy, and common sense supports this concept. By addressing the following requirements, accurate data can be produced: Comply with the FDA s Good Clinical Practices (GCPs) Validate software Ensure dependency control Implementation The following list outlines ways in which the accuracy requirements can be achieved: Develop and practice a software validation Standard Operating Procedure (SOP) Utilize the UNIX makefile Program and document dependencies among data sets and programs (Figure 5.) Enforce these dependencies by executing the UNIX makefile after any change to data or programs CUSTOMER NEEDS: TIMELINESS Requirements A well-designed and accurate data warehouse will not make much of an impact if its delivery is not timely. The following requirements exist for ensuring that the date warehouse is ready for customer access: Data appropriately clean when delivered Data appropriately current Implementation To implement timeliness of development and delivery of the data warehouse, the following procedures are recommended: Determine periodicity of cleaning and refreshing data At regular intervals At specific milestones Execute UNIX makefile at appropriate time to refresh data DATA WAREHOUSE COHESION AND TRACKING Unlike formal data warehouse products, where pulldown menus and component dependency tracking may be readily available, the use of generic software packages precludes any automatic tracking and consistency checking among data warehouse components. The developer must institute such monitoring themselves. Creation of a checklist is recommended in which each step of the process is identified and acknowledged as completed. Development of programs that check consistency is also beneficial.

5 The following items should exist in the completion checklist: Extract data from operational database Add stratification variables, study day, and common visit identifiers to all data sets Document derivations for analysis data sets Code and validate analysis data sets Update metadata database if needed Code UNIX makefile Produce detailed listing of data set variables and their metadata Author data usage tips If the data warehouse is to be submitted to the FDA, conversion of SAS data sets to transport format and validation of this process should be added to the checklist. DATA ACCESS AND REVIEW METHODS There are numerous data review packages that can easily access SAS data sets or transport files. Company and FDA scientists are generally familiar with at least one of these products. According to current FDA electronic submission guidelines, SAS transport files of clinical study data are to be delivered. It is recommended that the sponsor company provide the FDA with sample code for converting transport files back into SAS data sets if this process is needed. Figure 2. below identifies some of the data review products that are in use by company and FDA reviewers as well as the processes needed to make the data accessible to these tools. Figure 2. Data Access Products and Methods Access Product Operating System Used Data Type Used SAS Desktop or SAS data sets SAS System Viewer Data Conversion and Transfer Methods from SAS Data Sets on UNIX FTP to desktop if not using SAS on UNIX UNIX Desktop SAS data sets FTP to desktop JMP Desktop SAS transport files SAS proc copy, FTP to desktop SPlus Desktop or UNIX SAS data sets FTP to desktop if not using SPlus on UNIX Excel Desktop Excel spreadsheets FTP to desktop, SAS import/export wizard

6 CONCLUSIONS Software tools common on the desktops of most clinical programmers can be easily harnessed for development of a clinical data warehouse, alleviating the need to invest money and time into a sophisticated data warehouse product. Strategic use of these common tools can effectively meet the FDA s GCP and electronic submission requirements, reduce additional expenditures for software, and reduce the data warehouse development learning curve. These features aid the company s bottom line not only in conserving funds for software, but also by facilitating flexible training, hiring, and transfer of staff. The major disadvantage of using common tools rather than a formal data warehouse product is that there is no automatic tracking of technical tasks and processes performed. This issue can be addressed by creating a list of tasks and processes, and checking off each one as it is completed. TRADEMARK CITATION SAS and all other SAS Institute Inc. product or service names are registered trademarks or trademarks of SAS Institute Inc. in the USA and other countries. indicates USA registration. Other brand and product names are registered trademarks or trademarks of their respective companies. CONTACT INFORMATION Author: Patricia L. Gerend Senior Manager, Statistical Programming Address: Statistical Programming Department Mailstop #66 Genentech, Inc. 1 DNA Way South San Francisco, California gerend.patricia@gene.com

7 Figure 3. Detailed Listing of SAS Data Set Variables Data Set STAT: Statistical Analysis File with Baseline and Outcome Information Variable Name Description Type Length Format Name Format Value Format Decode AGE Age at randomization Numeric 8 BESTRESP Best response on study Numeric 8 RESPFMT 1 Complete response 2 Partial response 3 Stable disease 4 Progressive disease 5 Unable to determine CADX Cancer diagnosis Numeric 8 CADXFMT 1 Superficial 2 Visceral PCHEMO Prior chemotherapy (n/y) Numeric 8 NOYES 0 No 1 Yes 2 Not available PHORM Prior hormonal therapy (n/y) Numeric 8 NOYES 0 No 1 Yes 2 Not available PRAD Prior radiotherapy (n/y) Numeric 8 NOYES 0 No 1 Yes 2 Not available TX Treatment on study Numeric 8 TXFMT 1 Active 2 Control

8 Figure 4. Derivation Methods for Statistical Analysis File STAT Variable Name Variable Label Derivation Method age Age at randomization (years) Number of full years from birthdate (demog.birthdt) to date of randomization (stat.strtdate) bestresp Best response on study Set to best response on study from independent review committee (bestrev) when available; otherwise, set to best response on study from investigator (bestinv) cadx Cancer diagnosis Directly from cahx.cadx pchemo Prior chemotherapy (n/y) Set to 1 (yes) if patient received any chemotherapy (ptx.ptxdes=3) in the adjuvant setting (ptx.ptxcode=1) phorm Prior hormonal therapy (n/y) Set to 1 (yes) if patient received any hormonal therapy (ptx.ptxdes=2) in the adjuvant setting (ptx.ptxcode=1) prad Prior radiotherapy (n/y) Set to 1 (yes) if patient received any radiotherapy (ptx.ptxany=1 and ptx.ptxdes=1) in the adjuvant setting (ptx.ptxcode=1) tx Treatment on study Directly from randivrs.tx

9 Figure 5. Sample UNIX Makefile ################################################################ ### UNIX Makefile for oncology study ### ### ### ### Raw transport files are converted to SAS data sets. ### ### Analysis files (data warehouse) are created. ### ### Listings, tables, and graphs are produced. ### ### Dependencies among all input, output, and programs are coded here. ### ### ### ### Programmer: Jane Doe 7/31/2000 ### ################################################################ # All systems addressed by the makefile system: \ rawdata \ warehouse \ formats \ listings \ tables \ graphs # end of system # Excerpt from data warehouse section of makefile # #===========================================# warehouse: \../outdata/stat.ssd01 : \ stat.sas \ rawdata/cahx.ssd01 \ rawdata/demog.ssd01 \ rawdata/ptx.ssd01 \ rawdata/randivrs.ssd01 sas stat.sas # end of warehouse

10