Importing Medical Expenditure Panel Survey Data Into SAS

I did an in-house SAS user group presentation last week on using SAS survey procedures to analyze Medical Expenditure Panel Survey (MEPS) data with regard to insurance coverage in the context of healthcare reform (ACA and the New Individual Segment: Profiling the Uninsured and Non-Group Insured Populations with MEPS 2010 and SAS Survey Procedures). The MEPS 2011 consolidated data file is available as of September 2013 for download. It contains detailed information (over 1900 variables) on demographics, household income, employment, diagnosed health conditions, additional health status issues, medical expenditures and utilization, satisfaction with and access to care, and insurance coverage of those surveyed.

There are several government data sets made available to the public each year that are designed for easy analysis with SAS and other statistical programming software (including STATA and SPSS). I attended a BASUG training by Paul Gorrell back in 2012 which introduced me to some of these data sets. The MEPS website includes programming statements to help you import the data to SAS. If you have a SAS/STAT license with Base SAS of version 9 or above, you have access to four SAS survey procedures (PROC SURVEYFREQ, PROC SURVEYMEANS, PROC SURVEYREG, PROC SURVEYLOGISTIC) that you can use to analyze data from complex survey designs such as MEPS.

You can get started in just a few easy steps. There are a couple of ways to do this, but this is the method I used:
1. Download and run the h147ssp.exe file to extract the data to your chosen library.
2. After you execute the file above, you should be able to find the sas transport data file (h147.ssp) in your folder. Now you have to tell SAS where to find it with a FILENAME statement.
3. Assign the LIBNAME where you want your SAS data set to be created.
4. Import the data using PROC XCOPY.

Here’s an example:
LIBNAME MYLIB ‘C:\Users\C31497\Desktop’;
FILENAME H147 ‘C:\Users\C31497\Desktop\h147.ssp’;
PROC XCOPY IN=H147 OUT=MYLIB IMPORT;
RUN;

That’s it! Next you can run a PROC CONTENTS to get a full variable listing, or you can view the online codebook on the MEPS site. You can find out more about SAS Survey procedures in my NESUG 2013 paper, Proc SurveyCorr.

Two Interview Questions for SAS Programmers

I have a colleague who asks the same two questions every time he interviews a SAS programming consultant for an opening on his team. His first question has to do with the program data vector (pdv). His logic is that understanding the pdv is central to understanding how SAS processes data. Since he is a data step programmer, I also suspect that he uses this question to weed out programmers who rely extensively on PROC SQL, but lack a basic understanding of how the DATA STEP works. I am certainly guilty of preferring PROC SQL over DATA STEP programming, but I do know about the pdv and agree that it is important to understand how SAS processes data in order to make sure your programs run efficiently. Unlike querying with SQL in a relational database, where you want to use a set-based, non-sequential approach to maximize efficiency, SAS processes data sequentially. Understanding this procedural/iterative processing vs. the familiar set-based approach is important for someone coming from SQL to SAS.

When SAS compiles a data step, it creates the program data vector, which contains the automatic variables _N_ and _ERROR_. These variables are not written to the output data set, but they can be accessed and output to another variable or to the log; _N_ stores the number of times the data step has iterated during execution, while _ERROR_ is a binary variable set to 0 unless an error occurs during execution, in which case it is set to 1. As a data step executes and reads the input file, the current observation is read to the pdv, _N_ increments by 1, and the observation gets written to the output file. Then the program loops back to the top of the data step, and the process iterates until it reaches the end of the file, or until an error occurs. You can use this knowledge of the data step and the automatic variables to debug your programs — for example, you can write an observation containing an error to the log using the following statement:

if _error_=1 then put _infile_;

You can also use _N_ as an observation counter, if you are only reading in one observation for each iteration of the data step (it is important to remember that _N_ actually represents the number of iterations of the data step, which will often equal the number of observations read, but not always).

The second question for the prospective SAS programmer is to see if they can name three system options that are useful for debugging code containing macros. These are MPRINT, MLOGIC, and SYMBOLGEN. SYMBOLGEN automatically resolves macro variables used in submitted statements and prints them to the log; this helps you see at a glance if your macro variables are resolving to the values you expect. MPRINT outputs the full macro statements executed when you call a macro and prints them to the log. MLOGIC helps trace the execution of a macro by writing messages to the log at various stages of execution, so you can see more easily where a macro fails.

How to Use ODS to Zip Files in SAS 9.2

Starting with SAS version 9.2, you can use ODS to create zip files in SAS without having to use platform-specific commands (such as Unix commands if your files are on a Unix server). I used ODS to zip a file on my C drive in four steps:

  1. First, I told SAS that I wanted to create a new package. You don’t need to name your package unless you are going to create multiple packages:
    ods package open nopf;
  2. Next, I added my file to the package. You can add multiple files, but I recommend that you only zip a single file at a time. Also note that unless you add the file extension to the full path, your SAS program will run with no errors, but the resulting zip file will be empty:
    ods package add file=’C:\Users\C31497\Desktop\projects\h138.sas7bdat’;
  3. Then I published the zip file and gave it a name. The zip file appears by default in the same path as the original file, but you can specify a different path using the archive_path argument when you assign the properties. If there is an existing zip file with the same name, it will be overwritten:
    ods package publish archive properties(archive_name=’h138.zip’);
  4. Finally, don’t forget to close the ods destination after you’re finished. You may also wish to drop your original (unzipped) file, since this is not done automatically after the zip file is created:
    ods package close;

Here’s what it looks like when you put it together:

ods package open nopf;
ods package add file=’C:\Users\C31497\Desktop\projects\h138.sas7bdat’;
ods package publish archive properties(archive_name=’h138.zip’);
ods package close;

There is still no way to unzip your files outside of using platform-specific syntax, so hopefully SAS is working on that for a future version.

The Last NESUG

I attended NESUG 2013 in Burlington, VT earlier this week, along with some colleagues. One announcement at the end of opening session caught us off-guard – that NESUG 2013 was to be the last NESUG. NESUG 2014, which had been originally planned to take place in Philadephia, is now canceled, as are all other NESUG conferences going forward. The committee sent out a follow-up email to their opening session announcement in which they detailed the reasons for the announcement. SAS has been a major sponsor of the conference since its inception, contributing both funding support and a large number of displays and presenters to the conference. Apparently SAS notified the committee on August 29th that they have chosen to reduce funding for all the annual regional conferences, choosing instead to focus on industry-specific conferences such as PharmaSUG and more shorter, local events. Given this withdrawal of support, the committee determined that it could no longer hold the annual conference.

NESUG was the first of the regional conferences to be held this fall, so we are expecting news from some of the other regional conferences such as SESUG and WUSS later this fall as they decide whether they, too, will be unable to continue putting on their events. The regional conferences provided a cross-industry forum for users to gather locally and share programming techniques, discuss new procedures and SAS updates, and share their research projects with a tight-knit community. NESUG was a more intimate gathering than SAS Global Forum and for many first-time presenters, it was a smaller, less-intimidating conference, often within driving distance of home, at which to share their work. We will miss seeing the same faces year after year and are disappointed that SAS has decided to withdraw their support and seek another direction.

Updated: As of September 18th, the NESUG committee has posted more information on their site about their decision, along with some documents from SAS about their support of the regional conferences going forward.

SAS Withdraws Funding for Regional User Groups

At the opening session this week, the NESUG committee announced that NESUG 2013 would be the last NESUG. They sent a follow-up email the next day explaining the reasons behind this decision:

To the NESUG User Community:

On August 29, SAS informed us and the other regional user groups that they were significantly reducing funding support for annual regional conferences, including NESUG, beginning in 2014.

The NESUG Executive Committee met on September 3 to discuss this decision and to decide our response. We came to the conclusion that we, as volunteers, can no longer conduct a conference as successfully as we have for more than a quarter of a century. Therefore, the NESUG Executive Committee has voted unanimously to cancel all future conferences.

We want to thank our attendees, and especially the hundreds of volunteer presenters, session coordinators, registration desk volunteers, and others who so generously donated their time and talent to help the NESUG conference to set a standard of excellence for over a quarter of a century. We will miss you, but we encourage you to stay involved with the SAS community.

Regards,
NESUG Inc. “Of the user, by the user, for the user”

Daphne Ewing
Warren Stinson
Sue Douglass
Earl Westerlund
Lois Levin
Paul Gorrell
Lisa Eckler
Lisa Pyle
George Hurley