Our first SDE in Seattle was a big success. Thanks to everyone who presented and participated. Don't forget that all paid registrants will receive a $75 discount for our annual conference in Denver next May!
|Title (click for abstract)||Presenter(s)||Paper / Slides|
|Infrastructure Designed to Maximize Workflow||Paul Hamilton, Omeros Corporation||Paper (PDF, 83K)|
|Best Practices: Subset Without Getting Upset||Mary Rosenbloom, Alcon||Paper (PDF, 190K)|
|Something Old, Something New... Flexible Reporting with DATA Step-based Tools||Pete Lund, Looking Glass Analytics||Paper (PDF, 706K)|
|Using R in the SAS System||Alan Mitchell, Cancer Research and Biostatistics||Paper (PDF, 717K)|
|Compare and Conquer Key SDTM and ADaM Variables||Sunil Gupta, Cytel||Summary (PDF, 384K)|
|Efficient Cut-point Estimation and Validation using PROC PHREG||Alan Mitchell, Cancer Research and Biostatistics||Paper (PDF, 554K)|
|Utilizing SAS® for Cross-Report Verification in a Clinical Trials Setting||Marla Husnik, Fred Hutchinson Cancer Research Center||Paper (PDF, 443K)
Slides (PDF, 1.41M)
|Handling Interim and Immature Data In a Clinical Trials Setting||Paul Stutzman, Axio Research||Slides (PDF, 716K)|
All clinical statistical programmers work within a common set of constraints: we must be prepared to support the production of Clinical Study Reports after a trial is complete; we must be prepared to support filings to various regulatory agencies; we must operate under the aegis of CFR 21 Part 11; we must contend with frequent changes in specifications and contracting timelines; and most of use SAS™ software in our work. This paper presents an architecture purporting to maximize programmer workflow, minimize manual steps, and optimize programmer efficiency. Guiding principles include: single source of metadata, stored locally; all processes driven by metadata and automated through software; hands-off production of finished publishable products; and minimizing human-only tasks wherever possible.
You’ve worked for weeks or even months to produce an analysis suite for a project, and at the last moment, someone wants a subgroup analysis and they inform you that they need it yesterday. This should be easy to do, right? So often, the programs that we write fall apart when we use them on subsets of the original data. This paper takes a look at some of the best practice techniques that can be built into a program at the beginning, so that users can subset on the fly without losing categories or creating errors in statistical tests. We review techniques for creating tables and corresponding titles with by-group processing so that minimal code needs to be modified when more groups are created, and we provide a link to sample code and sample data that can be used to get started with this process.
The report looks simple enough — a bar chart and a table, like something created with GCHART and REPORT procedures. But, there are some twists to the reporting requirements that make those procedures not quite flexible enough. It's often the case that the programming tools and techniques we envision using for a project, or are most comfortable with, aren't necessarily the best to use.
Fortunately, SAS can provide many ways to get results. Rather than procedure-based output, the solution here was to mix "old" and "new" DATA step-based techniques to solve the problem. Annotate datasets are used to create the bar chart and the Report Writing Interface (RWI) to create the table. Without a whole lot of additional code, an extreme amount of flexibility is gained.
If you use both SAS and R, then you've probably run into a situation where your data are saved as SAS® data sets but the analysis tools you want to use are only available in R. Fortunately, a feature of SAS/IML allows users to exchange SAS data with R and execute R statements using SUBMIT/ENDSBMIT statements and CALL routines. SAS users can create R data frames from SAS data sets and have access to R’s graphics tools along with a large collection of add-on packages. An interactive R programming environment can be initiated from within SAS that is useful for writing and debugging R scripts. In addition to the basic mechanics of the interaction between PROC IML and R, a discussion of some of the pitfalls and a demonstration of some of the tools available will be presented. SAS/IML 9.22 or later is required. However, to use more recent versions of R, newer versions of SAS/IML are required.
We know that SDTMs are standardized version of case report form raw data and ADaMs are analysis datasets which are one proc away from tables, but how exactly do SDTM and ADaM variables compare? There must be key and common variables that make the migration from SDTM to ADaM straight forward.
This presentation explores when key variables are created and how these variables are related between SDTMs and ADaMs. For many variables, there are categories that define variable naming convention and control terms. Finally, the general structure of SDTMs and ADaMs will be compared.
In clinical research, it is important to present results that are easily interpreted by a broad audience. Using dichotomized rather than continuous risk factors in regression models is one way to simplify the interpretation when covariates are not linearly related with the outcome or are ordinal but not quantitative. Methods for covariate dichotomization have been described for censored survival data, but many require multiple passes through the data to assess each potential cut-point. However, an approximation of the log-rank statistic based on cumulative sums of martingale residuals allows consideration of all possible splits in an efficient way. This method can easily be extended to perform an approximate permutation test that provides the analyst with a low-cost internal validation tool. SAS code and simulation studies are presented to demonstrate the utility of the method.
Large scale efficacy clinical trials require frequent and diligent monitoring of study data that includes the generation of Data Safety Monitoring Board (DSMB) reports. The importance of data accuracy, frequency of generation, and sheer length of DSMB reports combine to make their verification crucial and time-consuming. In an effort to improve the accuracy and efficiency of DSMB report production we developed procedures utilizing SAS® to automate a number of verification checks. This paper presents the framework and the SAS® tools we developed for verifying DSMB reports for a phase III efficacy trial that are generalizable to other research reports. The tools we developed to support DSMB report production include the following: SAS® programs that create standardized results datasets for the generation of tables, listings, and figures (TLFs); driver files that determine the verification checks to be performed; SAS® programs that perform verification checks on results datasets; and HTML-formatted output that clearly show whether and where errors occurred. We present specific examples of our tools using mock data from a phase III clinical trial that utilize SAS® facilities such as the Macro language and Output Delivery System (ODS).
In a clinical trials setting, programmers and statisticians are frequently presented with immature and incomplete data. This is often the case when preparing reports for Data Monitoring Committees (DMCs), performing interim analyses, or developing standards-compliant dataset programs. Thus, it is important to understand the constraints and potential pitfalls of working with preliminary data, to write programs that handle both anticipated and unanticipated values, and to develop techniques for understanding how data change over time. This presentation will discuss these topics.