SAS Tip of the Month
Every so often it is important to remember regarding general programming standards and expectations in clinical trail programming.
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.
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:
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;
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