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
February 2016

No names, we have all done it/seen it. An example of a specification:

   If not missing(cmstyy) & missing(cmstmm) & missing(cmstdd)
   & year consdt does not equal cmst_yyyy then set cenddt=last
   day of that year (which will be 31DEC).

And another example:

   GHR= (GHR_1 + GHR_2 + GHR_3 + SFR_33 + SFR_35 - 5) *5

When writing ADS specifications a good rule of thumb is to write it as if you were across the table from an FDA reviewer – these people on the whole do not know SAS or R or any of the other myriad of statistical software, do not know the structure of the datasets, and don’t have much time. The specifications also have to be written in a way that is not programming language specific, i.e. either a SAS or R or STATA or SPSS or, dare I say it, VB – a programmer, and not necessarily a SAS programmer, must be able to pick up the specification and get the same result.

There are some exceptions to this, namely when an obscure statistic is being requested and it needs a particular SAS procedure call with specific parameters. The other issue when writing language specific specifications is that it places huge onus on the one specifying to get it right, and yes, it CAN take days to rewrite code if the specification is found to need amendment.

In the first example, the specification is meaningless to a reviewer who has little time and/or knows little of a programming language. To a programmer, trying to work out what the intent is difficult at best and many will just take that specification and write code to it. In this snippet, Its intent was:

   If the conmed end date is a year value only, and the
   year value is not the same year as consent date, then
   set a computed end date of the end of the conmed year.

Within most programming groups it is expected that an intermediate level programmer and higher to get this intent and program it, and if they do not understand it they should ask another programmer for help - experienced programmers enjoy passing on their knowledge and experience when asked (maybe we are busy at that moment you ask, but give a little bit of time and we always come back and at least follow-up). Sometimes even a help from an internet search will assist.

As a side note, this specification was part of a larger set of specifications on working incomplete concomitant medication end dates -- what would have been ideal would be a general instruction in the programming specifications saying something like:

   Concomitant Mediation (CM) End Dates

   If a CM date is incomplete, the following rule will be set for a
   computed end date:

      o If the month and year is present then set computed date to
        the last day for the month
      o If only the year is present then set a computed date to the
        last date for the year.

Looking at the second example, a question could be raised when the specs are being reviewed over what happens with missing data points in a record - a look at an external reference found that the equation in the document catered for missing values, i.e. one or more of the five variables in the formula had a missing value, and additionally catered for the situation where there were less than half the scores present. Within most groups it is expected that a programmer to go to an external reference document (SAP, eCRF, protocol exempted) unless the specification directed so. As it happened this issue was detected and corrected early, but the worst case scenario could be that it be picked up by the client or outside reviewer.

What is some good guidance?

Specification writers, read the SAP and become familiar with it, and read the protocol if available. Write your specification as if you were talking to an outside reviewers making sure you specify the intent of the derivation - you can always point to an external document for that derivation if needed. Trust your programmers to take that specification and turn it into what you intended.

Programmers, before writing code, read the SAP and become familiar with it, and also read the protocol if available. If a specification is not clear ask another programmer for help - again, experienced programmers enjoy passing on their knowledge and experience. If it is still unclear, then take it back to the specification writer because if you don’t understand it, expect an outside reviewer not to understand it either.

Whether we are a specifications writer, programmer or statistical reviewer, the ultimate goal is to produce output that is clear, accurate and timely.

Hope this is useful.

Updated February 2, 2016