Return to Homepage

Goto the Tip of the Month Archive

Other interesting pages ...
LinkedIn Profile
SAS Cheat Sheet
Useful SAS Code
Full SAS Example
Basic Statistics
Contact Information

SAS Tip of the Month
December 2014
(for SAS)

Every so often it is important to remember regarding general programming standards and expectations in clinical trail programming.

First topic:

ALWAYS review the Protocol, SAP including table shells, eCRF (if present), ADS and APS, and any other source documentation for background information or specifications

It is not good programming practice just to work off any ADS or APS specifications alone as these may be incorrect – the controlling document for any programming is the SAP. This is usually in an SOP.

Second topic:

ALWAYS do your work on the network drive in the relevant project area

This includes both development and production phases of the programming. The two main reasons for this is that the:

  • Network drives are usually backed up
  • Backup programmers can take over should you be out of the office for some reason, including illness, or on another more important project

The project area is backed up every night so that if your laptop suddenly fails the work is not lost, or if you are not at work for a day due to illness and something needs to get out then someone can take over and complete it. On a personal note, I did work in a company many years ago where one of the programmers was doing some work on their own laptop, against policy, and while they were walking through a door and the door closed on them knocking the bag causing the heads of the hard disk to be put out of alignment resulting in critical work being lost.

While at this time it is strongly advised that all programming work be on the network drive in the relevant project area, it will shortly become department operating policy. It is not enough to store your programs in your private network area as other programmers cannot get to the programming.

If you are concerned that a program in development will be run by another programmer as production then one suggestion is to surround the whole code as a macro that does not resolve, e.g.

   %macro skip;
      SAS Code;
   %mend skip;

Third topic:

ALWAYS run your SAS program in Batch Mode

When you run a program in batch mode several things happen including the creation of a SAS LOG of the program, which shows who ran the program, when and what happened and makes certain that there are no extraneous settings that can exist when running in interactive mode. From a QC/QA standpoint the SAS LOG is more important than the SAS Program as it says what it did and it should be possible to recreate the SAS program from the SAS LOG.

The SAS LOG must be checked for ERRORS and WARNINGS at a minimum but also other text could and should be searched for, e.g. unitialized variables. Also check the output – occasionally there will be issues not detected in the SAS LOG where the output either has a dataset with zero observations or a table with blank pages.

Hope this is useful. See you next month.

________________________________
Updated December 2, 2014