Automating the Creation of Data Definition Tables (Define.pdf) Using SAS Version 8.2

Transcription

1 Automating the Creation of Data Definition Tables (Define.pdf) Using SAS Version 8.2 Eugene Yeh, PharmaNet, Inc., Cary, NC Syamala Kasichainula, PharmaNet, Inc., Cary, NC Katie Lanier, PharmaNet, Inc., Cary, NC ABSTRACT One component of an electronic NDA submission to the FDA is the metadata file Define.pdf, which contains documentation of Case Report Tabulation (CRT) datasets. This file contains a list of dataset names and their descriptions and location. For each dataset, a list of variables and their associated attributes (e.g. length, label, format name, list of decoded values, etc ) are described. Prior efforts to automate the creation of Define.pdf using a SAS version 6.12 program had limitations in handling large text fields and the PDF file format. We have made enhancements to Define.pdf, including the addition of new SAS variable attributes, as well as automating the inclusion of a generic text comment field, used to display the variable source and the definition of derived variables. We used the Output Delivery System (ODS) in SAS version 8.2 and its capability to handle large text values (over 200 characters) such as derived variable definitions and lists of decoded values to directly generate Define.pdf from a SAS program. INTRODUCTION One component of an electronic NDA submission to the FDA is the metadata file named Define.pdf. This file is made for each clinical study in the submission, and contains documentation of the case report tabulation (CRT) datasets. Define.pdf provides useful background information to any FDA reviewer. As specified by the FDA guidance documents (1, 2), Define.pdf contains a list of clinical dataset names along with its description and file location (see Figure 1). For each dataset, the list of its variables and their associated attributes are displayed (see Figure 2). In the column labeled Comments, variables that originate directly from case report forms (CRFs) can link to the corresponding page of the standard annotated CRF file, Blankcrf.pdf. Variables that are derived during data analysis display the text description of their derivation. The list of parameters in Define.pdf specified by the FDA is not inclusive, but is intended to serve as a starting point for the file structure. FIGURE 1 Raw Datasets for Study ABC Dataset Description of Location Dataset ADE Adverse Events Crt/datasets/ABC/ade.xpt DEMOG Demography Crt/datasets/ABC/demog.xpt Although the traditional users of SAS datasets may be programmers and statisticians, tailoring the structure and naming convention within the datasets for the benefit of FDA reviewers is now increasingly important (3). Inclusion of additional features to Define.pdf can enhance its usefulness for FDA reviewers. The reviewer might want to know the following about a dataset: is this dataset sorted? If so, what are the sort variables?; Is there more than one record per subject?; Using the SAS Viewer, what column can I find variable X? The usefulness of any feature will depend, in part, on the discipline of a particular FDA reviewer. A quality control analyst or medical reviewer might not find the SAS format attribute useful, whereas a SAS programmer doing exploratory analyses might find it highly desirable. Likewise, a statistician might want to know the algorithm used to define derived variables, whereas other types of reviewers may ignore this text. FIGURE 2 Study ABC Demographics Dataset Variables Variable Label Type Codes Comments PATID Unique patient identifier Gender of subject Char SEX Char m = male f = female Demographics page 1 Demographics page 1 It would be ideal to have a single SAS program create Define.pdf for all the CRF-based and derived analysis datasets. Most variable attributes that are required by the FDA, along some additional attributes, are intrinsic components of the SAS system. This information is contained in the dataset contents and format catalog(s). The FDA guideline of a maximum length of 8 for the variable name, and 32 for the variable label, are well within the specifications of the dataset structure in SAS version 6 and higher. SAS version 8.2 has a maximum length of 32 for the variable name and 256 for the variable label. The use of external files by a SAS program may be unavoidable since some attributes are not part of the SAS System. Developing a robust and user-friendly method of structuring the external files needed, and combining them with the SAS components, is crucial to automating the creation of Define.pdf from a SAS program. One survey of FDA reviewers revealed their desire to see more detail in the variable definitions displayed in the comment field (4). Inevitably, providing more detailed text would require programs to manipulate longer character strings. Prior programming efforts to automate the creation of Define.pdf using SAS v6.12 to v8.2 had limitations in the following topics: inclusion of some variable attributes, handling large text fields, and directly creating a PDF file (5, 6, 7, 8). The output files created by these methods had a file type of RTF, DOC, or HTML, which required further processing by various software applications to ultimately create the PDF output file, Define.pdf. SYSTEM We are running Microsoft Windows 2000, Win2000 servers, Microsoft V5.00 Terminal Server Client, and SAS version 8.2 in production. PURPOSE We have made enhancements to our previous programming efforts (5, 6) to create Define.pdf with a single SAS program (Define.sas) in the following areas: 1. Creation of a PDF file (Define.pdf) directly from a SAS program without the use of custom macros or any other software applications

2 2. Automate the creation of bookmarks 3. Identification of sort order variables, often used as key variables 4. Display of the variable position 5. Arranging the list of variables within each dataset in a logical order with the variables used for sorting at the top of the list. 6. Capability of handling longer text fields (e.g. dataset description, variable name, variable label) limited by the maximum lengths permitted by SAS v Improve the display order of decoded values, including large text fields, and handling the use of several format catalogs. 8. Storing a text comment field for each variable without creating additional files. This field displays additional information such as the variable source (i.e. variable origin) described by a CRF location or source dataset(s). For a derived variable, a text description of its definition is included. Define.sas requires the following inputs: the raw and derived datasets, the format catalog(s), the SAS analysis file programs, and the output directory to place Define.pdf. An example of the Define.pdf we created is shown in Figures 3, 4 and 5. In this paper, we present a practical way to use straightforward SAS v8.2 code in a single program to directly create Define.pdf. The key programming elements are discussed below. VARIABLE DISPLAY ORDER The list of variables within each dataset is arranged in a logical order. The variables used for sorting (often matching the key variables, used to maintain uniqueness), are placed at the top of the list in Define.pdf (see Figure 5). The remaining non-sorting variables are placed after the sorting variables, ordered alphabetically by their variable name. The overall row order in Define.pdf corresponds to the column order of the actual dataset (see Figure 6) as seen using SAS or the SAS Viewer. Any dataset can be restructured to change the column order (i.e. variable position) and sort order using the following code: Data Dscrf01; Retain sortvar1 sortvar2 A_var B_var C_var; Set Dscrf01; Run; Proc sort data=dscrf01 (label=description of DSCRF01); By sortvar1 sortvar2; Run; Sortvar1 and Sortvar2 are the names of the sorting variables and A_var, B_var, C_var are the names of all the non-sorting variables, listed in alphabetical order. DATASET CONTENTS The datasets to be described by Define.pdf are placed into a common directory defined by a library name, libref. The list of variables found in each dataset, along with its attributes are placed into a temporary dataset ds_contents using the code: PROC CONTENTS DATA=libref._ALL_ OUT=ds_contents;. The list of attributes included: Attribute name (SAS name) Dataset name (memname) Dataset label (memlabel) Variable name (name) Variable label (label) Variable position number (varnum) Sort variable order (sortedby) Variable type (type) Variable length (length) The additional attribute of variable format name can be constructed from the PROC CONTENTS variables FORMAT, FORMATL, and FORMATD. DISPLAYING CODED VALUES If variables have coded values (e.g. 1=male, 2=female), the entire list of all possible codes (e.g. 1, 2) and corresponding decodes (e.g. male, female) are displayed together in a field labeled Codes in Define.pdf (see Figure 2). The list of all possible decoded values are defined by SAS formats, which are stored in a format catalog. When Define.pdf is given to the FDA, an accompany format catalog file may also be given or, alternatively, the SAS code which creates the format catalog can be given, so that the format catalog can be recreated by the FDA reviewer. The latter method can be a useful way to overcome any incompatibility problems arising from dealing with different software versions and platforms. Prior to finalizing Define.pdf, the SAS working environment may have multiple format catalogs that are referenced by the same set of datasets. If a given variable refers to a format name that exists in two or more of the format catalogs, the value of the SAS system option, FMTSEARCH, dictates the order in which a set of specific format catalogs are searched for the presence of that format name. For example, if 3 format catalogs are referenced in the order defined by OPTIONS FMTSEARCH=(study1 drug1 global), any given format name associated with a variable is first searched for in the format catalog in library reference study1, and if it is not found, then a new search is made for the format name in the format catalog in drug1, and global, if needed. When generating the list of decoded values, the same order of succession must be applied in determining which format catalog to access for each format name. The search order of multiple format catalogs defined by the SAS system option, FMTSEARCH, can be stored in the macro variable fmtorder using the following code: Data _null_; set sashelp.voption (where=(optname='fmtsearch')); call symput ( fmtorder,compress(setting,'()') ); run; If the FMTSEARCH option was set to a blank value, the single format catalog can be assumed to be in library reference LIBRARY. All the formats and their list of decoded values in the format catalog study1 can be place into a dataset ds_study1 using the statement: PROC FORMAT LIBRARY = study1 CNTLOUT = ds_study1. Several coded values can share the same decoded value (e.g. 1-3= mild, 4-6= moderate, 7-10= severe or n = no, N = no, y = yes, Y = yes ). Constructing a user-friendly listing of decoded values from the format catalogs, when this occurs, becomes complicated since multiple observations in the format dataset must first be grouped by the decoded value, then sorted by the coded value, and then combined with all observations

3 sharing the same decoded value. For example, a user-friendly display of decoded values grouped together is n, N = No, y, Y = Yes, as opposed to the same ungrouped list of decoded values found in a format catalog n = No, N = No, y = Yes, Y = Yes. After processing a dataset for each format catalog used, the entire list of all possible codes and corresponding decodes for a given format, is combined into a long character value. This list of decoded values could occupy more than an entire page (e.g. a list of medication routes, or investigator names and addresses). However, since character variables in SAS v8.2 are no longer limited to a maximum of 200 characters, this long character value can be stored in a single variable using only a single observation for each formatted variable in every clinical dataset. For these variables, the list of decoded values is displayed in a user-friendly sequence in the Codes field in Define.pdf (see Figure 5). THE TEXT COMMENT FIELD A text comment field for each variable can be used to display additional information such as the variable source or a text description of a derived variable. The closest variable attribute within the SAS System to the text comment field is the SAS variable label, capable of storing 256 characters. However, the SAS variable label is used for a unique and separate purpose. For clarity, the SAS variable label should not be used to store additional types of information. With a separate text comment field not inherent to the SAS System, a programmer can choose many different approaches to store this metadata and incorporate it into Define.pdf. Any external file format that allows easy data entry such as ASCII, Microsoft Excel, Microsoft Word files, could be used. Since we define all derived variables in the SAS code within analysis file programs, we found that placing the text description of the corresponding algorithm in the same program was a practical and efficient way to store the text comment field. Some advantages of placing the text field in the same analysis file program are: 1. No additional files need to be created since the analysis file program already exists. 2. If modifications are made to the SAS code, which executes the algorithm of a given variable, modification to the text comment field can be made at the same time without having to find, open, modify, and save any other file. 3. Adding the text description of the algorithms to the header section of an analysis file program is one practical way to document the function and purpose of the program. A comprehensively documented program header is beneficial to anyone reviewing the program at a later time. 4. No additional software is needed to enter and update the text comment field metadata, since the same software is used to edit the analysis file program. 5. If the SAS program is copied or moved to a different location, the text comment field is automatically copied or moved to the same location. 6. By decentralizing the location of all the text comment fields, we avoid the risk of interfering with or locking out multiple users trying to simultaneously open and write to the same centralized file. Since each SAS program only contains the text comment fields for the variables in the dataset created by that program, several different users can simultaneously create or update text comment fields in different programs. Text Comment fields are placed into the program header section of an analysis file program. These comment fields are ordered alphabetically by their associated output variable name. Similar to the other sections of the program header, these comment fields appear as program comments during SAS software execution, thus preventing the text from being executed as SAS programming code. The programmer should update the text comment field whenever the corresponding coding of the actual algorithm is altered. The start of each text comment field is denoted by the variable name surrounded by the special delimiter characters -< and ->. The end of the text comment field is denoted by the next appearance of the same special delimiter - < or the standard SAS comment delimiter */. For example, this is a sample of text comment fields for the variables Firstdt, Lastdt, and Elapsed_days in an analysis file program. /*.. -<Firstdt>- Text description of variable Firstdt. -<Elapsed_days>- If Firstdt and Lastdt are not missing, Elapsed_days= Lastdt-Firstdt+1. Otherwise Elapsed_days is missing. -<Lastdt>- Text description of variable Lastdt. */ The actual choice of delimiter characters used is arbitrary, as long as the program knows what character values are used and the characters are not recognized by SAS as the end of a comment (e.g. ; or */ ). The maximum length of this comment field is only limited by the maximum length of character variables in SAS. The list of analysis file programs to process can be automatically stored in a dataset once the user identifies the directory path of the programs is a macro variable pgmpath. Using FILENAME saspgm PIPE "%STR(DIR/B %"&pgmpath\*.sas%" )" and a DATA step with an INFILE saspgm clause will re-direct the output from the MS-DOS command DIR/B to the input of a DATA step, which stores the list of programs of the file type *.sas. Using this list, Define.sas reads each analysis file program (*.sas) line-by-line as an ASCII file using another DATA step and FILENAME statement. By detecting the presence of the special delimiters, the output variable name and its associated text comment field string are defined in a separate temporary dataset. We chose to display the variable source (dataset name) in the text comment field. For derived variables, the variable source was followed by a text description of the algorithm used to define the variable. CREATING DEFINE.PDF So far, we created separate temporary datasets to store: (1) the PROC CONTENTS of all datasets, (2) the decoded values from each format used in the format catalog(s), and (3) the text comment field of each variable. We combine these datasets into a new dataset, Define.sas7bdat, where each variable in each dataset and all its attributes are stored in a single record. Datasets were merged one to one by dataset name and variable name. Using this combined dataset as an input to PROC REPORT, we used the code ODS PDF FILE= Define.pdf with the ODS in SAS v8.2 to create Define.pdf (see Figures 3, 4, and 5). TITLES AND BOOKMARKS The PROC REPORT is implemented several times to primarily handle the varying number of columns displayed within Define.pdf. The list of datasets in Figure 4 has three columns,

4 while the list of variables within each dataset has nine columns (see Figure 5). One FDA guidance document specifies a last section of Define.pdf (2). This section lists all the variables present among all datasets and can be displayed using two columns; one for the variable name and the other for the dataset name. Every time PROC REPORT is implement by the program, the results are appended to the end of the Define.pdf and two bookmarks are generated. The parent and subordinate bookmarks both link to the same location within Define.pdf. The name of the parent bookmark can be specified by using the code ODS PROCLABEL=.., just prior to implementing each PROC REPORT. The subordinate bookmark is always labeled "Detailed and/or summarized report. These bookmarks are not useful since they are all identical in name, and the parent bookmarks already navigate to the same locations. One option to minimize the redundancy among all bookmarks in Define.pdf is to hide all the subordinate bookmarks. This is done by clicking on all the icons that appear to the left of all the parent bookmarks until they display a + symbol rather than a - symbol (see Figure 3). A second option is to manually delete all subordinate bookmarks using Adobe Acrobat after running Define.sas. Since it is desirable to bookmark the beginning of each dataset description, a separate PROC REPORT was executed for each dataset. This also allowed us to change the title appearing at the top of the page to match the dataset being displayed. The name and sequence of the datasets included in Define.pdf were determined by the sort order of memname in the Define dataset. proc sort data=sasout.define (keep=memlabel memname) nodupkey out=dslist; by memname; run; To avoid hardcoding each dataset name and label (variables memname and memlabel) within the program, the statements ODS PROCLABEL, TITLE, and PROC REPORT were repetitively implemented using CALL EXECUTE within a DATA step, where the Dslist dataset was the input. Each PROC REPORT was limited to display the description of one clinical dataset by subsetting the overall Define dataset with a WHERE clause. One alternative to using CALL EXECUTE is to use a single PROC REPORT statement with a BY clause which would shorten the program code, and would still yield an output that is ordered by dataset name or label. Unfortunately, this method would also generate undesirable bookmark text and the title text (created using #BYVAL). Also, the sequence of datasets in the output could not be independently controlled from the text appearing in the title. DISCUSSION One advantage to the sponsor in submitting an electronic NDA versus an NDA on paper is the ease of navigation of an electronic file for the FDA reviewers, expediting the entire review process. Other advantages such as taking less physical space and the ability to cut and paste text have been sited by FDA reviewers (4). In two guidance documents, the FDA specifies that each study in an electronic NDA submission (enda) include a description of the clinical datasets in a file named Define.pdf (1, 2). Both guidance documents are very similar, except that the CBER document states that the final section of Define.pdf contains a list of all variables among all the clinical datasets (2). This section is absent from the CDER document (1) and its example version of Define.pdf (9). We have chosen to include the list of variables in our version of Define.pdf, but this section can be easily omitted from the program or deleted from the output file. The FDA provides guidance for the required elements and structure of the file, but has left the specification as a starting point of discussion between the sponsor and the FDA reviewer. Some FDA reviewers have suggested establishing standards for variables and variable names used within clinical datasets (4). The use of standard variables would streamline the process for a reviewer working on multiple projects across different sponsors. An industry organization has developed a standardized model for clinical datasets, including a list of standard variable names (10). One obstacle in creating Define.pdf from a SAS program is the fact that some metadata parameters are not intrinsic to the SAS system. For SAS v6.xx or earlier, there are two additional obstacles: (1) the value of some parameters may exceed 200 characters in length and (2) SAS programs cannot directly create PDF files. A programmer must develop a strategy to store and incorporate additional information with the metadata intrinsic to SAS in order to create Define.pdf. Since this can be more demanding than a simple programming task, the creation of Define.pdf has been addressed by a various number of commercially available software applications (11, 12, 13). These applications are either standalone products or utilize additional standard software applications (e.g. MS-Word with PDFMaker, Adobe Acrobat, Global Graphics Software Jaws PDF Creator ) to assist in the creation Define.pdf. CONCLUSION We presented a method of using a single SAS version 8.2 program to create Define.pdf that complies with the structure specified by FDA guideline documents. Our approach to creating Define.pdf differs from other methods because it does not rely on custom developed macros (6, 7) or any software application other than SAS (5, 6, 7, 8, 11, 12, 13). One advantage of using a single program to automate the creation of Define.pdf is that intermediate files are not needed, thus simplifying the process. Except for hyperlinking, post-processing the program output with additional software is also not required. This minimizes the likelihood of human error. The program is written in a generalized manner, so that it can be implemented with minimal modifications for different clinical studies. The program only requires the input parameters of the directories of the clinical datasets, analysis file programs, and format catalog(s). Our output file displays all of the practical variable attributes that are intrinsic to the SAS system and allows the display of a custom comment text field, without the need of any additional electronic files. Automating the inclusion of the text comment field in Define.pdf by storing the text in SAS program files has been successfully implemented by other software (13). Text comment fields are generic in nature and can be used to display different variable attributes (e.g. origin, role, derived variable algorithm, footnote references). We chose to display the variable origin and the text description of the variable definition in the same text comment field. We included the additional SAS variable attributes of variable position, variable format name and variable sort number in Define.pdf. Note that the SAS View, SASHELP.VCOLUMN, to the dictionary table DICTIONARY.COLUMNS, used by others (6, 8) to obtain the various variable attributes does not include the sort number attribute. By using PROC CONTENTS DATA=libref._ALL_ OUT=xxx, we were able to include this attribute as the variable SORTEDBY. We chose to include these attributes since they may be useful to FDA reviewers when viewing and using the datasets. These attributes are also readily available features within the SAS system. We also improved the handling of format catalogs and provided a more user-friendly display of decoded values compared to our previous programming efforts (5, 6).

5 With SAS version 8.2, one enhancement made to SAS Software, as compared to version 6.xx, is an increase in the maximum character variable length to 32,767 (compared to 200 in version 6.xx). Also, SAS programs can use the ODS to directly generate PDF files. These two features allowed us to implement a straightforward generic SAS program to directly create Define.pdf without the need for any external macros or additional software. Our program also delineates the major sections of Define.pdf by creating titles and bookmarks. The text used for the titles and bookmarks are automatically customized based on the dataset labels. FUTURE WORK IMPROVING THE APPEARANCE The PDF files created by the ODS statements in SAS v8.2 have several small formatting problems compared to the RTF files that could also be created using the ODS. Random text alignment problems and awkward text wrapping within cells are noticeable on occasion. Depending on the font used, some special characters may not be properly displayed. Since RTF files created by the ODS lack these flaws, these problems found in output PDF files will inevitably be fixed in future versions of SAS software. HYPERLINKS Bookmarks and hyperlinks are two major features that make PDF documents easy to navigate. Creating bookmarks and hyperlinks are usually a tedious manual process, which is prone to human error. Bookmarking is automatically implemented by our program and is not left as a manual process. Hyperlinked text is specified in the FDA guidance documents. The actual datasets and the first page of each dataset description are hyperlinked on page 1 of Define.pdf. Additional hyperlinks exist from the variable origin of CRF-based variables to the corresponding variable location in Blankcrf.pdf (the standard annotated case report form document). Unfortunately, implementing hyperlinks in a PDF output file cannot be accomplished in a SAS v8.2 program. This leaves the task of creating all hyperlinks in our version of Define.pdf as a manual process. Hyperlinking can be manually done using Adobe Acrobat. This process will hopefully not be necessary in the future, once SAS software improves in its ability to create hyperlinks within PDF files. EXPANDABILITY The FDA guidance documents set limits on the maximum number of characters used in the following data fields: dataset name, variable name, and variable label to 8, 8, and 32, respectively. If these limits are ever increased in the future, SAS v8.2 will likely still be capable of managing the metadata. It can handle a maximum length for the dataset name, variable name, and variable label of 32, 32, and 256, respectively. ADDITIONAL PARAMETERS A standard model for describing the structure of metadata of clinical datasets submitted to the FDA has been developed (14). The list of parameters in this model exceeds those given in the FDA guidance documents. These additional parameters (e.g. dataset structure, role) are not intrinsic to the SAS system. Including such parameters in Define.pdf would require additional data management. Although such parameters provide the reviewer with additional information, it also increases the complexity of creating Define.pdf. Commercially available software applications do address, in varying degrees, these extra parameters. The display of the Sort Variable in our Define.pdf is similar to the Keys parameter in the metadata model. We currently do not display the other parameters of Structure, Purpose, and Role in the metadata model. INTEGRATION WITH OTHER PROCESSES Define.pdf is one component of Item 11 (CRTs) of the enda. The other SAS programming tasks involved with Item 11, such as creating SAS transport files can be automated by executing SAS programs (5). This program may be integrated with the program that creates Define.pdf. If an enda contains several different clinical studies, each with a separate Define.pdf file, a table of contents (TOC) containing hyperlinks to all Define.pdf files within the submission can be constructed. This TOC document is called Datatoc.pdf in the FDA guidance documents. Such a file can be created by a SAS program, given that the location of Define.pdf files are known, but as mentioned before, all hyperlinks at this time, must be manually created. REFERENCES (1) Guidance for Industry: Providing Regulatory Submissions in Electronic Format NDAs. US Food and Drug Administration Center for Drug Evaluation and Research (CDER) (01/27/199) (2) Guidance for Industry: Providing Regulatory Submissions to the Center for Biologics Evaluation and Research (CBER) in Electronic Format - Biologics Marketing Applications. US Food and Drug Administration, Center for Biologics Evaluation and Research (CBER) 11/12/1999, Revised 11/22/ (3) S. Light, A. Siegel, The Changing Nature of SAS Programming in the Pharmaceutical Industry. Proceedings of the PharmaSUG 2001 Conference. (4) A. Oliva, Electronic Submissions: A Medical Reviewer s Perspective. Presented at the 38 th annual meeting of the Drug Information Association, June (5) D. Michel, Data Transfers Across Diverse Platforms, Proceedings of the XX th Annual Northeast SAS User s Group International Conference, (6) M. Becker, K. Moses, Data Definition Tables- Definition and Automation, Proceedings of the PharmaSUG 2002 Conference. (7) E. Dennis, J. Zhou, Using SAS Macros to Construct Items 5 and 11 of an Electronic Submission, Proceedings of the PharmaSUG 2002 Conference. (8) A. Rocha, P. Hamilton, Creating Case Report Tabulations (CRTs) for an NDA Electronic Submission to the FDA, Proceedings of the 25 th Annual SAS User s Group International Conference, paper 31, (9) Example of an Electronic New Drug Application Submission US Food and Drug Administration, Center for Drug Evaluation and Research (CDER) (2/17/1999). (10) Introduction to the CDISC Submissions Data Domain Models, Version 2.0, 12/12/2001

6 (11) Company: Datafarm, Inc., Product: DefinePDF, Website: (12) Company: Liquent, Inc., Product: FDA Compiler, an add-on to Liquent Coredossier 5.5 Website: (13) Company: Meta-Xceed, Inc., Product: Trialex System website: (14) D. Christiansen, W. Kubick, CDISC Submission Metadata Model, Version 2.0, 11/26/2001 ACKNOWLEDGMENTS The authors would like to thank Matt Becker and Monte Jarvis for their contributions to this project. CONTACT INFORMATION Your comments and questions are encouraged. Contact the authors at: Eugene Yeh PharmaNet, Inc Winstead Drive, Suite 505 Cary, NC Work Phone: Fax: Syamala Kasichainula PharmaNet, Inc Winstead Drive, Suite 505 Cary, NC Work: Phone: Fax: Katie Lanier PharmaNet, Inc Winstead Drive, Suite 505 Cary, NC Work: Phone: Fax: 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 trademarks of their respective companies.

7 FIGURE 3. Define.pdf - Bookmarks (left), portion of page 1 (right) FIGURE 4. Define.pdf, page 1 - List of datasets

8 FIGURE 5. Define.pdf List of variables in the derived dataset CVSDA FIGURE 6. Sample SAS Viewer display of the dataset CVSDA