Using Proc Report Compute Blocks to Enhance ODS …

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. 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.

2 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. 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.

3 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. 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.

4 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. hlt_indx is set to 99 for any uncoded terms. A variable called pageno is included for page breaks and to help position footnotes.

5 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. 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.

6 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. 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.

7 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. 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 ( ) 1 ( ) 0 ( ) Cardiomyopathy 1 ( ) 1 ( ) 1 ( ) 0 ( ) Extrasystoles 0 ( ) 0 ( ) 1 ( ) 0 ( )

8 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. See Appendix III for full output . SEPARATE SUMMARY LINE FROM Report The first order of business is to separate the At Least One Adverse Event summary row from the rest of the table.

9 This can be done by Using a call define statement within a Compute block. The goal is to affect an entire row rather than just one cell. Here s the code: /*visually separate summary row, and high level term groupings*/ if type eq "hlt" and hlt_indx=1 then do; call define(_row_,'style','style={protectspec ialchars=off pretext="\line\brdrb\brdrdashdotstr " posttext="\line"}'); end; Since the input dataset is presorted we know that hlt_indx will always be equal to 1 for the summary row. Note that the call define statement has three parameters, 1) column or row declaration 2) attribute-name 3) value.

10 In this particular call define statement, _row_ is used for the row or column declaration to tell SAS where the formatting should take place, and the RTF code in the third parameter does the rest. Also note that both pretext and posttext options are used here. The former simply inserts RTF code before the text in the cell or paragraph, and the latter inserts after the text. Before the text, \line\brdrb\brdrdashdotstr is included which inserts a blank row before the summary row (simply for spacing), and creates a striped border. \brdrb indicates that the border below the cell or paragraph is being modified.