Nikki's approach is to use PROC SQL with a where statement. proc sql; create table sql_readin as. quit;run;

Transcription

1 THE ROAD TO SAS DELIVERANCE- DUELING CODERS Nikki Carroll, Kaiser Permanente, Aurora, CO Frank Ferriola, Elk Crossing Technologies Corp, Highlands Ranch, CO ABSTRACT There's more than one way to skin a cat. There are more ways to program in SAS than you've had hot dinners. There are more ways to program in SAS than you can shake a stick at. You take the high road and I'll take the low road. All roads lead to Rome. Six ofone... halfa dozen of the other. All of these familiar cliches lend to the idea that there are many possible ways to program in SAS, yet still get to the same desired outcome. This paper's goal is to look at multiple illustrations where a programmer can use different SAS procedures that yield the same output. Advantages and disadvantages of each program will be discussed and actual program code will be included. INTRODUCTION When beginning to program in SAS, users often discover different people have different ways to program. The programs might be different, yet they yield the same end result. SAS is a wonderful language that makes it easy to accomplish things at different levels. What we will show in this paper are a few basic approaches to the same problem. It is not our intent to favor one approach over the other, it is to give the reader alternatives and let him/her decide which one they feel comfortable with. STARTING WITH DATA Anytime you write a SAS program, you are going to need to process data. The most common ways to process data include creating it with code, using an existing SAS dataset or import or read in external data. For our purposes we will start with SAS datasets that have already been created for this paper. The data incorporates Pharmaceutical records for prescription drugs. DUEL 1: CHOOSE YOUR WEAPONS! Task: Read in a dataset and exclude data for certain parameters. Frank chooses to use the DATA step and will read the data in followed by specific exclude statements. data data_step (keep;brn cost ndc provider svc_age); set data.wussrx_02; where 18<=svc_age<=65; Nikki's approach is to use PROC SQL with a where statement. proc sql; create table sql_readin as quit; select hrn, cost, ndc, provider, svc_age from data.wussrx_02 where svc_age between 18 and 65; NOTE: The data set WORK.DATASTEP has observations and 5 variables. NOTE: Table WORK.SQL_READIN created, with rows and 5 columns. Analysis: Both ways created the same table with the same number of records and variables. Nikki could have used a wildcard (*) in her select statement and likewise Frank's keep statement is optional. Also notice that the "Between" statement in SQL is actually inclusive of 18 and65. Processing time was insignificant in this example (1/Sth second faster for SQL) but for huge datasets, SQL might be the better choice. Both ways requires similar keystrokes. PROC SQL uses one complete statement, while DATA uses several statements to make the procedure. In both cases you can "build" your procedure by starting simple and adding parts to it. Recommendation: Unless you are using very large datasets, either process will work. You can try hoth and see which one you are most comfortable with. DUEL 2: Stand back to back! Task: Merge datasets to get product information. Once again Frank will use the Data step to merge the files, but first both datasets must be sorted: proa sort data=data_step; by ndc; proc sort data;data.wussprod_02 out=wussprod; by ndc; data data_merge; merge data_step (in;a) wussprod (in;b); if a; by ndc; 417

2 Nikki's approach is to again use PROC SQL with a where statement to merge the datasets in order to get the product information. proc sql; create table sql_merge as quit; select b.generic, b.brand, b.gpi, a.provider, a.cost, a.svc_age Frank's Log shows: from sql_readin a, wuss.wussprod_02 b where a.ndc=b.ndc; NOTE: The data set WORK.DATA_MERGE has observations and 6 variables. NOTE: Table WORK.SQL_MERGE created, with rows and 6 columns. Analysis: Once again, the two processes yield the same results. Frank's method requires presorting the two datasets, while Nikki's doesn't. In SQL you can also match on two different variables (although in this example the same one is used) while in the merge statement in the data step, you must have the same variable name in all datasets. Notice also that the two datasets are referred to as a and b. The IF A statement in the data step indicates that the record will be kept only if it is in the first data set (A). The data step requires that the data be "overlayed" from left to right. That is, any like variable names in the datasets will be taken from the rightmost data set first. In this case Wussprod values would supercede data-step values. SQL gives more versatility by giving you options on "which way" you want to merge. Recommendations: This is one area where SQL is generally a better choice when merging several datasets or complex joins. However, with the understanding ofhow merge works, you can easily merge two data sets with the datastep. DUEL 3: Start Walking! Task: Format vs. Coding This time both will use a data step. Frank will use a PROC FORMAT and then format the data within the data step. proc format; value $gpiname '58'='Antidepressants' '39'='Antihyperlipidemic' '27'='Antidiabetics' '12'='Anivirals' '49'='Ulcer Drugs' '44'='Antiasthmatics' '21'='Antineoplastics' '?2'='Anticonvulsants' '4l'='Antihistamines' '59'='Antipsychotics' '30'='Endocrine' '36'='Antihypertensives' '34'='Calcium Channel Blockers' '67'='Migraine Products' data data_format; set data_merge; '86'='0pthalmics' 'Ol'='Antibiotics'; gpiname=substr{gpi,l,2}; format gpiname $gpiname.; Nikki's approach is to hard code the data in a data step using if-then-else statements. data hard_code; set sql_merge; if substr(gpi,l,2l = '58' then gpiname='antidepressants'; else if substr(gpi,l,2) = '39' then gpiname = 'Antihyperlipidemic'; else if substr(gpi,l,2) = '27' then gpiname = 'Antidiabetics'; else if substr(gpi,l,2) = '12' then gpiname = 'Anivirals'; else if substr(gpi,l,2) = '49' then gpiname = 'Ulcer Drugs'; else if substr(gpi,l,2) = '44' then gpiname = 'Antiasthmatics'; else if substr(gpi,l,2l = '21' then gpiname = 'Antineoplastics'; else if substr(gpi,l,2l = '72' then gpiname = 'Anticonvulsants'; else if substr(gpi,l,2l = '41' then gpiname = 'Antihistamines'; else if substr(gpi,l,2l = '59' then gpiname = 'Antipsychotics'; else if substr(gpi,l,2) = '30' then gpiname = 'Endocrine'; else if substr(gpi,l,2) = '36' then gpiname = 'Antihypertensives'; else if substr(gpi,l,2) = '34' then gpiname = 'calcium Channel Blockers I ; else if substr(gpi,l,2) = '67' then gpiname = 'Migraine Products'; else if substr(gpi,l,2) = '86' then gpiname = 'Ophthalmics'; else if substr(gpi,l,2) = '01' then gpiname = 'Antiobiotics'; else gpiname = 'Other'; NOTE: The data set WORK.DATA_FORMAT has observations and 7 variables. NOTE: The data set WORK.HARD_CODE has observations and 7 variables. Analysis: For a third time the results are identical. Nikki's approach required more keystrokes and is not reusable. Frank's PROC FORMAT is reusable within the same program or can be stored in a Format Library for use by other programs. This way there would be one source to make any changes to the format. Nikki could accomplish the same thing by putting the hard code in a macro and store it in a Macro Library, which would be callable by other programs. Recommendations: If you have only a handful of values and/or you are only using this process once, or you need to get answers quickly, you can hardcode the values into 418

3 your program. For long-term efficiency however, you should store this code in a macro or use the Proc Format stored in a Format Library. id provider; var gpiname numrx totcost; by provider; DUEL 4: Stop and Turn! Task: Summarize data with count of prescriptions and total cost by provider and gpiname. Frank will use PROC SUMMARY: proc summary nway data;sumprep; class provider gpiname; var cost; output out=data_summary (rename=_freq_=nurnrx drop=_type_) sum=totcost; proc sort; by provider descending numrx; Nikki's approach is to use the beloved PROC SQL. proc sql; create table summ_data as select provider, gpiname, count(gpi) as numrx, sum(cost) as totcost from hard_code group by provider, gpiname order by provider, numrx desc; quit; NOTE: The data set WORK.DATA_SUMMARY has 6456 observations and 4 variables. NOTE: Table WORK.SUMM_DATA created, with 6456 rows and 4 columns. Analysis: Once again the results are identical. Both processes include all of the same components, however Frank's requires the extra sort step to order them after the summary has completed. Frank has been using PROC SUMMARY for years (see paper from SUGI 27 Nikki, on the other hand has always preferred SQL and has written two papers on the subject in the proceedings of WUSS1999 and WUSS2000. Recommendations: This is another case of personal preference and comfort level. Neither Frank nor Nikki would like to recommend one process over the other as that might lead to fisticuffs. DUEL 5: Fire! Task: Print Reports. Frank chooses to use the DATA step and will read the data in followed by specific exclude statements. Frank does a straight proc print: proc print data=data_summary; Nikki's approach is to export a delimited file out to Excel where she can "make it pretty''. data _null_; set summ_data; by provider; file 'e:\mydocs\excel\costrx\temp\wuss_rpts.xls'; if first.provider then do; put (provider gpiname numrx totcost) ( I ; 0 ) ; end; else do; put I;' (gpiname numrx totcost) ('; '); end; NOTE: There were 6456 observations read from the data set WORK.DATA_SUMMARY. NOTE: The file 'e:\mydocs\excel\costrx\temp\wuss_rpts.xls ' is: File Name=e:\mydocs\excel\costrx\temp\wuss_rpts.xls, RECFM=V,LRECL=256 NOTE: 6456 records were written to the file 'e:\mydocs\excel\costrx\temp\wuss_rpts.xls ' The minimum record length was 18. The maximum record length was 38. NOTE: There were 6456 observations read from the data set WORK.SUMM_DATA. Analysis: Both of these processes are very simplified, and both can be enhanced with other options. There are also other possibilities like ODS, Proc Report, and Dynamic Data Exchange (DDE). The key point here is that two different processes created the same final data set. You can switch Frank and Nikki's processes on each other's final datasets and get the exact same output. Please see Exhibits 1 and 2 at the end of this paper for sample output. Recommendations: The output method you choose will depend on your client or boss's specific needs. If you are just looking for a report to pull nwnbers from, PROC PRINT will work. If you need to put further information in or do analysis, the PROC EXPORT method will be more useful. CONCLUSION Having gone through 5 different processes, the duel would have to be called a draw. The point is that SAS is versatile enough to allow you to get to the same endpoint in different ways. It also shows that no matter how good your program is, you can usually look at it again and find a way to simplify it even more. In some cases this will 419

4 help you in the long run as you create more and more programs and won't have to duplicate code. The users are left to make up their own mind on which processes they prefer. And remember... there are more ways to program in SAS than you can shake a stick at! ACKNOWLEDGMENTS The Authors would like to thank the following people for their help with this paper: Frank would like to thank: William Slentz and Brian Wright, my mentors from Blue Cross Blue Shield of Delaware Doug Felton for help with previous papers, which eventually led to this one, Daryl Baird, my current mentor and business partner, And finally to co-author Nikki Carroll, for her papers on SQL which led me to the initial idea for this paper, and who has been relentless in keeping this paper going. Nikki would like to thank: Greg Carroll for putting up with me. Beth Worrall for all of her inspiration. And finally to co-author Frank, for coming up with the idea for this paper, for having a great sense of humor and being so fun to work with! CONTACT INFORMATION Your comments and questions are valued and encouraged. Contact the authors at: Nikki Carroll Kaiser Permanente E. Centertech Pkwy Aurora, CO (303) (work) (303) (fax) nikki.m.carroll@kn.org Frank Ferriola Elk Crossing Technologies Corp W. Deer Creek Dr. Highlands Ranch, CO (303) faferriola@elkcrossing.com 420

5 Exhibit 1: Frank's Sample Output 10:41 Saturday, June 15, provider gpiname numrx tot cost 7 Antiasthmatics Ulcer Drugs Antibiotics Antihistamines Antidepressants Antihypertensives Antidiabetics Antidepressants Antihyperlipidemic Antiasthma tics Ulcer orugs Calcium Channel BlOckers Antibiotics Anivirals Anticonvulsants Migraine Products Antihistamines Antipsychotics Opthalmics Endocrine Antihyperlipidemic Antihypertensives Calcium Channel Blockers Antibiotics Antidepressants Ulcer Drugs Antihypertensives Calcium Channel Blockers Ulcer Drugs Antihypertensives Antiasthma tics Antidiabetics Antihyperlipidemic Antidepressants Calcium Channel Blockers Ulcer Drugs Anticonvulsants Opthalmics B Anivirals 6.14 Antipsychotics Antibiotics Antihypertensives 2B

6 Exhibit 2: Nikki's Sample Output # TOTAL PROVIDER GPINAME RXS COST 7 Antiasthmatics 50 $ 5, Ulcer Druas 4$ Antiobiotics 3$ Antidepressants 1 $ 6.38 Antihistamines 1 $ Antihypertensiv 50 $ Antidiabetics 44 $ 1, Antideoressants 41 $ 1, Antihvoerlioide 3f $ Antiasthmatics 32 $ 1, Ulcer Drugs 30 $ Calcium Channel 21 $ Antiobiotics 9 $ Anivirals 8$ 2, Anticonvulsants 7$ Miaraine Produc 5 $ Antiosvchotics 3$ Antihistamines 3$ Qphthalmics 3$ Endocrine 2$ ~ntihvoerlioide 46 $ 3, Antihvoertensiv 26 $ Calcium Channel 22 $ 1, Antiobiotics 3$ Antidepressants 3$ Ulcer Drugs 2$ Antihvoertensiv 3$ Calcium Channel 2$ Ulcer Drugs 1 $ Antihypertensiv 10 $ Antiasthmatics 9$ Antidiabetics 6$ Antihvoerlioide 3 $ Antidepressants 3 $ Ulcer Drugs 2$ Qphthalmics 2$ Calcium Channel 2$ Anticonvulsants 2$ Anivirals 1 $ 6.14 Antiosvchotics 1 $