Programming Tips and Examples for Your Toolkit, III John Morrill, Pharmion Corporation, Overland Park, KS

Transcription

1 Paper TT15 Programming Tips and Examples for Your Toolkit, III John Morrill, Pharmion Corporation, Overland Park, KS ABSTRACT This paper is a continuation of a series of PharmaSUG papers containing several ideas, each generally unrelated to the others. The series has been aimed toward the intermediate level pharmaceutical programmer. Brief ideas presented in this paper include (1) a method of validating tables using data sets prior to reporting (DSPTRs), (2) a use of PROC COMPARE that should be obvious but is perhaps underused, (3) dealing with incomplete information using expiring code, and (4) dealing with numbers displayed as negative zero. Two major areas covered in this paper are SAS tools designed to collect and present information about (5) the contents of SAS programs within a study and (6) the data within a study. Also covered is (7) a brief update on a consistency check paper from 2006 PharmaSUG. This update deals with American & British English spelling. Finally, (8) a fun little word-find routine is presented. 1. VALIDATION USING THE DATA SET PRIOR TO REPORT (DSPTR) The practice of creating derived variables in analysis files and reporting on them in table programs is widely used in the pharmaceutical industry. The derived variables in the analysis files are easily validated using PROC COMPARE. Table and listing output, though, is never a SAS data set that can utilize the many useful features of PROC COMPARE. However, PROC COMPARE can be effectively used even with table and listing output. Consider a table program that reads an analysis file, manipulates the data with various data steps and procedures, and produces a table using PROC REPORT. Consider further the data set that PROC REPORT reads to generate its output we will call this the Data Set Prior To Report (DSPTR). Consider that this DSPTR, a SAS data set, can be saved in a directory as an output just as the table itself is. Once the result of the PROC REPORT, the table output, is validated, the associated DSPTR becomes a validated record of the values in this table output and can be used as a standard against future runs of the table program. A PROC COMPARE between the new DSPTR and the validated DSPTR will quickly expose differences. Unexpected differences can be addressed while the absence of differences, or the presence of only explainable differences, can serve as a method of validation of the new output. Using DSPTRs can serve as an electronic replacement for what has often been a visual process. It can reduce the turnaround time on validation of outputs and can increase the accuracy of part of the validation process. Compared to electronically comparing old and new table output versions, using DSPTRs along with a quick visual scan is particularly effective when changing the number of titles or footnotes. Using DSPTRs does not replace the need to visually review the actual table output for formatting, page-breaking, titles, footnotes, and other issues. DSPTRs have been used effectively to check consistency of sample sizes across tables. 2. USING PROC COMPARE WITHIN THE ANALYSIS FILE At the risk of stating the obvious, PROC COMPARE can be effectively used in the creation and especially the update of analysis files. Your author states this because using PROC COMPARE in this way does not seem to be a common practice, but also because your author long failed to recognize its worth. While nothing replaces logically thinking through a piece of code (alas, with faulty logic even this fails), a beforechange versus after-change comparison of analysis file output can quickly point out faulty assumptions in logic. Using PROC COMPARE is a quick way to detect unexpected results. Detecting such errors is key to producing quality work, and detecting errors through PROC COMPARE is a way to reduce production time. In practice, I place a PROC COMPARE (or a macro call to it) at the end of a program and execute the compare at will. 3. DEALING WITH INCOMPLETE INFORMATION WITH EXPIRING CODE There are times when a certain assumption is needed in order to proceed with a SAS program. For example, let s say that a draft of the program is needed immediately but the precise definition of a variable is in question and may not be resolved for a month. Simply programming a presumed definition is dangerous since there is no guarantee that the issue will be revisited. So, programming a temporary definition and finding a way to guarantee review is what is needed. As long as the program will be run again after a month, the code below is one example of a way to ensure this review. Many variations exist; this one requires the user to update the date each day the program is executed. Without explicitly updating this section each day, the program will abort each time it is executed. Once the temporary definition is adjusted to the permanent one, this code may be inactivated (either by commenting out or by deleting).

2 * To be placed at the start of the program. *; %let code_date=19jan07; * ERROR WARNING: LOOK AT XYZ definition EXPIRING CODE *; %macro remember_to_update; %if (&sysdate NE &code_date) %then endsas;; %mend remember_to_update; %remember_to_update; 4. A SOLUTION FOR NEGATIVE ZEROS At times a very small negative number is displayed as negative zero. For example, displayed to one decimal place may appear as -0.0 instead of 0.0. A quick way to overcome this is shown below in the form of a macro placed in the offending data set. The extra macro variable d_frmt is shown to represent the flexibility of setting a general format for an entire suite of programs. %let d_frmt=6.1; %macro correct_neg_zero(ivn=,d_f=&d_frmt); &ivn=round(&ivn,1/10**(substr("&d_f",3))); %mend correct_neg_zero; data between; format q1 q2 6.3; input q1; q2=q1; q3=q1; %correct_neg_zero(ivn=q3,d_f=&d_frmt); cards; ; proc print; format q2 q3 6.1; ========= Obs q1 q2 q Note that a more general form of this macro would be required to handle all variations of the format. For example, specifying the format as 6. or 16.1 would cause a problem with this version of the macro. An index function could be used instead to find the format s decimal place. 5. A BIRD S EYE VIEW OF A SUITE OF SAS PROGRAMS What kinds of things would be valuable to know about the SAS programs in a given project? In this section we search SAS programs and output directories in order to collect and present information about the SAS programs within a study. Except where noted, the observations on the tables shown below are completely dynamic, meaning that no pre-set or expected observations are fixed but records appear only when such data exists. Code and limitations are given in sections 5.4 & 5.5, respectively.

3 5.1 SOURCES OF DATA Searching the SAS table programs themselves for permanent directories referenced would reveal a table like the one shown below. We might expect a folder or directory containing table programs to reference only derived data sets, as this table shows. At times early in a project before derived data sets are available, some table programs may need to point to the raw directory. If it is the goal for all final table programs to reference only derived data, the table below can be used to demonstrate this. Table SOURCE DIRECTORY name raw external derived ae.sas cm.sas mh.sas SOURCES OF DATA MORE DETAIL Again searching the SAS table programs themselves but this time for derived or analysis data set names produces a table like the one shown below. One use of this table would be to show which tables must be re-run if a given derived data set is altered. A similar table with derived data sets in the first column could be generated showing dependencies between derived data sets. Table DERIVED DATA SET name COREVAR AE EFF_ALL MH ae.sas cm.sas mh.sas DESTINATIONS AND TIMING OF OUTPUTS Searching program and output directories produces a table like the one shown below. This can be used to determine whether the appropriate outputs are being created and whether the appropriate time sequence exists. Flags can be generated to alert cases where the save date of the program is more recent than any of its outputs. A realistic version of this table would be a case where not all observations in the table are necessarily created dynamically in many projects a single program would create multiple outputs. Date/time stamps could be captured for more accuracy. Program DATE of FILE name Sas Log Lst RTF DSPTR AE.SAS 18Dec Dec Dec Dec Dec2006 CM.SAS 18Dec Dec Dec2006 MH.SAS 18Dec Dec Dec Dec2006 The absence of Lst and RTF output for the CM.SAS program is certainly cause for concern. The absence of RTF output for MH.SAS is also cause for concern, but the presence of MH.LST indicates that the MH program succeeded further than did the CM.SAS program. As AE.SAS and AE.LOG have more recent dates than the AE output, this is certainly cause for concern. Another example of searching directories, one for which code is shown in section 5.4, is shown below. In this case we are dynamically searching raw data directories for existence and date/time information. The first column is the raw data file name. The remaining columns contain the date/time stamps of these raw data files as they exist in various folders. The folder names incorporating the date of a given folder serve as the column headers. A missing date/time stamp means that the indicated file (row) does not exist in the indicated folder (column). This can be useful in tracing the timing of file updates.

4 MEMNAME CRDATE_R_ CRDATE_R_ CRDATE_R_ AE 10APR06:02:15:58 25SEP06:10:29:42 02OCT06:08:46:58 DATES 01FEB05:00:12:31 01FEB05:00:12:31. DEATH 10APR06:02:16:44 25SEP06:10:32:33 02OCT06:08:51:19 PREG 10APR06:02:17:28 25SEP06:10:35:24 02OCT06:08:55:20 PUNB. 25SEP06:10:35:25 02OCT06:08:55:21 RADIAT 10APR06:02:16:37 25SEP06:10:32:20 02OCT06:08:51:01 RAND003 31OCT05:13:25:57.. RESP 10APR06:02:17:28 25SEP06:10:35:25 02OCT06:08:55:22 RESP2 08DEC05:14:46:46. 02OCT06:08:55:36 SKELETAL 10APR06:02:17:28 25SEP06:10:35:26 02OCT06:08:55:23 In addition to checking dates between transfers of raw data, it is often useful to check other characteristics such as type, length, format, and label. Detecting changes to such characteristics immediately upon receipt of a transfer of new data can eliminate or reduce problems arising out of such changes. Note that we are not considering the contents of the data sets, just the meta-data. The data sets could contain complete garbage and we would not detect this using the methods described in this section. 5.4 CODE HIGHLIGHTS This first batch of code demonstrates a way to dynamically detect all SAS programs in a directory and then iterate through these programs, detecting the presence of a string in each file. This is for sections 5.1 and 5.2 above; formatting the output as shown in these sections is left for the reader. The code has not been made platform independent. * Code for parts 5.1 and 5.2 above. *; * Book is created dynamically below. *; filename book " U:\Conferences\qwe4.txt"; * This creates a file in the current directory consisting of file *; * names meeting the given criteria - in this case *.sas files. *; options noxsync noxwait; data _null_; call system("dir U:\MM003\tables\*.sas /b > qwe4.txt"); * cancel; * The file containing program names is read. Names and parsed *; * meaning that T_AE_Age.sas is turned to T_AE_Age. *; data any(keep=fn_new); infile book missover length=reclen; length fn $100.; input fn $varying100. reclen; fn_new=reverse(substr(reverse(upcase(compress(fn))),5)); * Macro variable is created containing file names strung together. *; proc sql noprint; select distinct fn_new into :fn_new separated by ' ' from any ; quit; * This is an empty initial file. Other files below are combined with this file. *; data combine; * This loops through all program names, reading the program itself and saving *; * lines from the program that contain the given string - in this case DERIVED.*; %macro loop; %let i=1;*49; %let ids=%scan(&fn_new,&i,%str( ));

5 %do %while (%length(&ids) gt 0); filename book2 "U:\MM003\tables\&ids..sas"; data &ids(keep=line source); infile book2 missover lrecl=2500 length=reclen obs=55400; length line $2500 source $100; input line $varying2500. reclen; if index(upcase(line),"derived.") GT 0; source="&ids"; data combine(where=(source NE '')); set combine &ids; %let i=%eval(&i+1); %let ids=%scan(&fn_new,&i,%str( )); %mend loop; %loop; * This shows all files (first column) containing the string DERIVED (second column). *; proc print width=min data=combine; var line; format line $80.; by source; id source; This next batch of code was used to generate the second example in section 5.3. Similar code could be used for the first example in 5.3. Using certain assumptions, the code below could be made dynamic rather than having to specify which directories are considered. * Code for part 5.3 above. *; libname r_ 'G:\BDM\project1\Data\Raw\2006_04_10'; libname r_ 'G:\BDM\project1\Data\Raw\2006_09_25'; libname r_ 'G:\BDM\project1\Data\Raw\2006_10_02'; title1 %SUBSTR(&SYSPROCESSNAME,9) " &sysdate9 &systime"; %macro ec9; %macro loop(ids=); proc contents data=&ids.._all_ out=c_&ids(keep=memname crdate rename=(crdate=crdate_&ids)) noprint; proc sort data=c_&ids nodupkey; by memname crdate_&ids; %mend loop; %loop(ids=r_060410); %loop(ids=r_060925); %loop(ids=r_061002); data all; merge c_r_ c_r_ c_r_061002; by memname; proc print width=min noobs; title2 "History of raw datasets"; title3 ' '; %mend ec9; ** NOTE - need to modify EC9 after each transfer. **; %ec9; *history of raw datasets*;

6 5.5 LIMITATIONS Depending on how various programmers write code, a naïve search of programs for sections 5.1 and 5.2 would yield incomplete information. For example, assume a program contains a call to external code. If this external code is where the requested string exists, associating the desired string with the correct program will be difficult. Additionally, this method does not take into account file references that are parsed together within a macro. Finally, this method does not distinguish between active code and text appearing within a SAS comment. There are ways to overcome these limitations. One method would be to utilize MPRINT output in the log file to detect exactly what files and directories are being referenced. 6. A BIRD S EYE VIEW OF A PROJECT S DATA A number of useful things can be learned by viewing some high level project information. The following sections can be easily generated with limited knowledge of a study s data sets and yet yield some potentially important results. The table found in section 6.1 presents transposed PROC CONTENTS output. The tables found in sections 6.2 and 6.3 use the SAS dictionary tables as the source of files. For continuity, the same data sets are used in sections 6.1 through 6.3. Code used to generate these tables is found in section DISTRIBUTION OF VARIABLE NAME AMONG ALL DATA SETS The following table shows raw data sets across the top and variable names down the side with a one indicating presence of that variable (row) in a given data set (column). Edit check=p01 Variables down, data sets across the top. Obs NAME DM AE CM LB MH NR VS 1 DOB DOMAIN ENDDT HIGH LOW PANEL PT RACE RELATED RESULT SERIOUS SEX STARTDT STUDY TEST VERBATIM VISIT pt vis_num We see that 19 unique variable names are found among seven data sets. Two variables, DOMAIN & STUDY, are common to every data set. PT (patient or subject number) is not in all data sets. This makes sense for NR (normal range) since lab normal ranges are independent of subject number. However, we notice that PT is not found in LB (laboratory results). Upon further inspection, a lower case version of PT is found. (This really happened in a study; it was quite helpful to recognize this fact early. Use of the option validvarname=upcase can be valuable for this type of issue.) It makes sense that VISIT is not found in DM (demographics) and NR as both are or can be independent of VISIT. Again we notice an aberration in LB as its visit variable is named vis_num. DM is one of several data sets which contain variables found nowhere else: DOB, RACE, & SEX. Similarity among data sets is reasonable easy to detect. For example, AE (adverse events) and CM (concomitant medications) share many of the same variables. This is useful in coming to an understanding of the keys or common merge variables of a set of data sets.

7 Note that values are not represented here, only the existence of variables in various data sets. So, we don t know that PT contains reasonable subject numbers (see section 6.3 for this) or that all records in these data sets belong to the same study. As a practical matter, the data sets across the top could be sorted alphabetically for ease of use. As with examples below, the ones/missing in the body of this table could be altered to show number of populated/missing records. Or perhaps other information such as the type and length of variables (e.g., N8 or C3) could be shown. 6.2 DISTRIBUTION OF VISIT NUMBER AMONG ALL DATA SETS The following tables show raw data sets across the top and visit number down the side with number of records within the table. Since we learned in section 6.1 that the LB data set uses a different variable for VISIT, distributions of both VISIT and VIS_NUM are shown. Edit check=p02_visit Distribution of VISIT among all data sets. VISIT AE CM MH VS Edit check=p02_vis_num Distribution of VIS_NUM among all data sets. vis_num LB We note that four non-missing values of VISIT are populated: 1, 2, 3, & 60. Perhaps 1, 2, and 3 are the first three visits in the study and 60 is a generic page used across VISITS. Seven data sets are in this study. We note that DM and NR are not represented in these tables since they do not contain any visit information. LB s visit information is not contained in the VISIT variable so its distribution is shown separately. Why does AE have some records at VISIT 60 but one record with the value of VISIT missing? Regarding CM: why is VISIT not populated for one record and is it an issue that CM does not contain any records at VISIT 60? Is it an issue that MH (medical history) has most of its records occurring at VISIT 1 (perhaps the screening visit is when MH information was recorded) but then has one record occurring at VISIT 60? Note that for a real study with many more data sets and a full complement of visits, it is at times quite useful to subset the data down to an individual subject to see the resulting distribution. This can quickly illustrate where that subject is missing data. A subsetting macro parameter could be added to facilitate this feature. Also for a full complement of data, one will notice that earlier visits are populated more heavily than later visits due to subjects incomplete progress through the study or subjects dropping out. A deviation from this pattern may be cause for concern. As in the case with VISIT 60, real studies use various numbers for purposes other than actual visits. For example, follow-up visits may be numbered in the 800s and unscheduled visits may be in the 900s. Once you are familiar with a study, data sets having records outside of expected places could trigger a review. The subject counts could be converted to a one tally per subject basis. This has been used, for example, to detect where a number of subjects were improperly missing lab results due to a lab loading issue or the lab mis-numbering visits. Note that with some minor modifications, all data sets could be shown even if they do not contain values. The option could be added to dynamically variables to summarize in P02 based on meeting certain criteria in P01. This would replace the parameter specification in the macro call of P02.

8 6.3 DISTRIBUTION OF SUBJECT NUMBER AMONG ALL DATA SETS The following table shows raw data sets across the top and subject or patient (PT) number down the side with number of records within the table. Note that the NR data set is not presented since it contains no patient information. Edit check=p02_pt Distribution of PT among all data sets. PT CM AE DM LB MH VS We note that CM contains two records with no patient information certainly not what one would expect. The code used to produce this table (see section 6.4) did not distinguish between upper and lower case versions of the PT variable. Care should be taken to ensure this is done. Again, use of the option validvarname=upcase can be valuable for this type of issue. LB does not have data for a number of PTs. One wonders if perhaps 17 is an invalid patient number. Since it appears only in LB, one possibility is that PT 17 should really be PT 7. We note that PTs 1, 7, & 17 do not contain CM information. Perhaps these subjects dropped out of the study prior to having CM recorded or perhaps they truly have no CM information. We note that PT 1 is missing both CM and VS (vital sign) information. Other subjects also fail to have observations in various data sets. Summarizing what we have seen above, information can be learned about individual data sets by looking down the columns and information can be learned about individual subjects by looking across the rows. A similar statement could also be made for each of the tables in sections 6.1 and 6.2. As in section 6.2, the numbers within the body of the table which represent record counts could be converted to show a 1 if a given subject (row) is present in a given data set (column). Then a simple PROC PRINT with a SUM statement would give the number of subjects in each data set. 6.4 CODE HIGHLIGHTS The code below produces the tables shown in sections 6.1 through 6.3. Beginning level programmers may wish to note the use of the macros. In the P02 macro below, supplying a different parameter produces a table with vastly different information in it. Note that the parameter to P02 must be uppercase. %macro P01; title2 "Edit check=p01 Variables down, data sets across the top. (EC6)"; proc contents data=raw._all_ noprint out=cont(keep=memname name); proc sort data=cont; by name memname; data cont; set cont; f=1; proc print width=min; var name mem: f; run cancel; proc transpose data=cont out=cont_t(drop=_name_); by name; id memname; var f; proc print width=min uniform; %mend P01; %P01;

9 %macro P02(bv=); proc sql noprint; select memname into :memname_ separated by ' ' from dictionary.columns where upcase(libname)='raw' & upcase(name)="&bv" ; quit; data all_qv; length dataset $20; %macro loop; %let i=1; %let ids=%scan(&memname_,&i,%str( )); %do %while (%length(&ids) gt 0); proc freq data=raw.&ids(keep=&bv) noprint; tables &bv / missing list out=&ids(keep=&bv count); data &ids; set &ids; dataset="&ids"; data &ids._order; &bv=.z; dataset="&ids"; data all_qv; set all_qv &ids &ids._order; if dataset NE ''; %let i=%eval(&i+1); %let ids=%scan(&memname_,&i,%str( )); %mend loop; %loop; proc sort data=all_qv; by &bv dataset; * Alphabetizes except out of sorts data set placed first (?). *; proc transpose data=all_qv out=all_qv_t(drop=_:); by &bv; var count; id dataset; options ls=170 ps=67; title2 "Edit check=p02_&bv Distribution of &bv among all data sets. (P011)"; proc print uniform width=min noobs data=all_qv_t(where=(&bv NE.z)); title2; %mend P02; %P02(bv=VISIT); %P02(bv=VIS_NUM); %P02(bv=PT); 7. A CONSISTENCY CHECK UPDATE REGARDING AMERICAN AND BRITISH ENGLISH SPELLING 2006 PharmaSUG paper TT14 presented a SAS program that points out discrepancies in usage across a set of SAS outputs or within an MS Word document. This consistency check program creates a SAS data set with a single variable containing all words in a document or set of documents. Then each occurrence is counted, collapsed into a unique record, and scored for spelling and other characteristics. A use of this consistency check program that is not described in the paper is to detect British verses American versions of English. The special dictionary described in the paper can be modified to score words with various spellings such that words with British spelling are separated from words with American spelling in a special section of candidate words. If the intended audience is British, one can look over the American spelling section of the

10 Consistency Check output for candidates to be altered to use the British spelling. Alternatively, for an American audience, the British section could be checked. For a general audience, the decision to be consistent one way or another could be validated by using Consistency Check output. A good deal of customization (customisation?) is needed for this to be useful. Web sites exist with lists of words using British versus American English spellings. A search of british american english spelling list on your favorite search engine will generate a good start on this list. 8. A WORD-FIND SOLVER I feel fortunate to be able to make a living doing something I enjoy: programming. I also enjoy applying SAS to problems outside of my work. Occasionally something I learn in such pursuits is applicable to pharmaceutical programming. Outside of general programming learnings, I haven t quite found the direct application of a word-find yet, but perhaps a reader will suggest something. Read on. 8.1 THE TASK AND SOLUTION The objective of a word-find puzzle is to find a list of words (target) within a grid of letters. The words may be up, down, forward, backward, or diagonal but must be in a straight line. For example, the word CAT is found reading across from the initial position of the 6 th row and 2 nd column (6,2). CAT is also found starting from (4,4) both reading down and northwest. Y Z B D C A X T K L M N W J A H G O A I B C F P V C D A E Q U C A T S R A B C D E F A B C D E F The code in section 8.2 reads in the letters of the grid, generates candidate words composed of all valid combinations of letters in the grid, then compares the target list of words with these candidates. For matches, the beginning (p,q) and stopping (ps, qs) positions are printed as shown for the word CAT: Obs w p q ps qs 1 CAT CAT CAT CODE HIGHLIGHTS Highlights schmilights! Here is the whole program. options nocenter;* mprint mlogic macrogen symbolgen; * Read in grid to data set *; data wf; input q $; q_w=length(q); q_h=_n_; cards; YZBDCA XTKLMN WJAHGO AIBCFP VCDAEQ UCATSR ABCDEF ABCDEF ; * Read in grid to single macro variable and create macro variable dimension. *; proc sql noprint; select q_w, q

11 into :q_w, :q separated by ' ' from wf; select max(q_h) into :q_h from wf; quit; data q_max; q_max=max(&q_h,&q_w); proc sql noprint; select q_max into :q_max from q_max; quit; * From grid in the form of a single macro variable create an array of macro variables. *; %macro loop; %let i=1; %let ids=%scan(&q,&i,%str( )); %do %while (%length(&ids) gt 0); %do c=1 %to &q_w; %global mv_&i._&c; %let mv_&i._&c=%substr(&ids,%eval(&c),1); %let i=%eval(&i+1); %let ids=%scan(&q,&i,%str( )); %mend loop; %loop; * Cycle through grid capturing all possible words. *; %macro loop2; data all; length w $&q_max; %do p=1 %to &q_h; %do q=1 %to &q_w; %do x=-1 %to 1; %do y=-1 %to 1; %do wl = 2 %to &q_max; w= %do c=0 %to %eval(&wl-1); %let ps=%eval(&p+&y*&c); %let qs=%eval(&q+&x*&c); "&&MV_&ps._&qs" ' ' ; p=&p; q=&q; ps=&ps; qs=&qs; if (0 LT &ps LE &q_h) & (0 LT &qs LE &q_w) & NOT ((p EQ &ps) & (q EQ &qs)) then output; %mend loop2; %loop2; proc sort data=all; by w; ***proc print data=all(where=(w IN ('CAT' 'GO')));

12 *** * Put in words to find here. *; data find; length w $&q_max; input w $; cards; JICC CAT GO QWERTY YXWAVUAA ; proc sort data=find; by w; ***proc print; *** data qwe; merge all(in=a) find(in=b); by w; if a & b b; proc print; CONCLUSION I hope something here was useful to you. I hope you take time to share your ideas with others. Don t forget how fun programming can be! REFERENCES Morrill, JM and David J. Austin, Consistency Check: QC Across Outputs for Inconsistencies Proceedings of the 2006 Annual Conference of the Pharmaceutical Industry SAS Users Group, May Available online at (accessed 24 January 2007). ACKNOWLEDGMENTS The concept of DSPTRs was first introduced to me in 2005 by Dr. Indra Fernando of Pharmion Corporation. It was independently suggested by Suzanne Lassman of EMB Statistical Solutions, Inc., and was used successfully on a recent project with EMB. The idea of using Consistency Check in detecting British versus American spelling variations was suggested by Neil Malone of Pharmion Corporation. My daughter Laura provided the impetus to create the word find solver. Doug Moore and Dr. Indra Fernando provided valuable comments in review of this paper. My thanks goes to these and many others who have freely shared ideas over the years. SAS and all other SAS Institute Inc. product or service names are registered trademarks or trademarks of SAS Institute Inc. in the USA and other countries. indicates USA registration. CONTACT INFORMATION Your comments and questions are valued and encouraged. Contact the author at: John Morrill Pharmion Corporation 9900 W 109 th Street, Suite 300 Overland Park, KS Work Phone: JMorrill@Pharmion.com or JSMorrill@gmail.com