\WSS95. Applications Development. Managing Longitudinal Panel Surveys Using Interactive Applications Created by SAS!Af and SASJFsp with SCL

Transcription

1 Managing Longitudinal Panel Surveys Using Interactive Applications Created by SAS!Af and SASJFsp with SCL Miriam Cistemas, Technology Assessment Group, San Francisco, California ABSTRACT Social science researchers have been using the SAS System for years to analyze survey data. Recently, through increases In the functionality of SAS/AF, SAS/FSP, Screen Control Language (SCL) and other aspects of the SAS system available with version 6.08 and above, it has become easier to use SAS to manage other parts of the survey process as well, including subject enrollment, entering of questionnaire data, and in the case of longitudinal surveys, subject tracking and follow-up. The click and-point interface features of SAS/AF and SASIFSP allow these processes to be controlled by a non-programmer such as the survey interviewer, decreasing programmer and secretarial time that is usually required for such efforts. This paper illustrates the implementation of a Sutvey Management System for a longitudinal study of subjects with Carpal Tunnel Syndrome currently in progress at the University of California, San Francisco. Specifically, it shows how the interactive system guides the user through the subject enrollment process, allows the interviewer to enter questionnaire data and patient status data, as well as generate thank-you and follow-up letters to patients and simple reports for investigators concerning patient status. The use of SCL for cross-field and cross-observation validation is also discussed. Finally, a set of guidelines to ease the development of such systems is provided. ensure that the system would be flexible enough so that it would be easy to add options to the menus and modify data-entry screens as the study progressed. Using SAS/AF PROGRAM entries to control branching to various options of the system and using FSEDIT screens to guide the data entry, it was easy to develop a Sutvey Management System. SCL put the building blocks of the system together. STARTING THE SYSTEM After clicking on an icon in the Windows Program Manager, the interviewer is brought to the main menu of the system (Figure 1 ). This main menu is actually a SAS/AF PROGRAM entry, consisting of 7 fields with attributes of PUSHBTNC. When clicked, these buttons call other PROGRAM entries or execute other SCL commands. INTRODUCTION The Carpal Tunnel and Disability (CTD) study at the University of Celifomia at San Francisco requires data to be collected and analyzed for 250 subjects from the following sources: 3 annual telephone interviews, and clinical data from nerve-conduction studies and doctor examinations. Potential study subjects are identified by physicians who agree to participate in the study. The physician must communicate information concerning these patients to CTD interviewers, who then enroll, interview, track subjects, and gather clinical data concerning these subjects for a period of three years. I wanted to develop a system that required no SAS knowledge for the end user that would include extensive cross-field and cross-observation capabilities, as well as the ability to generate simple reports and correspondence. In addition, I wanted to ENROLLMENT OF STUDY SUBJECTS Entering of all data on study subjects is made using customized FSEDIT screens that are similar in appearance to the paper forms on which the data were originally recorded. A button in the Patient Record Keeping menu of the system is associated with the customized FSEDIT screen in Figure 2 by means of the SCL CALL FSEDIT statement. Using the following SCL code, the FSEDIT screen automatically creates variables containing the current date from the system time clock, and a patient identification number for each new observation added to the data set \WSS95

2 FSEINIT: ***open up the current data set: dsidl = return code for opening up current data set (check for dups) dsidl = open( 'cts.ctspats return; INIT: (keep--pat--l.n.aml!wl phonewl) ) ; ***check whether the observation is new; if lastcm:io='add' then do; dateadd = today(); ***get the patient I of the last patient added and add 1; nobs=attrn(dsidl,'nlobs'); if nobs=o then pat=l; else do; return; FSETERM: rc =fetchobs(dsidl,nobs); patnum=getvarn (dsidl, pat=patnum+l; dsidl = close(dsidl); varm.un(dsidl, pat.)); FNAMEWl: /***first name field***/ LNAMEWl: I?HONEWl: /***last name field***/ /***phone number field***/ **.*only process statements if all 3 fields are filled in; if fnamewl ne ' & lnamewl ne & phonewl ne then do; ***reset all fields to default appearance; rc=field('error off', fnamewl lnamewl phonewl. ) ; rc=field('oolor white underline', 'fnamewl lnamewl phonewl'); ***initialize all duplicate obs fields to missing; dupobsl = dupobs2 =. ; dupobs3 = ; ***look and see whether duplicate values for any of these 3 fields exist at any other observation already entered; if locatec (dsidl, varnum(dsidl, fnamewl ), fnamewl) then dupobsl = curobs (dsidl); if locatec(dsidl,varnum(dsidl, 'l.namewl'), l.namewl) then dupobs2 = curobs (dsidl) ; if locatec (dsidl,varnum(dsidl, 'phonewl'), ph.onewl) then dupobs3 = curobs(dsidl); ***Provide appropriate warnings; select; ***if only first name, do nothing; when (dupobs2 = and dupobs3 = ) ; when(dupobsl = dupobs2 & dupobs2 = alazm; dupobs3) do; rc = field('color red reverse, fnamewl lnamewl phonewl' ) ; rc = field ( error on, fnamewl lnamewl phonewl' ) ; _msg_= Patient with same full name & phone I already entered at ' II Observation II dupobs3 II ' ; cursor ph.onewl; when (dupobs2 = dupobs3) do; <code to handle this condition> The SCL code behind the screen shown in Figure 2 also ensures that no patient is enrolled twice by checking for other observations with the same name and telephone number, and issuing appropriate warnings to the user. This is accomplished efficiently by using the CONTROL ALWAYS statement in the FSEINIT section to allow labeled sections to refer to actual fields in the screen. Thus in the SCL code below, the code is only run when data are entered into the fields named FNAMEW1, LNAMEW1, and PHONEW1 (corresponding to the first name, last name, and phone number fields in Figure 2). retm:n; when(dupobs3 ne ) do; <code to handle this condition> ***go to the next field if no duplicate name or ID I; otherwise do; if curfld () =. PHONEWl' then cursor diagdlwl; WYSS

3 In addition, SCL makes it easy for developers to gently guide the user into making a correct selection when an error has been made. Thus in the Title field of Figure 2, only four choices are valid. If the interviewer does not pick one of these choices, a selection box appears asking for the user to select from one of the valid choices (Figure 3). This feature is accomplished using only one SCL statement: if titlewl not in ('Mr.. I 1 'Ms. I 1 'Mrs. I 1 'Miss. I 1 'Dr. I) then titlewl = showlist ('Mr. I J 'Ms. I 1 '!drs. I 1 'Miss. I 1 'Dr. I 1 'Please select a title below:')r PATIENT INTERVIEWING The system uses information entered at enrollment time to create Information Sheets for subjects to be interviewed. These sheets include subject information (e.g. name and phone number) and space to record contact information which is later entered into the system. The interviewer can generate information sheets for as many subjects as necessary using selections lists and boxes (Figure 3). The interviewer sees a selection box tor all eligible subjects, clicks on those for whom sheets are to be generated, and then presses the 'OK' button. The SCL behind the PROGRAM entry saves these list of subject's identification numbers into a SCL list and then transfers these values to SCL variables by means of an array and a do-loop. ***set up array into which selection list data will be put; array id {40} idl-id40; ***nsel will contain the number of selections the user makes from the selection boxr length nsel 3r ***open the data set containing eligible patients and their m is; dsidl=open('cts.ctspats(keep--pat fnamewl lnamewl) ) ; ***create an empty list which will receive ID Is of subjects selected by the user; idlist=makelist(); rc=curlist(idlist)r ***set size of the selection box; call wregion(l0,15,14,50); ***display m #s and names of eligible patients and allow users to select up to 40 of them, saving these m #s to the SCL list; rc=datalistn(dsidl, pat fnamewl l.namewl', 'Pick up to 40 patients.,, 40) ; nsel=getnitemn(idlist,'count'); ***extract data from the SCL list and put into SCL variables idl-id40; do i = 1 to nsel; id{i} = getnitemn(idlist,'pat',i); ***delete the list from memory; idlist=dellist(idlist); call close(dsidl); After the interviewer has selected the patients for which the Information Sheets are to be generated, the SCL then generates SAS statements to be execute in base software through a SUBMIT block. This SUBMIT block subsets the subject data using these SCL variables (id1-id40) that hold the identification numbers of selected patients, and then runs PROC FSLETTER on this subsetted data. TRACKING OF SUBJECT STATUS/INTERVIEW FOLLOW-UP After the interview or any other patient contact (receiving a change of address postcard, or receiving a signed medical records release form) the interviewer launches the Survey Management System and enters all such information into a FSEDIT screen. The interviewer also has the option of generating various personalized thank-you and letters with envelopes using a process very similar to the one followed to generate the Information Sheets. CLICK-AND-POINT ROUTINE REPORT GENERATION In the early phases of such a study, the interviewer (and programmer) are often asked as to the status of patients identified, enrolled, and interviewed up to this point. Allowing the interviewer to generate such recurring reports with the click of a mouse saves both you and the interviewer time, and is easy to develop. An easy way to do this is to write a SUBMIT block that includes all of the SAS code necessary for the report 27 3 YNSS95

4 inside a labeled section associated with a SAS/AF PUSHBTNC field. The SUBMIT BLOCK can access the subject data entered by the interviewer during subject enrollment and interview follow-up. CUSTOMIZING THE ENVIRONMENT The applications developer and end user usually have different preferences for their SAS environments. You as a developer will probably want a tool-box handy, plus a command line or bar, and access to the AWS menu (or non-windows equivalent). Your end user, on the other hand, should be limited to accessing only the parts of the SAS system necessary the interviewing, subject tracking, and routine reporting processes. The SuNey Management System's function keys are an abbreviated list of the more extensive defaults. Customized keys can be created using the Display Manager KEYS command and saved to the catalog where all of the PROGRAM, HELP, and SCREEN entries are located. These KEYS entries are then associated with SAS/AF entries through the GATTA window, and with SAS/FSP SCREEN entries using the PARMS window. The FSEDIT SCREEN entries of the Survey Management System access a pull-down menu containing customized commands (Figure 4). Such a menu is easy to make using the PMENU procedure, which creates a catalog entry of type PMENU that can be associated with FSEDIT screens using two SCL statements in the FSEINIT section. FSElliiT: ***Set up display options; rc=pmenu ( cts. cts. ctsedit.pmenu ) ; call execcmdi I pmenu on ) ; retunl; PROVIDING HELP TO THE USER As a SAS/AF developer, you have the opportunity to provide HELP entries which can be accessed using pull-down menus, push-buttons, or function keys. For the interviewer who is computer-shy, these can be invaluable. They are easily made by invoking PROC BUILD and editing a HELP entry. Such entries can be called via a PMENU, function keys, or SAS/AF PUSHBTNC fields. SUGGESTIONS FOR CREATING SURVEY MANAGEMENT SYSTEMS 1. Make a 'structure' for each data set to be edited by the system by coding a DATA step for each one. These DATA steps should include a LENGTH or ATTRIB statement for all variables, and a DELETE statement This will ensure that all variables in these data sets will be stored in the order you want, and allows you to avoid designing data sets interactively through FSEDIT. 2. Make the custom FSEDIT SCREEN entries. The screen layout and SCL programs for these entries can be made in a text editor and then brought into the FSEDIT editor using the INCLUDE command. Think of conventions to make all FSEDIT screens have a similar look and feel; do not bombard the user with too many colors. 3. Make PMENUs for FSEDIT screens: if one PMENU cannot do it for all of your FSEDIT screens, try to make them feel functionally equivalent and look as similar as possible. 4. Think of all the options the system will have (immediately and in the future) anff how the user should be able to branch to them. Make all such menus and options appear from the beginning of the development process, and simply have the message line display a message such as 'Option not currently available' for options that have not yet been integrated into the system but will be some day. Then, begin to associate functionality with the menu choices. 5. Create the HELP entries and associate them with the PROGRAM entries, MENU entries, and PMENUs as necessary. 6. Make an -AUTOEXEC file to associate with a Microsoft Windows program item icon (or an equivalent if not in the Windows environment) which will launch the system with the click of a mouse. Use Display Manager commands in this -AUTOEXEC file to iconize or close all windows that you do not want the user to access. \WSS

5 li.bname '<li.bname of AF catalog>'; dm pgm off; log off; 1st off'; dm 'af c=<name of program entxy serving as main menu>' af; Use the -NOAWSMENU option on the command line of the Windows program item if you do not want your user to access the AWS menu. The following statements can be typed into the Command Line box of the Program Item Properties window in the Windows Program Manager: <path of SAS.EXE> -noawsmenu -config <name of config file> -autoexec <name of autoexec file> 7. Use the BUILD procedure with a MERGE statement to create a production catalog for the end user which will exclude the SCL source code and disallow editing of entries. This will protect your work and save space. proc build c=<name of production catlllog>; merge c=<name of developer catalog> run; noedit nosource; 8. Document your SAS/AF work using PROC BUILD with the PRINT command. lproc build c=<name of production catalog>; I run; print; Documentation of SAS/FSP work is more difficult. One way to do this is to save the text of all FSEDIT screens and their associated SCL programs to external text files using the Display Manager FILE command while in the FSEDIT Modify or FSEDIT Program windows. REFERENCES SAS Institute, Inc. (1993) Building SCL Applications Course Notes, Cary, NC: SAS Institute Inc. SAS Institute, Inc. (1989) SAS AF Software, Usage and Reference Version 6, First Edition, Cary, NC: SAS Institute Inc. SAS Institute Inc. (1994) SAS Screen Control Language, Reference Version 6, Second Edition, Cary, NC: SAS Institute Inc. SAS Institute Inc. (1993) SAS/FSP Software, Usage and Reference Version 6, First Edition, Cary, NC: SAS Institute Inc. SAS, SAS/AF, SAS/FSP, and SAS/BASE are registered trademarks or trademarks of SAS Institute, Inc. in the USA and other countries. indicates USA registration. Other brand and product names are registered trademarks or trademarks of these respective companies. ACKNOWLEDGMENTS Robyn Johnson of the Arthritis Research Group of the University of CBiifomia at San Francisco provided invaluable feedback by testing two Survey Management Systems created using SAS/AF and SASIFSP. The faculty of the Arthritis Research Group provided the time and resources necessary to develop these systems. CONCLUSION Creating a customized survey enrollment, data entry, subject tracking, and reporting system which requires no knowledge of SAS for the end user is easy to do using SAS/AF, SASIFSP and SCL. Most importantly, it saves time because the interviewer(s) can efficiently manage parts of the survey process that either you used to do as a programmer (routine report generation and a large percentage of the data cleaning) or that an administrative assistant used to do (generating thank-you and reminder letters, keeping track of subject status and addresses). This is time that can be spent on more rewarding tasks, such as analyzing the survey data WYSS95