Paper 014-2015

A Risk Factor Coding Custom Report

Created With ODS Report Writing Interface With Recent Literature and Peer Review

Robert Richard Springborn,

Healthcare Outcomes Center, Office of Statewide Health Planning & Development,

Sacramento, California

ABSTRACT

The ability to prepare custom designed reports and convey your message in a clear and concise manner is very important in today’s sophisticated business environment. Easy to read clearly designed reports can enhance your organization’s credibility and reputation. Traditionally, reports were created in SAS® using PROC REPORT, PROC TABULATE, or PROC PRINT with the final report converted to RTF or to PDF. Reports created using these procedures can be customized to a limited extent, however reporting requirements for clinical studies are often so highly customized that standard SAS® procedures cannot meet the requirements. ODS Report Writing Interface (RWI) provides maximum flexibility and full control of data placement in a table so that even the most rigid reporting requirements can be met with ease. The driving force for this topic was the need to create a hospital level risk factor coding report which compares California CABG Outcome Reporting Program (CCORP) clinical data, to OSHPD’s hospital administrative data, to verify risk factors used in a risk-adjusted operative mortality model. This model provides hospital and surgeon performance scores for coronary artery bypass graft surgery (CABG) in California. This paper describes a custom report generated with RWI and includes recent literature, a discussion of peer-review, and functional groups.

INTRODUCTION

RECENT LITERATURE

Before we build the custom report let’s review recent literature.

Traditionally, reports were created in SAS using PROC REPORT, PROC TABULATE, or PROC PRINT with the final report converted to RTF for viewing as a MS Word file or to PDF for viewing in Adobe Acrobat. Reports created using these procedures can be customized to a limited extent, however reporting requirements for clinical studies are often so highly customized that standard SAS procedures cannot meet the requirements. ODS Report Writing Interface (RWI) provides maximum flexibility and full control of data placement in a table so that even the most rigid reporting requirements can be met with ease.

O’Connor (2013) describes the next generation of ODS Report Writing Interface (RWI) as Enterprise Business Reporting. “Enterprise Business Reporting is the evolution of our traditional reporting framework to address advanced reporting requirements for the 21st century. Whether the reports are going be distributed in print, on the web, via email, or on a mobile device the Enterprise Business Reporting framework will easily accommodate all types of published reports without any format specific knowledge” (O’Connor 2013, p.1).

O’Connor (2013) also states “When publishing reports you have to take into consideration the output destinations because not all destinations support ODS LAYOUT, or possibly do not support all features equally. For example, when producing a PDF report you must take into consideration the physical page constraints, but when producing an HTML report the WEB browser has scroll bars so you don’t have any physical limitations. These external physical constraints provide additional restrictions on how your grid will behave” (O’Connor 2013, p.1).

Finally, O’Connor (2013) reminds us that ODS LAYOUT and ODS Report Writing Interface (RWI) goes far beyond traditional tabular output produced by procedures “The custom report writing capabilities are also more commonly referred to as DATA _NULL_ report writing which has long been an integral part of the SAS reporting solution. The ODS Report Writing Interface is intended to fully embrace ODS features such as proportional fonts, traffic lighting, colors, images, and Unicode characters, while at the same time providing pixel perfect placement capabilities. This interface has methods to allow you to produce tables, text, insert images, and control the placement of everything in the report. This interface is not only fully integrated with all the capabilities of the ODS System, but also takes advantage of the rich programming features that the DATA step offers, such as conditional logic, formatting capabilities, by-group processing, arrays, and a wealth of other features. The ODS Report Writing Interface is an

1

A Risk Factor Coding Custom Report Created With ODS Report Writing Interface, continued object-oriented language that provides you with flexibility and control to address even the most rigid reporting requirements with ease” (O’Connor 2013, p.1).

O’Connor (2009, 2013) and Kummer (2014) provide the best source of information for those who wish to learn ODS Report Writing Interface (RWI). The custom report featured in Springborn (2013) was built by first running example code from O’Connor (2009) and then modifying that example to use real data instead of ficticious data, and adding additional object funtions and options for enhanced effects. The complete reference source that contains all object functions and their options for both gridded and absolute layout types is titled SAS ® 9.4 Output Delivery System: User’s Guide, Third Edition (http://support.sas.com/rnd/base/datastep/dsobject/index.html).

The literature contains many examples of how ODS Report Writing Interface has dramatically enhanced users ability to create custom reports. A few recent examples are given below.

Springborn (2012, 2013) showcases how creating custom reports using ODS Report Writing Interface (RWI) is a dramatic improvement over traditional methods such as Dynamic Data Exchange (DDE). The author also provides and explains the SAS code used to create the custom report.

Zhang (2011) demonstrates how an adverse event review custom report can be created using ODS Report Writing Interface (RWI) without using auxillary software such as MS Access and MS Word. “The adverse event review report contains data from INTERMACS (Interagency Registry for Mechanically Assisted Circulatory Support) a national registry for patients who are receiving mechanical circulatory support device therapy to treat advanced heart failure. All of the data is collected online through the United Network for Organ Sharing (UNOS) in Richmond, Virginia; and all the analyses and reports are processed in the INTERMACS at the University of Alabama at Birmingham. We receive 37 SAS datasets from UNOS periodically, which include all kinds of information regarding mechanical heart transplantation. The report is composed of two parts, on the top is the Patient Information Overview, and then followed by the Event Worksheets that correspond to the high-lighted events listed in the Patient Information Overview. The adverse event review report is sent to doctors periodically to verify if stated events or causes are valid” (Zhang 2011, p.1). Several features of the report require the use of ODS RWI including: a) the need to dynamically adjust horizontal and vertical spacing of text and numeric values according to the length of the values; and b) the need to order Event Worksheets by event date which should be in the same order of events listed in the Patient Information Overview. The author uses several programming tricks to customize their report including: a) creating a report header with a logo and text; b) using macros to simplify inserting values or text in a table row; c) inserting a column header for tables that continue to additional pages; d) inserting special charactes such as a “box” to input a response; and e) adding traffic lighting to high-light events listed in the Patient Information Overview.

Duan and Feaster (2012) create a two-page clinical study custom report. Each page contains a single table with six sections of page header, table title, table header, table body, table footnote, and page footer. The authors simplify the program code by using macros to create each of the six sections. The authors use several programming tricks to customize their report including: a) a title containing “this page” of “last page;” b) a table header with column labels containing trailing superscripts; c) a table footer with text containing file path, file name, date and time report created, and leading superscripts; and d) ejecting a page to ensure the first page of a new table appears on an odd page. The best part is the authors provide the SAS program code which creates the clinical report.

Lund (2013) gives a step-by-step example of how ODS Report Writing Interface (RWI) can be used to create a table by beginning with an ODSOut object method which writes text to the printed page and then adding object methods to: add a border to create a box with text; join two boxes with text to create a single row; create additional rows of two boxes joined with text; join the rows into a single table; add a header row of different color with column labels; modify font style, justification, and cell padding of text values and numbers; and create a region with one container to position the final table on the page. Lund (2013) also provides an example which creates a Table of Contents, however two programs are being used. The first generates information needed for the table of contents such as contents text, page number, and indent level and puts that information in a worksheet. The second program reads this information and uses ODS RWI to build the table of contents. Finally Lund (2013) provides an example of creating and completing a two-page form using macros. Again, information such as position of text, font size, and font weight are placed in a worksheet and the ODS RWI program code uses that information to build and complete the form. This example includes the use of PROC TEMPLATE to provide separate background images for each page of the report.

Cole and Baxter (2013) describe an automation process to consolidate data from multiple sources for the purpose of creating a single document or “codebook” for data review. The authors explain “The National Food Study collects data using multiple survey instruments including computer assisted personal interviews (CAPI) and paper instruments. Codebooks provide critical documentation of survey data, including: variable names, code definitions, the distribution of responses, and the full question text as it was read to respondents. The codebook program developed for the National Food Study enabled the authors to quickly and efficiently generate codebooks from multiple data files and for multiple survey instruments. This enabled the authors to quickly review their data after completing fieldwork, and provide documentation to the client that consolidated information from the survey instruments and data files” (Cole and Baxter 2013, p.1,10).

2

A Risk Factor Coding Custom Report Created With ODS Report Writing Interface, continued Kummer (2014) notes that report writing using SAS has evolved considerably over the years. The author states “Reporting in general, and arranging SAS output on a page in particular, has always been challenging and somewhat limited within SAS. For the longest time you could display your output in one column only or use PROC GSLIDE/GREPLAY or PROC DOCUMENT to somehow arrange it. Even the addition of the COLUMNS= option for the ODS PDF statement left the user with limited control about the placement of output. With the introduction of ODS LAYOUT and the ODS Report Writing Interface (RWI), these challenges and limitations are now a thing of the past” (Kummer 2014, p.1).

Kummer (2014) describes the difference between ODS LAYOUT and ODS Report Writing Interface, “In short, ODS LAYOUT provides a set of new ODS statements to arrange output objects that come from various sources (for example SAS procedures) with a never before experienced flexibility and control. The ODS Report Writing Interface lives within the DATA step, and displays individual, computed, or aggregated values from an input data set with the same flexibility and control as ODS LAYOUT allows it for procedure output. The term output objects refers to output from SAS procedures (for example graphs and tables), the DATA step, and also to plain text and images.” (Kummer 2014, p.1)

Kummer (2014) describes two types of layouts available within ODS LAYOUT namely absolute layout and gridded layout. “In general, starting a layout (no matter the type) with the ODS LAYOUT statement creates what we call a layout container. This container defines the space where the different kinds of output objects can be arranged in. The ODS LAYOUT statement controls the type, size, and placement of the container, but also the behavior within it. Depending on the type of layout, this container can have a fixed size and position, or it can be sized and positioned dynamically. Individual region containers are specified inside this layout container. These region containers are controlled with the ODS REGION statement. Again, depending on the type of layout, these region containers can have a fixed size and position or they can be sized and positioned dynamically. The actual output objects are displayed inside the individual region containers. A single region can display one-to-many output objects” (See Kummer 2014 p.1).

Kummer (2014) provides an example of a gridded layout (pages 2-4). “A gridded layout arranges your output objects in a very dynamic fashion and reflects a two-dimensional grid structure similar to a spreadsheet or table. The regions of a gridded layout are arranged in columns and rows. Every single item in this grid can be customized: From column and row spanning, to the veritical and horizontal space between the regions, but also the size and position of the regions themselves. The big strength of a gridded layout is the automatic alignment and sizing of the respective regions. Another feature that makes a gridded layout very dynamic is the possibility to automatically advance to new regions based on certain criteria like BY-groups among others. For example, each table or graph result from a BY-group is displayed in its own region without specifically using an ODS REGION statement for each BY-group” (See Kummer 2014, p.2).

Kummer (2014) provides an example of an absolute layout (pages 5-7) “While a gridded layout is very dynamic in populating a report, an absolute layout is more static in nature. Static when talking about the placement of the region containers. An absolute layout is not restricted to columns and rows, but rather follows the concept of layers. The regions are generally defined by an X and Y coordinate and a width and height. Correct use and order of specifying the region position and dimensions are crucial with this type of layout, as regions can overlap each other. Therefore, some type of design phase is beneficial before starting to write code. This can help to avoid resizing one or more regions whenever changing the position and dimension of preceding ones. While a region in a gridded layout can dynamically adjust to the size of the output object or objects that are displayed, an absolute layout region is empty if it is not sized properly” (See Kummer 2014, p.5).

Kummer (2014) explains that ODS Report Writing Interface (RWI), which lives within a DATA step, can also be used to create a gridded layout or an absolute layout. “The ODS RWI could be described as the DATA step’s PUT statement on steriods. It uses the ODSOUT object in combination with a set of methods to create reports within a DATA _NULL_ step. The biggest strength of the ODS Report Writing Interface is the possibility to display any variable that is available within the DATA step anywhere inside the defined space of the report. Besides presenting the data in tabular form, the ODS RWI can also use a gridded or absolute layout. The concept is exactly the same as for ODS LAYOUT. Instead of specifying ODS LAYOUT and ODS REGION statements, the respective methods of the RWI are used. The ODS RWI is confined to the information available within the DATA step. It can display only individual, computed, or aggregated values from variables available in the Program Data Vector (PDV)” (See Kummer 2014, p.7,10). In addition, images can be displayed, and titles, footnotes, and page breaks can be controlled within the DATA step.

The bonus is that Kummer (2014) provides “ready to use” program code for several examples. “If and how you use ODS LAYOUT or the ODS Report Writing Interface depends on your reporting needs. Both provide new ways to arrange different types of output within a report with ease. Before ODS LAYOUT and the ODS RWI were available, reports like the ones presented in this paper were just not possible. Perhaps the use of macros, data manipulation, and reporting procedures would get you close but the code necessary is large, complicated, and hard to maintain” (Kummer 2014, p.13).

Now let’s examine the problem that motivated the custom report.

3

A Risk Factor Coding Custom Report Created With ODS Report Writing Interface, continued TELL ME ABOUT THE PROBLEM

The Risk Factor Coding custom report was motivated by two factors. First, historically, the Risk Factor Coding report was created as a single MS Excel worksheet to compare hospital level prevalence rates of model risk factors between CCORP clinical data and Patient Discharge Data (PDD) administrative data sources. Prevalance rates were also assessed for the current data reporting period and four previous data reporting periods for both data sources. For the current data reporting period using only CCORP data, traffic lighting was used to compare the ratio of hospital prevalence rate to the California prevalence rate to identify three categories of questionable data as “as expected,” “higher than expected,” or “much higher than expected.” Historically OSHPD staff decided which hospitals would receive a follow-up phone call to discuss questionable data. Soon it became apparent that it was time consuming and impractical to call all hospitals with questionable data. The solution was to create a hospital level Risk Factor Coding report so each hospital could review their own results. In addition, the Risk Factor Coding report also assessed missing values. Missing values can occur if data elements are difficult to code or not applicable to many patients. Missing values were assessed as the ratio of hospital percent missing to California percent missing. Again the ratios were evaluated using traffic lighting to identify three categories of questionable data as “as expected,” “higher than expected,” and “much higher than expected.” Therefore the Risk Factor Coding Report will assess two different data quality measures. As a result sending an updated Risk Factor Coding Report to each hospital will greatly facilitate efforts to increase data quality for all California hospitals.

Secondly many organizations including OSHPD are transitioning from PC SAS to SAS Enterprise Business Intelligence (SAS EBI). So the updated Risk Factor Coding report had to be created and maintained using a SAS programming language compatible with SAS EBI such as SAS Enterprise Guide. OSHPD is the leader in collecting data and disseminating information about California's healthcare infrastructure, promoting an equitably distributed healthcare workforce, and publishing valuable information about healthcare outcomes. For some time, OSHPD has needed a more streamlined and powerful system for data storage and utilization. The new approach had to support more complex queries, integrate data sources, eliminate duplication, provide up-to-date reporting via web tools, consolidate and maximize resources, leverage current investments, and integrate IT solutions with considerable flexibility. To this end, OSHPD decided to upgrade the existing data environment with SAS EBI. SAS EBI is a comprehensive, easy-to-use business intelligence software solution that integrates the power of SAS Analytics and SAS Data Integration to provide insights that power better decisions.

This paper will provide an example of a custom report generated by ODS Report Writing Interface using SAS Enteprise Guide. The SAS program code and description of highlights are available from the author.

METHODS

DATA SOURCE FOR THE REPORT

The California Coronary Artery Bypass Graft (CABG) Outcome Reporting Program (CCORP) is the largest public reporting program on CABG surgery outcomes in the United States. Each year OSHPD releases the California Report on Coronary Artery Bypass Graft Surgery which presents findings from analyses of data collected from California-licensed hospitals where surgeons performed adult isolated CABG surgery. This report features risk-adjusted operative mortality used to evaluate hospital and surgeon performance. The California Report on Coronary Artery Bypass Graft Surgery, 2011 Hospital Data California CABG Outcomes Reporting Program can be found at (http://www.oshpd.ca.gov/hid/Products/Clinical_Data/CABG/11Breakdown.html).

CCORP reviews the data submitted by each hospital for completeness and errors. Using a three-step data quality review and verification process, CCORP asks hospitals to check; a) data collection and acceptance, b) data discrepancy reports, and c) risk factor coding reports. Data discrepancy reports were discussed in Springborn (2012, 2013). This paper will focus on risk factor coding reports which compare hospital’s prevalence rate of each risk factor to the overall prevalence rate for California. This prevalence rate is assesed for the current year and four previous years for both the CCORP and Patient Discharge Data (PDD) data sources. In addition to the use of data discrepancy reports and risk factor coding reports to identify questionable data, medical chart audit findings are used to identify hospitals with possible under-reporting and over-reporting of risk factors. CCORP requests hospitals to review and, when necessary, correct miscoded data elements. It is important to verify that risk factor values are accurate because these risk factors will determine hospital and surgeon performance published in the public report. To make fair comparisons of care delivered by different healthcare providers, it is necessary to adjust for differences in severity of illness (case mix) of patients across providers. CCORP “levels the playing field” by considering the pre-operative condition of each patient. Providers that handle more complex cases receive a larger risk-adjustment weight in the risk model, and providers that handle less complex cases receive a smaller weight. Thus, hospitals and surgeons treating sicker patients are not at a disadvantage when their performance is compared with other surgeons and hospitals.

4

A Risk Factor Coding Custom Report Created With ODS Report Writing Interface, continued OBTAIN PEER REVIEW DURING PROJECT DEVELOPMENT

Before we spend weeks and even months writing SAS program code, we need a plan to incorporate peer-review into the design and implementation of the new custom report. We want to show that the new custom report created with ODS Report Writing Interface contains the same information as the historical report created in MS Excel. It is a bad idea to create the custom report and simply assume managers and others will love the final product without any review. Managers and staff will have ideas to guide report layout which may include: inserting text notes and titles; changing the graph type or graph features such as line type, scale, titles, point labels, and legend; and changing the tabular data to inserting more or fewer columns in a table, change column labels, change numeric precision, add color enhancements etc.

For the programmer it is very difficult to be in the midst of building program code and suddenly stop and retrace your steps to make a report modification. I have a 50-page outline to guide me as I update program code to create a new custom report for a new reporting period. It is much easier to complete the draft report and then consider modifications. Managers and staff may ask for minor modifications to existing report layout which are easier to accomplish. But requests to changes to report layout such as inserting a new graph, a new table etc. may have to be postponed to future data reporting periods to allow time for testing a new report.

The solution is to develop a series of steps for building the custom report and include “bus-stops” where we obtain peer-review from managers and others. This reduces stress and make the entire process more enjoyable for everyone. Here is how I included peer-review in steps to build the Risk Factor Coding report.

1. Design the custom report by selecting examples of program code and sample data from O’Connor (2009, 2013) which place tables, graphs and other procedure output objects in the correct location on the printed page. Add titles, footnotes, and headers to achieve the desired appearance.

2. Consolidate all example program code and sample data into one program and one SAS data set. At this point the custom report will be reading data from one data set instead of several data sets.

3. Replace sample data with real data from the previous reporting period. Begin by running a PROC CONTENTS to determine: the number of variables; variable type as character or numeric; use of formats to group similar values; and numeric precision as number of digits after the decimel; required to create the custom report. Now write a SAS program to create the same variables from the real data source. This step will create a draft of the custom report using data from the previous reporting period. Previous reporting period can be last month for monthly reports, or last year for annual reports.

4. Compare the historical report created using MS Excel with the new report created using ODS Report Writing Interface using data from the previous reporting period. This is the first bus-stop to verify that the new report contains the same information as the historical report. The only difference between the reports is the report layout because the same data has been used for both. Also we can use the historical report to verify information contained in the new report. Managers need to know the new report contains the same information as the historical report with a few enhancements.

5. Create the custom report using data for the current reporting period. Here the managers have already approved the layout of the custom report. Now the only difference is the report uses data for the current reporting period. This is the second bus-stop where managers can again consider changes to the custom report. It has probably been a period of time since you created the custom report for the previous reporting period. During that time managers and staff may have additional comments. For this step I usually create 3 reports for review. If they have no comment I proceed with the last step.

6. Create the new custom report for all hospitals. There may be staff who distribute the reports to hospitals electronically, and respond to questions from hospitals. Be ready to assist office staff by providing information to clearly explain the new custom report to hospitals.

USE FUNCTIONAL GROUPS TO DEBUG PROGRAM CODE

All SAS program code should be documented with the date and code’s purpose. When program code is changed documentation should be updated. There are two forms of documentation. First, a short form where you insert high level short statements as comments in the program code. Second, a more detailed approach where a MS Word document contains line by line details of the SAS program code. Both types of documentation were used for the Risk Factor Coding report. Each time a new custom report is required for a new data reporting period, a new section is added to the MS Word document. Over time these sections create an archive of historical and current editions of the SAS program code.

Functional groups are used to group sections of SAS program code that have a similar purpose. When we document our SAS program code and use functional groups it is much easier to locate SAS program code which may be creating an incorrect result and provide a remedy. Here I must digress. SAS never creates an incorrect result. The programmer may have written SAS program code for a less than perfect objective. SAS is very loyal and does not question the programmer. SAS simply executes the imperfect SAS program code and gives you an imperfect result. You can smile now! Back to functional groups. Let’s examine how the SAS program code that creates the Risk Factor Coding report was divided into three functional groups.

5

A Risk Factor Coding Custom Report Created With ODS Report Writing Interface, continued The first functional group will build a SAS data set containing CCORP data elements for the current and four previous data reporting periods. Every three years there are changes to names and categorical values of several CCORP data elements. This functional group ensures data elements included in the Risk Factor Coding report have the same name and same coding of categorical values for all five data reporting periods.

The second functional group will build a MS Excel worksheet which contains risk factor prevalence rates and missing value rates for each hospital, all five data reporting periods, and both data sources. First, ICD-9-CM codes from the PDD administrative data are used to calculate risk factor prevalence rates for current and four previous data reporting periods. Second, risk factor prevalence rates and missing value rates are calculated for the CCORP clinical data created in the first functional group. Finally the MS Excel spreadsheet is created by summarizing the rates for each hospital. Each row of the worksheet contains information featured in a hospital level Risk Factor Coding report. The summary table provides an important tool to compare hospital rates across data reporting periods and between data sources to identify the “worse hospital offenders” which may require a follow-up phone call.

The third functional group uses ODS Report Writing Interface to create the Risk Factor Coding report. This functional group contains three “primary” macros which will build: a) the table of missing value rates (page 1 of the report); b) the second table of risk factor prevalence rates (page 2 of the report); and c) a graph of prevalence rates for five data reporting periods and two data sources for fourteen risk factors (pages 3-16 of the report). Secondary macros contained inside the primary macros, provide a data management task such as transposing data sets and renaming variables, creating summary statistics, or changing data labels and titles used in the graphs.

Again this approach greatly facilitates locating SAS program code which may have led to an incorrect result. For example, if a PDD risk factor prevalence rate at a specific hospital may be incorrect we begin by verifying hospital’s original data values and the program logic in functional group two that created the rate. This will confirm what rate should be printed in the summary table. If a different rate is printed in the report then we also need to locate the SAS code section in functional group three to be sure the correct rate is printed in the report.

Historically managers reviewed the summary table and discussed which hospitals should be contacted for questionable data. The approach was incomplete because many hospitals with questionable data were not notified. ODS Report Writing Interface has dramatically improved data quality efforts by providing the tools to create a Risk Factor Coding custom report for each hospital. Let’s review the features of both reports.

RESULTS

EXAMPLE RISK FACTOR CODING REPORT

The Risk Factor Coding report contains three sections; a) missing value rates for five data elements for the current data reporting period (Page 1), b) risk factor prevalence rates for 14 data elements for the current data reporting period (Page 2), and c) A graph of risk factor prevalence rates for both data sources at five data reporting periods for each of the 14 risk factors (Pages 3-16).

Let’s examine the historical Risk Factor Coding report. Display 1 shows the missing value rates for three variables for 18 hospitals. The number of cases is given in columns L, O, and R. The hospital rate as number of cases per number of isolated CABG cases is given in columns M, P, and S with the California rate given in row #2 of each column. Columns N, Q, and T provide the ratio of the hospital rate to the California rate color coded as green ( “as expected” for a rate less than 2.5), yellow ( “higher than expected” for a rate between 2.5 and 3.4), and red (“much higher than expected” for a rate 3.5 or larger). Display 2 provides the Resuscitation prevalence rates for five data reporting periods. Every other column starting with column EY provides the number of cases. Every other column starting with column EZ provides the rate per isolated CABG cases. The hospital rate for the current data reporting period in column FH is divided by the California rate (column #2) and color coded as described above.

Let’s examine the new Risk Factor Coding report created with ODS Report Writing Interface. Display 3 shows the first page of the report containing missing value rates for five data elements for the current data reporting period. The ratio of the hospital rate (column 6) and the California rate (column 7) is color coded as before (column 8). Warfarin Use and PA Systolic Pressure Measured had no missing values. Missing rates for Total Bilirubin and Total Albumin are “as expected” but the rate for INR is “much higher than expected.” Display 4 shows the second page of the report containing prevalence rates for fourteen risk factors for the current data reporting period. The ratio of the hospital rate (column 6) and the California rate (column 7) is color coded (column 8). Four risk factors were not reported. Every risk factor should be reported to give credit for patients that are more sick than others. Also rate of missing for Chronic Lung disease is “higher than expected” and Resuscitation is “much higher than expected.” This hospital should review their medical records to verify their data and make changes where appropriate. Display 5 compares the California, CCORP, and PDD rate for the current reporting period (2014 Jan-June) to the previous four reporting periods. There is considerable variation but agreement between the CCORP and PDD rates. Therefore the “higher than expected rate” for Chronic Lung Disease should be reviewed for all five data reporting periods.

6

A Risk Factor Coding Custom Report Created With ODS Report Writing Interface, continued

Display 1. Historical Risk Factor Coding Report showing missing value rates.

7

A Risk Factor Coding Custom Report Created With ODS Report Writing Interface, continued

Display 2. Historical Risk Factor Coding report showing risk factor prevalence.

8

A Risk Factor Coding Custom Report Created With ODS Report Writing Interface, continued

Display 3. New Risk Factor Coding Report Showing First Page of Missing Value Rates.

9

A Risk Factor Coding Custom Report Created With ODS Report Writing Interface, continued

Display 4. New Risk Factor Coding Report Showing Second Page of Risk Factor Prevalence Rates.

10

A Risk Factor Coding Custom Report Created With ODS Report Writing Interface, continued

Display 5. New Risk Factor Coding Report Showing Five Data Reporting Periods for Chronic Lung Disease.

11

Set Yourself Free –Use ODS Report Writing Technology In SAS Enterprise Guide, continued

PROGRAM CODE AND DESCRIPTION FOR RISK FACTOR CODING REPORT

The SAS program that created the Risk Factor Coding report as well as a description of SAS program highlights can be obtained from the author.

CONCLUSION

In today’s sophisticated business environment where the ability to prepare custom designed reports and convey your message in a clear and concise manner is an absolute imperative; and many organizations are transitioning to SAS Enterprise Guide for their data collection, analytics, and data reporting needs; ODS Report Writing technology using SAS Enterprise Guide is an powerful alternative to Dynamic Data Exchange (DDE) using PC SAS.

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 trademarks of their respective companies.

ACKNOWLEDGEMENTS

The author would like to thank Daniel O’Connor at SAS Institute for sharing the paper O’Connor (2009b) and responding to my questions during report testing and development. In addition I could not have completed this project without my mentor Art Carpenter who was kind enough to share a “glimmer” of his great knowledge of SAS macros in his two workshops “Introduction to SAS Macros,” and “Advanced SAS Macros.” Completion of this project would not have been possible without the use of nested SAS macros to “bundle” the ODS Report Writing technology. Also for Art Carpenter sharing a clever “snip-it” of SAS code which creates a list of hospital license numbers and names and executes this report for each hospital.

REFERENCES

Cole, Nancy and Baxter, Cassandra. 2013. “Using the SAS® Output Delivery System Report Writing Interface to Produce Codebooks for Survey Data.” Proceedings of North East SAS Users Group 2013 Conference. Cary, N.C: SAS Institute Inc. Available at http://www.lexjansen.com/nesug/nesug13/112_Final_Paper.pdf

Duan, Rui and Feaster, Daniel. 2012. “Using SAS® ODS Report Writing Interface to Create Clinical Study Reports.” Paper 169-2012. Proceedings of the SAS Global Forum 2012 Conference. Cary, NC: SAS Institute Inc. Available at http://support.sas.com/resources/papers/proceedings12/169-2012.pdf

Kummer, Daniel. 2014. “Toe to Toe: Comparing ODS Layout and the ODS Report Writing Interface.” Paper SAS330-2014. Proceedings of the SAS Global Forum 2014 Conference. Cary, NC: SAS Institute Inc. Available at http://support.sas.com/resources/papers/proceedings14/SAS330-2014.pdf

Lund, Pete. 2013. “Have it Your Way: Creating Reports with the Data Step Report Writing Interface.” Paper 040-2013. Proceedings of the SAS Global Forum 2013 Conference. Cary, NC: SAS Institute Inc. Available at http://support.sas.com/resources/papers/proceedings13/040-2013.pdf

O’Connor, Daniel. 2009. “The Power to Show: Ad Hoc Reporting, Custom Invoices, and Form Letters.” Paper 313-2009. Proceedings of the SAS Global Forum 2009 Conference. Cary, NC: SAS Institute Inc. Available at http://support.sas.com/rnd/base/datastep/dsobject/Power_to_show_paper.pdf

O’Connor, Daniel. 2013. “Take Home the ODS Crown Jewels: Master the New Production Features of ODS LAYOUT and Report Writing Interface Techniques.” Paper 015-2013. Proceedings of the SAS Global Forum 2013 Conference. Cary, NC: SAS Institute Inc. Available at http://support.sas.com/resources/papers/proceedings13/015-2013.pdf.

Springborn, Robert. 2012. “Set Yourself Free –Use ODS Report Writing Technology in SAS® Enterprise Guide Instead of Dynamic Data Exchange in PC SAS®” Paper 035-2012. Proceedings of the Western Users of SAS Software Twentieth Annual Conference. Cary, NC: SAS Institute Inc. Invited Paper Available at at http://www.lexjansen.com/wuss/2012/35.pdf Springborn, Robert. 2013. “Set Yourself Free –Use ODS Report Writing Technology in SAS® Enterprise Guide Instead of Dynamic Data Exchange in PC SAS® Part II SAS® Code Revealed” Paper 016-2013. Proceedings of the SAS Global Forum 2013 Conference. Cary, NC: SAS Institute Inc. Invited Paper Available at http://support.sas.com /resources/papers/proceedings13/016-2013.pdf

12

A Risk Factor Coding Custom Report Created With ODS Report Writing Interface, continued Zhang, Siijian. 2011. “Our Adverse Event Review Reports Generated All in ODS Report Writing Interface.” Paper CC-15. Proceedings of the South East SAS Users Group 2011 Conference. Cary, N.C: SAS Institute Inc. Available at http://analytics.ncsu.edu/sesug/2011/CC15.Zhang.pdf

CONTACT INFORMATION

Your comments and questions are valued and encouraged. Contact the author at:

Robert Richard Springborn, Ph.D. Healthcare Outcomes Center Office of Statewide Health Planning and Development 400 R Street, Suite 250 Sacramento, CA 95811-6213 Office (916) 326- 3874 ROBERT.SPRINGBORN@OSHPD.CA.GOV

13