Chapter 9: Programming to Identify Chronic Conditions

Introduction and Goals

Review and Approach

Review: Peculiarities of Medicare Data

Our Programming Plan

A Note on the Chronic Conditions Data Warehouse (CCW)

Algorithms: Identifying Beneficiaries with Diabetes or COPD

Algorithms: Evaluation and Management Visits for Beneficiaries with Diabetes or COPD

Algorithms: Diabetic Eye Exams for Beneficiaries with Diabetes

Algorithms: Hospital Readmissions for Beneficiaries with COPD

Chapter Summary

Exercises

 

In simple terms, chronic conditions are medical conditions which have some permanence and can progressively worsen over time, thus requiring long-term management to monitor or treat (e.g., control symptoms or otherwise influence the course of the condition). Chronic conditions are not curable by any short-term treatment, and can exhibit remissions and exacerbations.1 Commonly identified chronic conditions in the Medicare beneficiary population include Alzheimer’s disease, asthma, chronic kidney disease, chronic obstructive pulmonary disease (COPD), depression, diabetes, glaucoma, and certain types of cancer, like breast cancer or colorectal cancer.2

Chronic conditions are important to study for several reasons. First, many Medicare beneficiaries are identified as having at least one chronic condition. For example, roughly 4 million Medicare beneficiaries are identified as having COPD and about 10 million beneficiaries are identified as diabetic.3 Second, beneficiaries with chronic conditions require a high level of specialized and concerted medical care, often resulting in the generation of many claims. In other words, utilization of services for beneficiaries with chronic conditions will be relatively higher than average, and cost may follow suit. Finally, beneficiaries identified as having chronic conditions are commonly used in the measurement of quality outcomes because they benefit from certain standard medical practices. For example, diabetics benefit from annual dilated retinal eye exams to monitor changes in the retina (called retinopathy) that can seriously harm one’s vision. Studying whether a provider performs this test on diabetic patients is a good way of measuring the quality of care provided by the doctor.

In this chapter, we will advance our discussions from Chapter 7 and Chapter 8 by providing more detail on how to measure quality outcomes. Specifically, we will combine the study of two common chronic conditions, COPD and diabetes, with the concept of measuring patient outcomes. Admittedly, quality of care and value measurement are controversial topics, especially if the measurements play a role in the assessment of provider performance or the determination of payment to providers. Indeed, patient outcomes (like hospital readmissions) often depend on things outside of providers’ control, like the behavior of the patient (e.g., does the patient exercise regularly, smoke, or reliably take prescribed medications?) and the patient’s general level of health when he or she began treatment. What’s more, some of these factors, such as whether or not a patient exercises regularly, cannot be measured with Medicare administrative claims data.

Given the above, our goal in this chapter is not to make any determinations about quality of care; after all, we are using fake data purely for simulation purposes! Rather, our goal is to use our example research programming project to teach the reader the mechanics of how to use Medicare data to identify chronic conditions and commonly used indicators of quality outcomes. By the end of this chapter, the reader will understand important foundational concepts to use Medicare administrative claims and enrollment data to identify most any chronic condition or compute most any quality outcome metric. For example, we will discuss calculating hospital readmissions and using diagnosis and procedure codes to identify a condition or an event related to quality outcome measurement (such as diabetic eye exams). The reader could adapt the measurement of eye exams for diabetics to examine a different procedure (say, an immunization for influenza) for beneficiaries with a different chronic condition (such as heart failure). To these ends, in this chapter, we will code algorithms to do the following:

• Use our Medicare administrative claims data to identify beneficiaries with two chronic conditions, diabetes and COPD.

• Measure evaluation and management utilization for beneficiaries with diabetes or COPD.

• Measure utilization of diabetic eye exams for beneficiaries with diabetes.

• Measure hospital readmissions for beneficiaries with COPD.

As discussed in earlier chapters, the online companion to this book is at http://support.sas.com/publishing/authors/gillingham.html. Here, you will find information on creating dummy source data, the code in this and subsequent chapters, as well as answers to the exercises in this book. I expect you to visit the book’s website, create your own dummy source data, and run the code yourself.

Refer to the reviews in Chapters 6, 7, and 8 to review the material relevant to this chapter’s study of chronic conditions and quality. As mentioned above, quality measurement can be controversial because it sometimes involves rating provider performance. With this in mind, let’s review some peculiarities and possible limitations of Medicare administrative data so we can be better prepared to interpret our output.

• Medicare coverage for the elderly is provided regardless of medical history. For example, a beneficiary diagnosed with COPD who becomes eligible for Medicare is granted coverage regardless of her COPD diagnosis. If you are used to working with commercial healthcare claims data, you will likely notice some unique characteristics of the Medicare population, like more beneficiaries identified as having at least one chronic condition (though this may change with the implementation of the Affordable Care Act).

• Some services may not appear in Medicare administrative data. For example, prescription drugs administered during a hospital stay may not appear in the claims data at all. Additionally, services paid for by Medicare Part C may not appear in the administrative claims files because managed care providers pay them.

• The administrative data we use for research purposes is updated on a regular basis, but only with claims that have been received, adjudicated, and deemed final action. As such, the files we use at any given time do not contain all final action claims submitted and paid up to the date of extraction of the data. In some rare cases, when not impractical, medical record reviews can fill in any gaps in information. What’s more, we will see changes to the information available for quality measurement as electronic medical records become more prevalent.

• The correct composition of any study population must be determined carefully. In Chapter 6, we determined that our example research project will examine only those beneficiaries continuously enrolled in fee-for-service Medicare during a defined timeframe, a decision that has implications for the output of our example research programming project. More specifically, this step resulted in eliminating beneficiaries for whom we may not have a full set of claims, giving us more confidence that we are not missing claims for services like retinal eye exams or hospital readmissions for our study population.

In Chapter 5, we submitted a data request to extract all claims and enrollment information for beneficiaries who were treated by the providers in our study population. We received and loaded our data, keeping only those variables we wished to use in our study. In Chapter 6, we used enrollment data to delimit our population to full-year FFS beneficiaries. In Chapter 7, we brought our claims data to bear on the calculation of utilization measurements. In Chapter 8, we used the Medicare amount paid to measure payments of specific services. In this chapter, we will draw on the study of utilization and payment by looking at two chronic conditions, diabetes and COPD. First, we will use diagnosis codes in specific settings of care to identify beneficiaries with diabetes or COPD (or both). Next, we will look at quality of care for these beneficiaries, giving us an excellent chance to apply the programming methods we learned in Chapters 7 and 8.

The output created in this chapter will be analytic files at the beneficiary level, which we will use for the remainder of our programming work. Looking forward, in Chapter 10, we will end our example project by summarizing all of our output.

A Note on the Chronic Conditions Data Warehouse (CCW)

 

Our first task is to identify beneficiaries in our population with diabetes or COPD. At the risk of being repetitive, before we begin, it is very important to note that the diagnosis codes we will use can change from year to year. The same goes for any of the codes we use in this book. For example, procedure and diagnosis codes are updated annually (new codes are created and some codes are retired). Therefore, it is good procedure to regularly check the codes you use to identify diagnoses or services (or anything, for that matter) to ensure they are current. This will be especially true after October 2014, as all codes will change when a new diagnosis coding system, ICD-10-CM, is implemented.

The algorithm to identify beneficiaries with diabetes is adapted from instructions available from the CCW, with some simplifications (e.g., for the identification of diabetes we do not require looking across two years of data).5 Our SAS code involves searching for specific diagnosis codes (see the below algorithms for the lists of specific diagnosis codes). These codes can occur at any position on the claim (i.e., they do not have to be primary diagnoses). The setting in which these diagnosis codes occurs is important. Specifically, if we find evidence that a beneficiary was diagnosed with diabetes on only one occasion in an inpatient or skilled nursing facility setting, we will count that beneficiary as having diabetes. In these settings, trained coding experts review medical records, consult with physicians, and only record a diagnosis if the patient actually has the condition. However, we need two separate events of a diagnosis of diabetes when searching in carrier and hospital outpatient claims.6 Why? Because the occurrence of a single diagnosis of diabetes in these settings may be what is called a “rule out” diagnosis, where the physician is ordering a lab test to check for diabetes. The second diagnosis confirms the beneficiary does have diabetes. In all cases, the diagnoses can occur any time during a two-year period (but we will search just one year of data in our example). Finally, the reader will note that we use home health claims data, but not hospice or DME data, in our identification of beneficiaries with diabetes or COPD. We use home health data even though investigators view diagnosis codes on home health claims as somewhat unreliable. We do not use hospice claims due to the nature of care provided in a hospice setting. Lastly, for obvious reasons, the DME file cannot be used to reliably identify beneficiaries with diabetes or COPD.

The algorithm to identify beneficiaries with COPD is constructed in a similar manner (and also adapted from information provided by the CCW) to the algorithm to identify beneficiaries with diabetes, but using different diagnosis codes (and the search typically occurs over a one-year period of claims data). Therefore, we will code a single algorithm to search inpatient, SNF, outpatient, and Part B carrier claims for evidence of these diagnosis codes, setting flags where appropriate. Then, we will count the flags we created, and use these counts to identify beneficiaries with diabetes or COPD.

In Step 9.1, we present an algorithm for identifying the presence of diagnosis codes used to identify diabetes or COPD in our inpatient, SNF, home health, and outpatient claims data sets. This algorithm is similar to code used in previous chapters to identify diagnosis codes in claims data. We use a macro called CLM_LOOP and array logic to create separate flags set equal to 1 in the presence of diabetes (DIA_IP, DIA_SN, DIA_OP, and DIA_HH) and COPD (COPD_IP, COPD_SN, COPD_OP, and COPD_HH) on a particular claim. Each of these claims data sets contain 25 diagnosis code variables (ICD_DGNS_CD1-ICD_DGNS_CD25). In addition, we must use conditional processing for our inpatient claims data set because, again, we are only searching claims for inpatient short stay and critical access hospitals with non-negative values of PMT_AMT. Therefore, we use a %if clause to read the inpatient claims in UTL.IP_2010_FNL_SS. We output only those records where the flag variables are equal to 1. In Step 9.3 and Step 9.4, we will use these records as definitive proof that the beneficiary has diabetes or COPD (with the exception of the flags derived from outpatient claims data).

 

In Step 9.2, we continue the process of identifying the presence of diagnosis codes used to identify diabetes or COPD, this time using our carrier claims data set. Once again, we search each claim for diagnosis codes that indicate the presence of diabetes or COPD. When such a diagnosis code value is found in one of the carrier file’s 13 line-level7 diagnosis codes (LINE_ICD_DGNS_CD1-LINE_ICD_DGNS_CD13), we set the relevant flag (DIA_CARR, COPD_CARR, or both) equal to 1. We output only those records where the flag variables are equal to 1. In Step 9.3 and Step 9.4, we will use these records to build proof that the beneficiary has diabetes or COPD.

 

In Step 9.3, we use a macro to loop (called CLM_LOOP2) through all claim types processed, summarizing the flags for each beneficiary by claim type, outputting one file for each relevant claim type (CC_CNT_IP, CC_CNT_SN, CC_CNT_OP, CC_CNT_HH, and CC_CNT_CARR). In so doing, we create summary variables called DIA_IP_SUM, DIA_SN_SUM, DIA_OP_SUM, DIA_HH_SUM and DIA_CARR_SUM equal to the total number of claims with the presence of a diagnosis code for diabetes in the relevant claims data set for each beneficiary. Similarly, we create summary variables called COPD_IP_SUM, COPD_SN_SUM, COPD_OP_SUM, COPD_HH_SUM and COPD_CARR_SUM equal to the total number of claims with the presence of a diagnosis code for COPD in the relevant claims data set for each beneficiary. Lastly, we perform nodupkey sort of the outputted files, keeping only one record per beneficiary. We now turn our attention to using these summary variables to make a final determination on whether or not a particular beneficiary has diabetes or COPD.

 

In Step 9.4, we see the above explanation of how to count diagnosis codes for a particular claim type come to fruition. Merging the output of Step 9.3 into a single data set, the code in this step uses the summarized diabetes and COPD flags created in Step 9.3 to identify beneficiaries with diabetes or COPD as follows:

• A beneficiary is identified as having diabetes in the presence of a single relevant diagnosis found in inpatient, SNF, or home health claims data. This evidence is found where DIA_IP_SUM, DIA_SN_SUM, or DIA_HH_SUM is greater than or equal to one.

• A beneficiary is also identified as having diabetes in the presence of two or more relevant diagnoses found on separate outpatient or carrier claims. This evidence is found where DIA_OP_SUM or DIA_CARR_SUM is greater than or equal to two.

• A beneficiary is identified as having COPD in the presence of a single relevant diagnosis found in inpatient, SNF, or home health claims data. This evidence is found where COPD_IP_SUM, COPD_SN_SUM, or COPD_HH_SUM is greater than or equal to one.

• A beneficiary is also identified as having COPD in the presence of two or more relevant diagnoses found on separate outpatient or carrier claims. This evidence is found where COPD_OP_SUM or COPD_CARR_SUM is greater than or equal to two.

 

Beneficiaries with diabetes are assigned a value of 1 to the DIA_FLAG variable, and beneficiaries with COPD are assigned a value of 1 to the COPD_FLAG variable. We then de-duplicate our output data set by beneficiary. We have now identified our subpopulation of beneficiaries with diabetes or COPD, contained in the outputted data set called CND.DIA_COPD_COND. Output 9.1 displays a print of the first 10 observations in the CND.DIA_COPD_COND data set.8

Output 9.1: Print of Beneficiaries with Diabetes or COPD

At this point in our project, we have both a list of beneficiaries in our population with diabetes or COPD, and a data set describing the E&M utilization of beneficiaries in our population. Indeed, the data set of E&M utilization called UTL.EM_UTIL, developed in Steps 7.2 through 7.4 of the code created in Chapter 7, contains a list of E&M services for the beneficiaries in our population. Our algorithm developed in Step 9.5 acknowledges that it is easier simply to merge our list of beneficiaries with COPD or diabetes with this E&M utilization data set created in Chapter 7. The output of this step is a data set called CND.EM_COND, and contains a listing of E&M services dates for beneficiaries with diabetes or COPD. To round out our work in Step 9.5, we summarize the EM_SVC flag for each beneficiary using a PROC FREQ, and use SAS’ Output Delivery System (ODS) to create our results.

 

Output 9.2 shows the frequency distribution run in Step 9.5.

Output 9.2: Frequency of EM Services

Now that we have a taste of using claims data to analyze services for beneficiaries with chronic conditions, let’s search for evidence of eye exam services for the beneficiaries we identified as having diabetes. We will keep our example simple and use a small set of procedure codes to identify retinal eye exams (presented in the code below). However, it is possible to use additional codes, like ICD-9-CM surgical procedure codes. If we were calculating an official quality measure (e.g., an NCQA HEDIS measure), we would perform exclusions on our population of beneficiaries. However, for our purposes, a simple check of the carrier file will suffice; although it would be easy enough to apply this algorithm to other settings, like inpatient claims, using algorithms developed in this chapter.

In Step 9.6, we create a data set called CND.EYE_DIA_COND that contains the beneficiary identifier (BENE_ID) and a flag variable called EYE_SVC indicating whether we found evidence of an eye exam for this beneficiary in the carrier claims. First, we merge the data set created in Step 9.4 that identifies beneficiaries with diabetes or COPD (CND.DIA_COPD_COND) with the carrier claims data set (UTL.CARR_2010_FNL). Because we are interested in eye exams for beneficiaries identified as having diabetes, we subset the CND.DIA_COPD_COND data set with a ‘where’ clause specifying that we retain records where DIA_FLAG is equal to 1. From this point forward, it is a matter of executing code to search the 13 line item procedure code variables for evidence of an eye exam service (this code should look very familiar!).9 We keep records for only those diabetic beneficiaries for whom we found evidence of an eye exam.

 

In Step 9.7, we de-duplicate the output of Step 9.6, overwriting the data set called CND.EYE_DIA_COND so that it now contains just one record per beneficiary.

 

Output 9.3 shows the first 10 observations of the output of Step 9.7.

Output 9.3: Print of Beneficiaries Who Received Diabetic Eye Exams

Let’s look for readmissions within 30 days of discharge for a hospitalization for any reason. As you advance your skills, you will be asked to program more complicated algorithms. For example, you may be asked to calculate readmission after a specific event, like a hospitalization for COPD or Acute Myocardial Infarction (AMI). In our case, we are simply looking for a readmission within 30 days of any hospitalization for our population of beneficiaries identified as having COPD, so we do not need to worry about identifying any diagnosis codes. In some cases, the reader may wish to use both prior and subsequent years of data in order to identify admissions and subsequent readmissions that occurred later in the study year, as well as early in the study year as a result of an admission in the year preceding the study year (in our case, calendar year 2010). For our simple instructional example, this will not be necessary.

First, in Step 9.8, we merge the file identifying beneficiaries with COPD created in Step 9.4 (CND.DIA_COPD_COND) with our inpatient claims data created in Chapter 7 (UTL.IP_2010_FNL_SS). We keep only those inpatient claims for beneficiaries with COPD.

 

Next in Step 9.9, we present code to look through the inpatient claims to identify admissions to a hospital that occurred within 30 days of discharge for a previous admission.10 Specifically, we use PROC SQL code to create a data set called CND.READM_COPD_COND that contains the beneficiary identifier (BENE_ID), discharge date (DISCHRGDT), and admission date (ADMSN_DT) on claims for beneficiaries with COPD representing readmissions to a hospital that occur 30 days after an initial admission. Note that we only select the BENE_ID from the data set with the alias “a” in order to avoid a warning in our log that the variable BENE_ID already exists on the output data set CND.READM_COPD_COND.

 

Output 9.4 shows the first 10 observations of the output of Step 9.9.

Output 9.4: Print of Hospital Readmissions for Beneficiaries with COPD

In this chapter, we used our claims and enrollment data to study chronic conditions and quality outcomes. Specifically, we:

• Discussed the importance of studying chronic conditions. Many Medicare beneficiaries have chronic conditions; treating chronic conditions requires a high level of specialized and concerted medical care, and the treatment of chronic conditions is often looked at from the perspective of measuring quality outcomes.

• Programmed algorithms to identify beneficiaries with diabetes or COPD by defining the occurrence of certain diagnosis codes that identify these chronic conditions (including “rule out” diagnoses), searching the line items on claims for these diagnosis codes, and counting the occurrence of these codes by claim type.

• Programmed algorithms to identify evaluation and management services for beneficiaries with diabetes or COPD by merging beneficiaries with these conditions with the files we created in Chapter 7 to define E&M visits.

• Programmed simple algorithms to identify the occurrence of diabetic eye exams by searching for procedure codes that identify retinal eye exams in the Part B carrier data for beneficiaries identified as diabetic.

• Programmed simple algorithms to identify hospital readmissions for beneficiaries with COPD within 30 days of a discharge for any hospitalization.

1. When using carrier claims to identify beneficiaries with diabetes, investigators often look for two claims separated by one or more days. In this case, we are looking for a diabetes diagnosis on two separate claims, but those claims could occur during the same time period. Can you modify Step 9.1 through Step 9.4 to identify and count diagnoses of diabetes on carrier claims occurring on separate days?

1. Can you modify the algorithms in Step 9.1 through Step 9.4 to identify beneficiaries with prostate cancer? Define beneficiaries with prostate cancer using the specifications from the CCW Medicare Administrative Data User Guide, available for download at http://www.ccwdata.org/cs/groups/public/documents/document/ccw_userguide.pdf.

2. Can you adapt the algorithms in Step 9.8 and Step 9.9 to look for readmissions within 30, 60, and 90 days of discharge for a hospitalization for AMI? Use the inpatient claims for our population of beneficiaries with COPD as your starting point.

3. Can you use the MBSF data received from CMS’s data distribution contractor (i.e., our original enrollment data, not reduced to contain information only for those beneficiaries identified as continuously enrolled in Medicare FFS for all twelve months of calendar year 2010) to identify beneficiaries that died during the year, and subsequently examine their claims data to find evidence of diabetes or COPD? Compare the mortality rates of beneficiaries with diabetes with beneficiaries with COPD, as well as the overall population of all beneficiaries in the MBSF data.

---