Trialworks



1. PURPOSE

The purpose of this guideline is to describe the naming, documentation, coding and layout conventions required in the development of SAS programs in Biometry. Also covered is a description of multi-use macros and how to handle missing and/or erroneous data when creating analysis datasets.

2. RESPONSIBILITY

It is the responsibility of the Biometry Manager to oversee the implementation of this guideline. It is the responsibility of the Bioanalysts to follow this guideline during the creation of SAS programs.

3. DEFINITIONS AND TERMINOLOGY

4. REFERENCES AND RELATED SOPs

• SOP 20-0412_00 SAS Program Life Cycle

• SOP 20-0413_00 SAS Data Flow

• SOP 20-0409_00 SAS Program Change Control

5. GUIDELINE

A. Program Naming Conventions

By applying a standard prefix convention to all SAS programs, the function of a program and its associated output is explicitly documented within the program name. Programs and their associated output should maintain a common name whenever feasible. The following conventions should be used:

|Function: |Prefix: |Example: |

|Analysis File |a_ |a_labdata.sas |

| | |a_labdata.sd2 |

|Summary Table |t_ |t_dosing.sas |

| | |t_dosing.rtf |

|Figures/Graphs |f_ |f_vitals.sas |

| | |f_vitals.ps/ f_vitals.pdf |

|Validation Programs/Output |v_ |v_demog.sas |

| | |v_demog.out |

|By-patient Listings |l_ |l_profile.sas |

| | |l_profile.pdf |

|Checking Programs |c_ |c_visitdates.sas |

| | |c_visitdates.pdf |

|Exploratory Programs |x_ |x_ebv.sas |

|(statisticians) | | |

|Clinical Operations Programs |cl_ |cl_demog.sas |

|(under Current) | | |

|Quality Assurance Programs |qa_ |qa_ae.sas |

|(under Current) | | |

|PCDS/PK Programs |pk_ |pk_demogdose.sas |

|(under Current) | | |

|CDA Audit Programs |cda_ |cda_conmed.sas |

|(under Current) | | |

|CDC Edit Programs |cdc_ |cdc_visitdates.sas |

|(under Current) | | |

B. Program Documentation

In-Program Documentation - SAS programs should contain internal comment blocks that serve as in-program documentation in order to:

• show program information (header)

• indicate when records are being deleted or modified.

• document if hard coding of data occurs (This should be infrequent. See SAS Datasets below.)

• indicate major sections of the program

• explain any unusual warnings or error messages anticipated in the logs.

Use the “*** text ; “ format for creating comment blocks. The “/* text */” format is susceptible to problems if there are embedded “/* text */” comments within it.

Program Header - SAS programs are properly identified with a program header. The program header minimally contains the following information:

• Program name

• Synopsis

• Programmer's name

• Date of creation

• Version

• Input datasets or files

• Output datasets or files

• Program history (modification date, modified by, modification)

Versioning Documentation - Updating the history of programs intended for regulatory submittal should be done using the SyValidate tool. The version number should be changed at the same time. If the change is minor, add to the decimal of the version number. If the change is major, then go up to the next whole number.

Titles and Footnotes – The main titles (TITLE1-TITLE3) and the source line footnote are set by the headfootp (portrait output) and headfootl (landscape output) macros in the task level autoexec.sas. TITLE4-TITLE10 are set by the Bioanalyst within the program.

• TITLE1 should be blank or read "Dummy Data" if the program uses dummy treatment groups.

• TITLE2 contains the MXI name and page x of y.

• TITLE3 contains the MXI protocol number.

• Use an appropriate TITLE4 statement to describe data in the output.

• FOOTNOTE2 creates a solid line to separate the output from the source line.

• The source line, FOOTNOTE4, includes the Bioanalyst’s initials, the full directory path and program name, and program run date and time.

C. Coding Conventions

Data Step

• General rule - One data step statement per line.

• Separation - Separate code blocks to improve readability.

• Alignment - Use consistent alignment within code blocks.

• Indentation - Use in "if … then … do …" or do loops. Especially use in nested do loops for ease of debugging

• Equations - Use parentheses to clarify components of an equation.

• Spacing - Use extra spaces to make reading equations and other statements easier.

• Continuation Lines - Break lines at sensible points to maximize readability.

• Labeling – If a variable is created within a program and is kept in a permanent dataset, it should be labeled appropriately.

SAS Procedures

• The PROC statement should be on separate line(s) and the option list should start with DATA= option.

• Each subsequent statement should be listed on a separate line and indented at least one space from the beginning of the line.

• For subsetting datasets, use a WHERE statement in the PROC whenever possible, rather than using a data step.

• Datasets used in a PROC should be defined explicitly instead of implicitly. If you are using a permanent dataset, use the OUT= option if it is available for the PROC.

• Do not use the NOPRINT option if the resulting statistics are part of a final table or listing. Use the NOPRINT option if just doing a PROC to get minor counts for TITLE statements and the like.

D. File Reference Conventions

SAS file and lib references should occur within the autoexec.sas, however if for some reason they reside within a SAS program, the UNC (Universal Naming Convention) should be used for the following reasons:

• It allows for portability of programs and structure to outside sources,

• It removes the issue of different users having different letters assigned to network drives.

Examples:

Instead of the statement:

%include ‘f:\biometry\analysis\autoexec.sas’;

This statement should be written as:

%include ‘\\mxiserver\1Share\BIOM\BIOM-Studies-Analysis\autoexec.sas’;

Relative path references are ok:

%include ‘..\programs\biostat\autoexec.sas’;

E. Multi-Use SAS Macros

Various SAS macros have been developed within or for the Biometry Department for use in analysis and for report generation. There are also macros that aid in the running and debugging of programs. Multi-use macros should be used whenever possible to provide consistency within and across studies. Documentation for these macros can be found in \\MXISERVER\1Share\BIOM\BIOM-Studies-Analysis\Globals\Macros\Usage.

Currently available macros are listed in the following table.

|Macro Name |Type |Description |

|Age |Analysis |Create age from birthdate |

|Impdt |Analysis |Impute a date value from a character string, applying assumptions when |

| | |the date is partial. |

|headfootl |Output |Creates titles and footnotes for landscape page setup |

|headfootp |Output |Creates titles and footnotes for portrait page setup |

|logeval |utility |Evaluates log files of programs for "cautionary" messages |

|pagenum |reporting |Converts XXX of YYY found within report files into proper page numbers |

|ps2pdf |output |Converts postscript files into PDF files |

|runorder |utility |Set up a sequence of SAS programs to run in a specified order. The |

| | |runorder macros are designed to facilitate situations in which a |

| | |program's execution is dependent on the output or datasets created by |

| | |earlier programs. To ensure that program dependencies are met, if a |

| | |program in the sequence has a SAS error, the runorder sequence will |

| | |terminate. |

|time_is |utility |Accesses the system time during the execution of a SAS program |

|Toc |utility |Creates a table of contents from an output directory |

|Topdf |output |Produces PDF output from SAS output |

|txt2html |output |Converts a text file into a HTML File |

|txt2rft |output |Converts a text file into a RFT File |

F. Log Evaluation and %logeval Utility

Log evaluation is an important part of the program development process. Many potential problems show up when an assessment is made of a program's log file. The logeval macro is an important tool that can be used to quickly search a log for errors and warnings. It searches an extensive list of key words, more than would typically be reviewed in a manual search. Reliance should never rest solely on the logeval macro however. It should be one tool used in conjunction with a thorough review of the log by the programmer. It is especially important to review the complete program log prior to the final program run.

When the logeval macro evaluates a SAS log file, it displays a line for each cautionary message found within the log, such as Warning or Error. It is particularly useful in finding unexpected or little known messages. The lines displayed in the logeval macro can be saved as a separate text file.

Whenever a program is submitted using the runorder macro, the logeval macro is the final part of the process. It is also possible to submit a program and run the logeval in one step using the SyValidate tools on the SAS server. (Note: It is not possible to use %logeval within a SAS program to evaluate that program's log since the log file is not closed until the entire program finishes.)

In Program Checking

The Bioanalyst is responsible for creating and using code to check the output of their program such as the use of proc frequencies and means to verify data counts and listings to check the characteristics of variables.

G. SAS Analysis File Programs

These following sections will deal with final SAS analysis datasets and how to program missing or limited patient information for analysis.

The Biometry standard is that derivations and imputations are all stored within the permanent analysis datasets. Analysis file programs embody all decisions that

are applied to the data for inclusion in the permanent analysis datasets, such as imputation of missing values (e.g., dates), collapsing or averaging of observations, applying rules such as last observation carried forward, or deriving new computed variables. Permanent analysis datasets also contain the relevant source data variables. There is generally only one analysis dataset created per analysis file program.

For example, the program a_ae.sas creates the SAS analysis dataset a_ae.sas7bdat. That file contains all adverse event related date imputations, the derived duration of the adverse event, the number of days from the start of treatment to the start of the adverse event, and all relevant source variables collected on the Case Report Forms.

H. Hard coding Within Programs

Hard coding to make data changes should typically be avoided. It should not appear in SAS programs unless it is determined that the data point will not be changed at the clinical site and the only manner of correcting the value is through the SAS program. The code block containing the hard coded changes should be prominently commented.

I. Handling Missing Dates

To handle missing dates use the impdt macro. There are 2 assumptions built in to the macro, 1) if the date is partial we may want to bias the date to either the earliest possible or last possible date given the partial date information or to the midpoint, and 2) that if a reference date is specified (a dose date for example), if the partial date could possibly include the reference date then set the imputed date to the reference date.

Macro %impdt – impute a date value from a character string, applying assumptions when the date is partial.

%impdt(chardt,

impdt,

infmt=date9.,

bias=mid,

missing=%str(_),

refdt=.);

parameters:

|parameter |Required? |Desc |

|chardt |Y |Character date to be imputed |

|Impdt |Y |Imputed date (SAS date) |

|Infmt |N |SAS informat |

|bias |N |Bias the imputed date. Valid choices are: mid (default) (15th for missing |

| | |day only, 01Jul for missing month and day); first – first day or 01Jan, last|

| | |– last day, 31Dec. |

|Missing |N |Character denoting a missing value, defaults to ‘_‘; a completely missing |

| | |date would look like ‘_________‘ given a date9. informat.. |

|refdt |N |A reference date (SAS date), purpose is to apply a conservative assumption |

| | |when imputing dates. Overrides the bias parameter assumptions when the |

| | |partial date could be the same as the specified reference day. If day is |

| | |missing and month and |

| | |year are the same as the reference date, or if day and month is missing and |

| | |year is the same as the reference year then set impdt to reference date. |

Note: the macro is meant to be called in the context of a data step, assigning the result to a date variable as in:

%impdt(aestrtc, aestrtdt, bias=ref, refdt=dosedt);

This statement would create a new SAS date var aestrtdt from the character date variable aestrtc using dosedt as a reference date.

J. Program Versioning:

• Sy/Validate is used to capture the significant development versions and the production versions of SAS programs. Upon completion of a development cycle (when the program output is ready for review by the requestor, or when the program is ready for validation / verification) a version of the code should be captured with Sy/Validate.

• To capture a version the user must be logged into the SAS server through terminal services:

o Open a Windows Explorer window on the directory where the program is saved

o Right click on the file and choose either ‘V- Version’, ‘V-Submit SAS 8.2 + Version’, ‘V-Version + Notes’ or ‘V-Version + Notes + Submit’. Any of these choices will save a version of the program.

• If the program is ready for validation / verification use the Sy/Validate tool to lock the program for validation / verification:

o Open a Windows Explorer window on the directory where the program is saved

o Right Click on the SAS program and choose ‘V-Lock for Validation’

o Note that the program’s file extension will change ‘.sas7bbak’ when the program is locked.

• When the program has completed validation / verification use the Sy/Validate tool to assign a production version if the program passed validation or unlock the program if the program did not pass:

o Open a Windows Explorer window on the directory where the program is saved. Note that the program will have the file extension ‘.sas7bbak’

o If the program passed validation right clink on the SAS program and choose ‘V-Production + Unlock’

o If the program did not pass validation / verification choose ‘V-Unlock’ to un lock the program for further development.

K. Final Program Submittal

• Use PC SAS for development and use the SAS server to run the final version of a program for validated output.

• If applicable, run interim analysis programs before running the final production SAS programs.

• If the study is blinded and requires unblinding, apply the blinding and unblinding according to the "Blind / Unblinding" WPGs.

• If applicable, verify that all input data are locked and that all deviations have been resolved.

• Verify that the program has gone through Verification according to the SOP 20-0410_00 SAS Program Risk Assessment Validation and Verification.

• Ensure that the program is the final production version by doing the following in the context of being logged into the SAS server MXISERVER:

1. Locate the SAS program in Windows Explorer.

2. Right mouse click on it and select the menu "V - Reconcile".

3. Roll back to the production version if the current program is not the same as the production version.

• Submit the program on the production server in batch mode by doing the following:

1. Log onto the MXISERVER server using terminal services.

2. Locate the program through Windows Explorer.

3. Select "Batch Submit" from the menu choices.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download