Using Proc Report Compute Blocks to Enhance ODS RTF Output

1 Paper PO12 Using Proc Report Compute Blocks to Enhance ODS RTF Output David Ryerson, Colorado Prevention Center, Denver, CO ABSTRACT Use of the Output Delivery System to create Rich Text Files has been well documented by SAS Institute as well as in conference papers such as this. As demand has persisted for better formatting and greater control over Output , SAS software has introduced several features including style statements within procedures, in-line formatting, and the ability to insert cell formatting RTF control words.

2 Users have taken these tools and combined them with novel coding techniques to create solutions such as traffic-lighting of cells, pagination schemes, and an ever increasing ability to format cells and tables. Rather than offering an overview of the mechanics of Proc Report and the Compute Statement, this paper will focus on several specific techniques to improve the appearance of tables. Indentation of secondary values in a column, conditional highlighting of cells, and visual separation of Report sections will be covered.

3 The simple ideas will be incorporated into an adverse events table that will combine all ideas into one coherent example. INTRODUCTION In addition to performing data step like operations such as creating variables and arrays, and computing summary statistics, Compute Blocks in Proc Report can be an especially useful tool for creating visually pleasing tables. The break and rbreak statements can provide a convenient way of breaking up tables, however, some of the options commonly used with these statements such as overline, underline, and skip can not be applied to the ODS RTF destination.

4 Fortunately, Using in-line formatting and RTF keywords within Compute Blocks allows us to accomplish the same functionality as native SAS keywords while extending our ability to control the look and feel of the tables. Code for the example was executed in version of SAS software. DESCRIPTION OF DATA The dataset used in this paper includes adverse event data already summarized (count and percent of subjects experiencing an event) by a category (high level term) and sub-category (low level term) for each of two treatment groups within two dose cohorts.

5 The first observation in the dataset is a summary line that indicates how many subjects had at least one adverse event. Since the text of high and low level terms can be rather long, the two have been combined into one variable, hlt_llt_txt, and another variable, type, indicates whether it is a high level term ( hlt ) or a low level term ( llt ). The variable, hlt_indx, has been created to aid in the visual separation of the high level terms. This index variable is retained and is incremented for every new high level term.

6 Hlt_indx is set to 99 for any uncoded terms. A variable called pageno is included for page breaks and to help position footnotes. Refer to Appendix II for a listing of the input data. DESCRIPTION OF Output The goal of the example program is to create a summary table with the following attributes: 1) A summary line ( At Least One Adverse Event ) will be placed at the top of the table. This line is somewhat distinct from the rest of the table as it summarizes everything below it. In order to make it visually distinct, the line will be separated from the rest of the table with a space before, a space after, and a bold dashed line.

7 2) Similarly, each grouping of high level terms might be considered distinct from the next. To emphasize this, a thin dashed line and a space will be inserted after each group. 3) As described above, the high level terms and low level terms have been combined into one term in order to save space on the page. In order to make the two decipherable they need to be differentiated visually. To do so, the lower level terms will be indented and the high level terms will remain left justified. 4) Uncoded terms should be differentiated from those that have been coded.

8 Depending on the type of Report , some of the adverse events may still be in the process of being coded when the tables need to be created. This is often the case for Data Monitoring Committees where reports are made with all available information (coded or not) at distinct time points throughout the course of a study. Data with uncoded terms need not be excluded. The adverse event description variable from the case Report form can be used in place of the low level term for those that have yet to be coded.

9 For the table in this paper, a superscript will be added to the UNCODED place-holder for the high level term and a footnote will be included to explain what is happening. For good measure, the uncoded low level terms will be highlighted by formatting the text in red. PARTIAL Output Table Protocol XXXX-XXX - Summary of Adverse Events High Level Term mg/kg mg/kg Low Level Term Drug (n=8) Placebo (n=2) Drug (n=8) Placebo (n=2) At Least One Adverse Event 5 ( ) 1 ( ) 7 ( ) 1 ( ) BLOOD DISORDERS 1 ( ) 0 ( ) 1 ( ) 0 ( ) Anaemia 0 ( ) 0 ( ) 1 ( ) 0 ( ) Haemolytic Anaemia 1 ( ) 0 ( ) 0 ( ) 0 ( ) CARDIOVASCULAR 5 ( ) 1 ( ) 6 ( ) 1 ( ) Angina Pectoris 2 ( ) 0 ( ) 1 ( ) 0 ( ) Arrhythmia 1 ( ) 0 ( ) 1 ( ) 0 ( ) Arteriosclerosis 1 ( ) 0 ( )

10 1 ( ) 0 ( ) Cardiomyopathy 1 ( ) 1 ( ) 1 ( ) 0 ( ) Extrasystoles 0 ( ) 0 ( ) 1 ( ) 0 ( ) Tachycardia 0 ( ) 0 ( ) 1 ( ) 1 ( ) UNCODED1 1 ( ) 1 ( ) 1 ( ) 0 ( ) Diabetic Hypoglycemia 0 ( ) 0 ( ) 1 ( ) 0 ( ) Sinus Tachycardia 1 ( ) 0 ( ) 0 ( ) 0 ( ) Uric Acid Increase 0 ( ) 1 ( ) 0 ( ) 0 ( ) Data are number of subjects experiencing event and percent per treatment group in parentheses. 1 Low Level Term is taken from the verbatim variable 'aedesc' for uncoded (red) terms. Note: Several groups were removed to limit the space required.