of my job is to understand the data and how to properly use them to correctly answer research questions.1
Medicare data are unlike any other health care data, and the uniqueness of Medicare data is driven by the uniqueness of the Medicare program. For example, public policy decisions largely influence decisions surrounding what services Medicare covers and how those services are paid for. This differs from the decision making process of a commercial health plan, which seeks to maximize profits. Here are a few examples, some of which we will discuss in coming chapters:
• Medicare generally covers elderly beneficiaries without regard to medical history. Therefore, the Medicare population is generally sicker than the population of most commercial health plans.
• Part D prescription drug data contains information for out-of-hospital prescription drug fills. Prescription drugs administered during a hospital stay may not appear in the claims data at all.
• Services paid for by Medicare Part C (Medicare Advantage) may not appear in the administrative claims files because they are paid for by managed care providers.
• Medicare pays for some services (e.g., home health agencies, hospice, or acute inpatient hospitals) using what are called prospective payment systems (PPS).
These examples are supposed to whet your appetite for learning about Medicare data. I am hoping that you have not run screaming from your desk! If you have, please come back! We will learn about all of these concepts and more! The point I am trying to make is that the more you understand the Medicare program, the more you will understand how to properly use Medicare administrative data for research purposes. To this end, this book will describe the Medicare program, Medicare data, how the two interact, and how that affects the SAS programmer who uses the data. These concepts and techniques will be illustrated through the completion of an example research project.
Learning how to use Medicare data is a lifetime pursuit. It takes many, many years to build subject matter expertise due to the sheer volume of information on topics like Medicare policy, payment systems, and data. What’s more, the world of Medicare data is changing rapidly due to increased attention on Medicare costs, quality, and the use of information technology in health care delivery. For example, the use of electronic health records (EHRs) in the measurement of utilization, cost, and quality is on the horizon. EHRs will supplement, or perhaps someday replace, the administrative claims data we use in this book. In addition, Medicare is exploring different methods of payment, such as the bundling of services previously paid on an individual basis. As such, we will never be able to cover every topic you will run into. However, we will build a very strong foundation in standard concepts, such as specifying and coding continuous enrollment algorithms and identifying and summarizing common services and events. My hope is that the reader can apply this foundation to programming projects that use Medicare data and use it to gain a broader perspective on the use of health care administrative data in general.
Framework of This Book
This book is organized as an approach to completing a research programming project. The basic framework below can be used as a blueprint for programming most any research project, including the example we will use in this book.
1. Plan the project by identifying the research questions to be answered and thinking through how we will construct our code to provide those answers. Prior to writing any code, we will create a data flow diagram of our programming plan and use that plan to request data. Typically, prior to writing any SAS code you would write programming specifications (or business requirements or functional requirements) that state exactly how you plan to answer the research questions using SAS code. For illustrative purposes, we will write the specifications as we code (i.e., the specifications will be our explanation of the code).
2. Obtain the needed data. There are many different types of data you can use, depending on the nature of the project and its requirements. Our project will focus on using administrative claims and enrollment data.
3. Develop code to create the analytic files needed to answer research questions. Analytic files are essentially summaries or subsets of the raw source data that we will use to perform the analysis that answers the research questions.
4. Develop code that utilizes the analytic files to create answers to the research questions.
5. Perform quality assurance and quality control of our algorithms.
6. Run our algorithms in production, typically by using a batch submittal.
7. Create documentation, take steps to preserve our output data sets, and complete any contractually required data destruction.
Our Programming Project
During the planning process for this book, I thought long and hard about an example project that would be useful to a variety of users. I wanted the project to address common research questions and result in the creation of algorithms that are almost universally applied to research programming work that uses Medicare data. As such, I came up with the following criteria for the project:
• The research questions must be applicable and relevant to today’s research environment. For example, the accurate measurement of utilization and cost of health care services are topics that have been consistently important and relevant since the first person used a computer to analyze health care claims.
• The research questions must lend themselves to building a foundation for addressing “real world” questions. The foundation for all research programming projects is the study population, so our example project will include obtaining beneficiary enrollment data for defining continuous enrollment.
• The research questions must result in algorithms that are easily adaptable to being used to answer research questions in your “real world” work. For example, we will create an algorithm that defines continuously enrolled beneficiaries as those beneficiaries who have had Medicare Fee-for-Service (FFS) coverage for all 12 months of a study year. This kind of algorithm is easily modified to define continuously enrolled beneficiaries as those beneficiaries enrolled in Medicare Advantage (MA) for 6 months of the year.
• Although this is an introductory text, the research questions must illustrate some of the complexity of using Medicare data. If there is one common trait that unites all of the projects that I have worked on, it is that the project always grows in complexity.
With these criteria in mind, I designed the following example research project:
Let’s imagine that we are working at a university or a policy research company (maybe you don’t need to imagine this because you already are!). Let’s further imagine the Centers for Medicare & Medicaid Services (CMS) enacted a pilot program during calendar year 20102 designed to reduce costs to Medicare and improve (or at least not harm) quality outcomes for Medicare beneficiaries. The details of the pilot program are not particularly important to our effort, so let’s imagine that the program provides an extra payment to providers that significantly reduce payments and improve quality outcomes when compared to groups of their peers. We have been asked to evaluate the effectiveness of the program, and we would like to start by measuring simple payment, utilization, and quality outcomes for those providers that interacted with the beneficiaries in our sample population during the study year 2010. Because the program had been operational for the full 2010 calendar year, we can identify the providers that participated in the pilot. Therefore, the starting point for our example research programming project is a file provided by CMS that contains identifiers for the providers that participated in the pilot program, along with identifiers for the beneficiaries associated with those providers.
