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.3 Therefore, we must acquire enrollment and claims data for these beneficiaries, and subsequently develop algorithms that will query the data to produce summaries of payment, utilization, and quality outcomes during the study year. These summaries will be used in our evaluation of the program.4
In the end, the goal of this text is not to make any real determinations about utilization, payments, and quality of care; after all, we are using fake data that cannot be used for drawing any real conclusions and exists solely to develop code.5 Rather, our goal is to prepare you for working on your own real world research projects by using our example research programming project to teach the mechanics of using Medicare data to measure utilization and Medicare payments, and to identify chronic conditions and commonly used indicators of quality outcomes. Therefore, by the end of this text, the reader will understand important concepts that are applicable and foundational to using Medicare administrative claims and enrollment data to, say, identify most any chronic condition or compute most any quality outcome metric.
We can now be more specific about the things we would like to measure. In particular, evaluating the success of the program involves coding the following measurements of utilization and payment for the beneficiaries in the pilot program we are studying. We need to:
• Calculate the number of evaluation and management (E&M) visits in a physician office setting, and the amount paid for those E&M services.
• Calculate measures of inpatient hospital utilization, and the amount paid for inpatient hospital claims.
• Calculate the utilization as it pertains to the professional component of emergency department (ED) visits.
• Calculate the utilization of ambulance services.
• Calculate the number of outpatient visits, as well as skilled nursing facilities (SNFs), home health agencies (HHAs), and hospice care.
• Calculate the total Medicare amount paid for all Part A claims for our population.
In addition, evaluating the success of the program also entails coding the following measurements of quality outcomes, often at the physician level:
• Measure evaluation and management utilization for beneficiaries with diabetes or chronic obstructive pulmonary disease (COPD).
• Identify the extent to which diabetics received services for eye exams.
• Calculate the number of hospital readmissions for beneficiaries with COPD.
• Finally, we will provide examples of methods to summarize and present results by beneficiary demographic characteristics, as well as by provider. While these examples are by no means exhaustive (e.g., we do not summarize and present every analysis performed in earlier chapters, we do not endeavor to analyze results using a control population, and we do not look for significant changes in performance over time), they do provide the reader with a foundation for further work.
The above concepts meet our criteria of being relevant, foundational, and adaptable. For example, instead of studying hospital admissions for Medicare beneficiaries with diabetes, you could study the same utilization and cost measurements for beneficiaries with prostate cancer. Similarly, you could adapt the measurement of retinal eye exams for diabetics to examine a different procedure (say, immunization for influenza) for beneficiaries with a different chronic condition (say, beneficiaries with prostate cancer or COPD).
Chapter Outline
Each chapter in this book will address a section of the project:
• Chapter 2 sets a foundation for using and understanding the data by learning about the Medicare program. Remember, the guiding principle of this book is that the only proper way to answer research questions about the Medicare program is by understanding the program that drives the data.
• Chapter 3 builds on the foundation developed in Chapter 2 by describing the content of Medicare data files in detail.
• Chapter 4 plans the project by describing the initiation, planning, and design phase of the Systems Development Life Cycle