Department of Health and Human Services 

OFFICE OF 

INSPECTOR GENERAL 

JANET REHNQUIST 

Inspector General 

FEBRUARY 2002 

OEI-07-01-00250 

Problems Pervade the Renal Beneficiary 

and Utilization System 
OFFICE OF INSPECTOR GENERAL 

The mission of the Office of Inspector General (OIG) mandated by Public Law 95-452, as amended 

by Public Law 100-504, is to protect the integrity of the Department of Health and Human Services 

programs as well as the health and welfare of beneficiaries served by them. This statutory mission is 

carried out through a nationwide program of audits, investigations, inspections, sanctions, and fraud 

alerts. The Inspector General informs the Secretary of program and management problems and 

recommends legislative, regulatory, and operational approaches to correct them. 

Office of Evaluation and Inspections 

The Office of Evaluation and Inspections (OEI) is one of several components of the Office of Inspector 

General. It conducts short-term management and program evaluations (called inspections) that focus 

on issues of concern to the Department, the Congress, and the public. The inspection reports provide 

findings and recommendations on the efficiency, vulnerability, and effectiveness of departmental 

programs. 

OEI's Kansas City office prepared this report under the direction of Brian T. Pattison, Regional 

Inspector General. Principal OEI staff included: 

Region Headquarters 

Madeline Carpinelli, Chicago, Program Analyst Bambi Straw, Program Specialist 

Brian T. Whitley, Kansas City, Program Analyst 

To obtain copies of this report, please call the Kansas City Regional Office at (816) 426-3697. 

Reports are also available on the World Wide Web at our home page address: 

http://oig.hhs.gov/oei/ 
EXECUTIVE SUMMARY 

PURPOSE 

To describe the state of the Renal Beneficiary and Utilization System and to evaluate how the 

system and resulting data are used. 

BACKGROUND 

End Stage Renal Disease (ESRD), characterized by a permanent loss of kidney function, is the 

only basis for entitlement to Medicare based on the presence of a specific medical diagnosis. 

The ESRD beneficiaries are entitled to full Medicare benefits as well as the services Congress 

specifically allows for these beneficiaries (e.g., dialysis, transplant procedures, selected 

pharmaceuticals, and nutrition supplies). At the end of 1999, the ESRD population in the 

United States had climbed to approximately 329,000, with Medicare expenditures of $11.3 

billion. In the next 10 years, the number of individuals with ESRD, as well as Medicare 

expenditures, is projected to double. 

The Centers for Medicare & Medicaid Services (CMS) is charged with the administration of 

the ESRD Program. Within CMS, the Information Systems Group manages the operation of 

the legislatively mandated system covering medical and demographic information for the 

Medicare ESRD population, the Renal Beneficiary and Utilization System (REBUS). 

The REBUS is intended to serve as a source of ESRD information, consolidated from various 

data providers. The main function of REBUS is to maintain data used in the determination of 

Medicare entitlement, including disenrollment, death, transplant, and dialysis treatment data. 

The REBUS also supports program analysis, policy development, program operations, and 

epidemiologic research. We were alerted to problems with REBUS when we experienced 

complications attempting to access data from the system for another inspection. Given the 

critical nature of the system, we examined the status of REBUS and evaluated the effects that 

data and communication problems have on data providers and end users. 

FINDINGS 

Datasets Within the Renal Beneficiary and Utilization System are Out-of-date, 

Incomplete, and Inaccurate 

Problems existed with 9 of the 12 REBUS datasets within the 12 months prior to the 

completion of our fieldwork (August 2001). Although CMS has taken steps to update some 

datasets, problems continue. The most common problem with REBUS datasets is that they are 

out-of-date, thus leading to incomplete and inaccurate data. 

Renal Beneficiary and Utilization System Review i OEI-07-01-00250 
Data Problems Result in Duplication of Effort, Delays, and Program Vulnerabilities 

Due to data problems with REBUS, some groups are requesting data already provided to 

CMS directly from the data providers. Representatives from the United States Renal Data 

System (USRDS) reported that their 2001 annual report, which presents national ESRD data, 

was delayed due to shortcomings in the REBUS data. Representatives from both CMS and 

the USRDS stated that when the dataset regarding Transplant Follow-up was not current, 

CMS did not have the information needed to terminate beneficiaries who had undergone 

successful transplants, thus resulting in an estimated 50,000 individuals continuing to receive 

Medicare benefits beyond their period of eligibility. In addition, incomplete Patient Status data 

has led to termination of ESRD benefits for beneficiaries enrolled in managed care plans. 

Data Problems are the Result of Historical Complications, a Lack of Resources, 

and an Outdated Database 

Data problems have plagued the ESRD Program since its inception in 1973. The CMS has 

reorganized several times, resulting in changes in the components responsible for operation and 

oversight of REBUS. During these reorganizations, key staff members were reassigned, 

including the two original architects of REBUS. In addition, the REBUS uses an outdated 

programming language, and there are few programmers who have the expertise to work with 

such a system. Due to its age and programming language, REBUS is incompatible with the 

modernized systems with which it is supposed to exchange data. 

Lack of Defined Roles and Relationships Leads to Poor Communication 

Representatives from the primary organizations providing data for or using data from REBUS 

(e.g., the ESRD Networks, United Network for Organ Sharing, and the United States Renal 

Data System) noted long standing communication problems with CMS. Representatives said 

that few meetings are held to discuss data quality issues. The CMS representatives agreed that 

communication with some groups may be lacking. 

RECOMMENDATIONS 

The CMS is well aware of problems within REBUS. The CMS has expended considerable 

effort maintaining and updating REBUS, and steps have been underway for some time to 

develop a replacement system. Considering the history of data problems with REBUS and the 

various delays that have stalled the implementation of the replacement system, we recommend 

that CMS: 

Develop a Strategic Plan for Addressing ESRD Data Management 

The strategic plan should build on CMS’s current efforts to address data shortcomings. At a 

minimum, the plan should address the following four areas: 

Renal Beneficiary and Utilization System Review ii OEI-07-01-00250 
< Short and Long-Term Targets 

The CMS’s strategic plan should address target dates for updating REBUS and restoring outof-date datasets. In addition, the plan should establish realistic target dates for the completion 

of the replacement system and the transfer of data from REBUS into this system. 

< Data Needs 

Problems with the timeliness, completeness, and accuracy of some datasets within REBUS 

raise questions as to the importance of these datasets to the operation of CMS’s ESRD 

program. The CMS should assess internal data needs and the needs of external data users to 

determine the appropriateness of CMS maintaining these data. 

< Efficiency of Data Distribution 

Within the constraints of the Privacy Act and other applicable laws and regulations, CMS 

should reassess where and how ESRD users obtain needed data. If CMS decides that it is 

most appropriate for end users to obtain data directly from the source, it should factor in this 

decision when determining which datasets should be retained. 

< On-going Communication 

The CMS should establish regular, periodic meetings to discuss ESRD data management issues 

with internal and external data providers and end users. 

Coordinate with the Social Security Administration to Address Errors in Basic 

Beneficiary Information 

According to CMS representatives, SSA has given low priority to correcting errors in ESRD 

beneficiary records. The CMS may want to consider holding high-level meetings with SSA to 

develop a mutually acceptable solution for addressing problems with basic beneficiary 

information. 

AGENCY COMMENTS 

In its written response to our report, CMS acknowledged limitations with REBUS and 

concurred with our recommendations. The CMS highlighted various actions taken since 

completion of our draft report, including devising short and long-term strategic plans, initiating 

meetings with data providers and users, and reaching agreements to reduce or eliminate nonessential data transfers. In addition, CMS is now encouraging various data users to seek 

information directly from the source rather than relying on CMS’s system. 

We made minor changes to reflect technical comments received from CMS. The full text of 

CMS’s comments are included in Appendix A. 

Renal Beneficiary and Utilization System Review iii OEI-07-01-00250 
TABLE OF CONTENTS 

PAGE

EXECUTIVE SUMMARY ...................................................... i

INTRODUCTION ............................................................. 1

FINDINGS 

Out-of-date, Incomplete, and Inaccurate Datasets ...................................... 8

Duplication of Effort, Delays, and Program Vulnerabilities ................................ 10

Historical Complications, Lack of Resources, and an Outdated Database .................... 11

Poor Communication ........................................................... 12

RECOMMENDATIONS ...................................................... 14

AGENCY COMMENTS ...................................................... 16

APPENDIX A ............................................................... 17
INTRODUCTION 

PURPOSE 

To describe the state of the Renal Beneficiary and Utilization System and to evaluate how the 

system and resulting data are used. 

BACKGROUND 

This inspection topic stems from complications faced while attempting to access data from the 

Renal Beneficiary and Utilization System (REBUS), the critical End Stage Renal Disease 

(ESRD) data system, for the planned inspection entitled “End Stage Renal Disease: Method 

Election Vulnerabilities.” Efforts to select a universe of beneficiaries for that inspection were 

compromised by problems encountered with a particular dataset within REBUS. Inquiries to 

the Centers for Medicare & Medicaid Services (CMS) revealed that some datasets in REBUS 

had not been updated in more than 2 years. Concerns about the entire data system developed 

as we were informed that data in other datasets may have been similarly out-of-date and 

incomplete. 

End Stage Renal Disease 

End Stage Renal Disease is characterized by a permanent and irreversible loss of kidney 

function requiring either kidney transplantation or regular dialysis treatments in order to survive. 

In 1972, amendments to Title XVIII of the Social Security Act extended Medicare Part A and 

Part B benefits to virtually all individuals with ESRD regardless of age.1 The ESRD program is 

the only Medicare program for which entitlement is based on the presence of a specific medical 

diagnosis. 

The ESRD beneficiaries are entitled to full Medicare benefits as well as services Congress 

specifically allows for these beneficiaries (e.g., dialysis, transplant procedures, selected 

pharmaceuticals, and nutrition supplies). In 1973, the year in which the program was initiated, 

the number of eligible ESRD beneficiaries totaled 10,000. By the end of 1999, the ESRD 

population in the United States had climbed to approximately 329,000, with Medicare 

expenditures of $11.3 billion.2 The number of individuals with ESRD is 

1 Individuals who suffer from ESRD and are under age 65 may experience a 3-month waiting period prior to 

Medicare coverage. In addition, individuals who have coverage under an Employer’s Group Health Plan may 

undergo a 30-month period in which Medicare acts as a secondary payer to the Group Health Plan. 

2 United States Renal Data System, retrieved from the World Wide Web: http://www.usrds.org/atlas.htm 

(August 30, 2001). 

Renal Beneficiary and Utilization System Review 1 OEI-07-01-00250 
projected to double by 2010, surpassing 660,000 individuals, with projected Medicare 

expenditures in excess of $28 billion.3 

The CMS is charged with the administration of Medicare benefits to eligible persons with 

ESRD. Integral to the effective administration and management of this program is the effective 

operation of REBUS, the comprehensive database covering medical and demographic 

information for the Medicare ESRD population. 

ESRD Information System 

In 1978, Public Law 95-292, section (c)(1)(A), mandated the Secretary of the Department of 

Health, Education and Welfare to establish a renal disease medical information system. This 

legislation stemmed from the need to calculate utilization rates and serve the administrative 

needs of the expanding program. The resulting system merged data from an existing patient 

dialysis registry, a transplant registry, and Medicare eligibility and claims data from the Social 

Security Administration (SSA). 

The technical design and operation of this data merger proved difficult. An agency report from 

the then Health Care Financing Administration noted that poor contract management, interoffice miscommunication, and staff turnover slowed the implementation of the system.4 After an 

internal reorganization, the ESRD program staff began publishing the first series of regular 

reports using the ESRD medical information system in mid-1979. The system was fully 

operational by July 1980. 

The Renal Beneficiary and Utilization System 

The REBUS is the interactive tool used to access data within the Program Management and 

Medical Information System, the actual repository for the ESRD program data. This repository 

contains data covering the medical and demographic information for the ESRD population. 

Both CMS and the end users of data commonly refer to both the tool and the repository as 

REBUS, as will we throughout this report. The main function of REBUS is to maintain data 

used in the determination of Medicare ESRD entitlement, including disenrollment, death, 

transplant, and dialysis treatment data. The REBUS also supports program analysis, policy 

development, program operations, and epidemiologic research. 

3 United States Renal Data System, retrieved from the World Wide Web: http://www.usrds.org/ 

atlas_2000.htm (August 30, 2001). 

4 “Implementing the End Stage Renal Program of Medicare,” Richard Rettig, R-2505 HCFA/HEW, September 

1980. 

Renal Beneficiary and Utilization System Review 2 OEI-07-01-00250 
The CMS describes REBUS as: 

. . . a mission critical system that is used by CMS and the renal community to 

perform their duties and responsibilities in monitoring the Medicare status, 

transplant activities, dialysis activities, and Medicare utilization (inpatient and 

physician-supplier bills) of ESRD patients and their Medicare providers, as well 

as in calculating the Medicare-covered period of ESRD. 

The REBUS data are used for payment decisions and actuarial projections, as well as serving 

the needs of the research and planning divisions within CMS, including the Center for 

Beneficiary Choices, the Office of Clinical Standards and Quality, The Center for Medicaid and 

State Operations, and the Office of Strategic Planning. 

REBUS Structure 

The REBUS is composed of twelve datasets. The information contained within those datasets 

is derived from data exchanges between groups as indicated below. The providers for this data 

are further described on the following page. 

Dataset Data Description Data Source 

Death Notice Date, place, and cause of death ESRD Networks 

Facility Certification Annual provider-specific treatment and transplant data ESRD Networks 

Identification Basic beneficiary, entitlement, and ESRD termination data Social Security Administration 

Inpatient Stay Hospital stay dates, provider number, surgery information National Claims History 

Medical Evidence Medical conditions, lab results ESRD Networks 

Method Selection ESRD payment method chosen by home dialysis patients Common Working File 

Patient Status Verified renal status, dialysis type, most recent treatment 

setting 

ESRD Networks 

Quarterly Dialysis Aggregated information for all dialysis claims in the quarter National Claims History 

SSA District Office Addresses of local Social Security Administration offices Social Security Administration 

Transplant Date of transplant; organ donor data United Network for Organ 

Sharing 

Transplant Follow-up Tracks the status of the beneficiaries transplant United Network for Organ 

Sharing 

Wait List Potential kidney transplant recipients awaiting transplantation United Network for Organ 

Sharing 

Source: CMS Data Users Guide 

Renal Beneficiary and Utilization System Review 3 OEI-07-01-00250 
Renal Beneficiary and Utilization System Review 4 OEI-07-01-00250

REBUS Data Exchanges and Usage

The REBUS data mostly are created and maintained in other systems, and then periodically

uploaded into REBUS. 

followed by descriptions of common users of REBUS. 

REBUS and the users of the resulting REBUS data are illustrated below in Diagram 1. 

discussion of the data sources and external data users follows the diagram.

Diagram 1: REBUS Data Providers and Users

Data Providers (Internal)

Enrollment Database -- This database contains information on all Medicare beneficiaries from

the beginning of the Medicare program in 1966 to the present.

Common Working File -- Fiscal intermediaries and carriers, which work under contract for

CMS, use the Common Working File to process claims. 

claims, helping to ensure proper claims processing. 

ensure that ESRD-related claims are supported by a diagnosis of ESRD for the beneficiary or

that the type of treatment being claimed corresponds with the method of treatment the

beneficiary selected.

National Claims History -- This file serves as a single repository for both Medicare Part A

and Part B claims, which would include 100 percent of ESRD claims. 

Below are descriptions of the various data providers for REBUS,

The primary sources of data for

A

The file contains edits to screen

These edits, for example, would help

The National 
Claims History contains every claim submitted since 1991 along with all adjustment claims. 

Data Providers (External) 

ESRD Networks -- In 1987, Congress mandated the formation of 18 ESRD Networks to 

assist in the collection and verification of patient, facility, and provider data. Dialysis treatment 

facilities complete required HCFA forms, including the HCFA-2728 Medical Evidence, 

HCFA-2746 Death Notification, and HCFA-2744 Annual Facility Survey. These forms are 

then forwarded to the regional Networks for data entry into the Standard Information 

Management System (SIMS), an electronic database implemented in January 2000. This 

system enables all 18 Networks to maintain uniform beneficiary and provider data from their 

respective regions, which are to be periodically uploaded into REBUS. 

Social Security Administration -- The primary source for beneficiary information in CMS’s 

Enrollment Database is SSA, which supplies information for updating the database daily. 

The United Network for Organ Sharing (UNOS) -- The UNOS maintains the nation’s organ 

transplant wait list under contract with the Health Resources and Services Administration 

(HRSA). This data is instrumental in developing organ transplantation policy as well as 

maintaining effective operation of the Organ Procurement and Transplantation Network. The 

Network maintains a national electronic list of patients waiting for organ transplantation and is 

responsible for matching donors and recipients. The UNOS sends their data to CMS, which is 

then loaded into REBUS. The data includes information regarding the donor and recipient, the 

date of the organ transplant, and routine follow-up information on the patient and transplanted 

kidney. 

Data Users (External) 

United States Renal Data System (USRDS) -- In 1986, Public Law 99-509 mandated the 

establishment of a national ESRD patient registry. This registry, the USRDS, formerly operated 

through the University of Michigan and currently operates through the Minneapolis Medical 

Research Foundation, University of Minnesota Twin Cities under contract with the National 

Institutes of Health. The USRDS relies on REBUS as its major source of data on the incidence 

and prevalence of kidney failure, the rates of hospitalization and transplantation, the rates and 

causes of death, and the costs of associated medical care. The USRDS distributes information 

to Congress, several Federal agencies, and the ESRD community through its annual reports. 

Independent Researchers -- The CMS creates Public Use Files used for independent and 

organizational research. The REBUS has been used in a number of ways, including basic 

descriptive epidemiology, analysis of mortality rates, and assessments of programmatic issues, 

such as reimbursement and clinical practice. 

Renal Beneficiary and Utilization System Review 5 OEI-07-01-00250 
University of Michigan Kidney Epidemiology and Cost Center (KECC) -- The Center uses 

data from REBUS to create facility specific reports for facilities, Networks, and state agencies. 

The Center also creates state specific reports which are used in program operations and 

oversight. 

Social Security Administration -- The SSA receives ESRD termination data from REBUS so 

that it can correctly terminate beneficiaries as their entitlement expires. 

The Renal Management Information System (REMIS) 

The CMS is developing a modernized information system to replace REBUS. The 

replacement, REMIS, is expected to improve system access and data quality because it will 

integrate better with updated systems of internal and external data providers. Plans for the 

development of REMIS were announced in December 1999, with the implementation date 

originally set for Spring 2000. Due to delays in the development of REMIS, the current target 

date is Spring 2002. 

Other ESRD Work by the Office of Inspector General 

The Office of Inspector General (OIG) has issued several ESRD-related studies. Most 

recently, the OIG released “External Quality Review of Dialysis Facilities: A Call for Greater 

Accountability,” OEI-01-99-00050, June 2000. The study found that CMS does not require a 

core set of facility-specific clinical performance measures, limiting its ability in identifying poorly 

performing facilities. The study also found deficiencies in lines of communication between the 

Networks and State agencies. 

In January 2001, the OIG issued “Review of Separately Billed End Stage Renal Disease 

Hospital Outpatient Laboratory Tests Included in the Composite Rate,” A-01-99-00506, a 

follow-up to the October 1996 report, “Review of Separately Billable ESRD Laboratory 

Tests,” A-01-96-00513. Both reports found that hospital laboratories were reimbursed 

separately for laboratory services already included in the dialysis facility’s composite rate. 

Based on a statistical sample, the 2001 report estimated that $6.1 million was improperly paid 

to hospital laboratories for services provided to ESRD beneficiaries during calendar years 1995 

through 1997. 

The OIG also released three reports focusing on the appropriateness of payments to Health 

Maintenance Organizations for ESRD-classified beneficiaries. In February 1996, the OIG 

issued “Review of Medicare Payments to Health Maintenance Organizations for End Stage 

Renal Disease Beneficiaries,” A-04-94-01090. Later the OIG released “End Stage Renal 

Disease Payments to Health Maintenance Organizations (HMOs),” A-14-9600203, June 

1997, and “Review of HMO Payments-Beneficiaries on Dialysis,” A-14-98-00211, July 2000. 

In each of these reports, the OIG found significant overpayments to HMOs for Medicare 

beneficiaries inappropriately identified as having ESRD due to the enhanced rate received for 

patients in that high-cost category. 

Renal Beneficiary and Utilization System Review 6 OEI-07-01-00250 
METHODOLOGY 

As previously stated, this inspection was an outgrowth of complications faced while attempting 

to access data from REBUS for a planned inspection. Based on the data problems we 

identified through our initial inquiry, we gathered additional information from key stakeholders, 

including the Information Systems Group within CMS’s Office of Clinical Standards and 

Quality, the ESRD Networks, UNOS, USRDS, and KECC. We were able to identify these 

key stakeholders through a CMS issued Data Users Guide which described each dataset of 

REBUS and how the information was exchanged between REBUS and stakeholders. 

Using structured discussion guides, we collected from the Information Systems Group 

information about the concept and design of REBUS, the causes of current and prior data 

problems, and the phase-in plans for REMIS. We collected from external data providers (e.g., 

UNOS) and data users (e.g., USRDS) their experiences working with REBUS and CMS, the 

challenges they faced accessing and/or submitting data to REBUS, the effect data and system 

problems have had on their operations, and the steps they have taken to overcome these 

problems. 

We analyzed all collected information, comparing the collective experiences of data providers, 

CMS, and data users, along with our own experiences. Our inspection focus was to assess the 

status of the individual REBUS datasets and how problems impact upon the data providers and 

users of the system. We did not test data within REBUS for completeness or accuracy 

because it was not our intent to assess the magnitude of problems so much as to assess the 

nature of the problems. 

We conducted follow-up interviews with CMS regarding the status of REBUS datasets and 

any plans for updating these datasets as a final step in our fieldwork. Therefore, all statements 

related to status and update plans are current as of August 2001. 

We conducted this inspection in accordance with the Quality Standards for Inspections 

issued by the President’s Council on Integrity and Efficiency. 

Renal Beneficiary and Utilization System Review 7 OEI-07-01-00250 
FINDINGS 

Datasets Within the Renal Beneficiary and Utilization System 

are Out-of-date, Incomplete, and Inaccurate 

Problems existed with 9 of the 12 REBUS datasets within the 12 months prior to our fieldwork 

completion (August 2001). The table below provides the status of all REBUS datasets as of 

August 2001, followed by discussions of problems with selected datasets.5 

Table 2: REBUS Dataset Status 

Dataset Description Status Plans for updating 

Death Notice Date, place, and cause of death Current N/A 

Facility Certification Annual provider-specific treatment 

and transplant data 

Current N/A 

Identification Basic beneficiary information, 

entitlement and ESRD termination 

data 

Not Current Dependent on other 

datasets 

Inpatient Stay Hospital stay dates, provider 

number, surgery information 

Not Current Up-to-date within 1 

month 

Medical Evidence Medical conditions, lab results Current N/A 

Method Selection ESRD payment method chosen by 

home dialysis patients 

Not Current Data needs to be 

uploaded 

Patient Status Verified status, dialysis type, most 

recent treatment setting 

Not Current Up-to-date within 3 

months 

Quarterly Dialysis Aggregated information for all 

dialysis claims in quarter 

Current 6 N/A 

SSA District Office Address of local SSA offices Not Current No plans to update 

Transplant Date of transplant, organ donor 

data 

Current6 N/A 

Transplant Follow-up Tracks status of beneficiary 

transplant 

Current6 N/A 

Wait List Potential kidney transplant 

recipients awaiting transplant 

Not Current Up-to-date within 3 

months 

5 The status of REBUS datasets as of December 21, 2001, as reported by CMS, is included in Appendix A. 

6 These datasets were out-of-date during the prior 12-month period. 

Renal Beneficiary and Utilization System Review 8 OEI-07-01-00250
The Method Selection dataset is more than 2 years out-of-date 

We found that the Method Selection dataset, which indicates the payment method and the 

source of dialysis supplies for home dialysis beneficiaries, was more than 2 years out-of-date at 

the time of this review. We initially identified problems with this dataset when we attempted to 

select a universe of beneficiaries for the “End Stage Renal Disease: Method Election 

Vulnerabilities” inspection. The CMS representatives reported that, although they have since 

collected the historical data needed to update the dataset, they have yet to upload the data to 

bring the dataset up-to-date. Therefore, in order to obtain the method selection data needed 

for the aforementioned inspection, we have requested data directly from the Common Working 

File, which supplies REBUS with this data. 

Systems incompatibility with the United Network for Organ Sharing has led to outof-date and incomplete transplant data in REBUS 

The three datasets pertaining to organ transplantation (Transplant, Transplant Follow-up, and 

Wait List) are further examples of datasets which are out-of-date, leading to incomplete data. 

In January 2000, UNOS changed both the layout within their database and the method they use 

to submit data. The CMS was unable to upload this reformatted data into REBUS, which led 

to the datasets becoming out-of-date. After rewriting the process of accepting the UNOS 

data, CMS has reported they are now posting data to the Transplant and Transplant Follow-up 

datasets in a timely manner; however, problems still remain with the Wait List dataset. Because 

Medicare beneficiaries with successful transplants are limited by law to 36 months of postoperative coverage, the data UNOS supplies are essential for determining continued Medicare 

eligibility for patients with transplants. 

Incomplete Patient Status data in REBUS may lead to termination of ESRD 

beneficiaries enrolled in managed care plans 

Representatives from the CMS regional offices alerted us to the potential of ESRD beneficiaries 

enrolled in managed care plans having their benefits inadvertently terminated because of 

incomplete data in the Patient Status dataset. The CMS relies on automated systems to 

determine the continued eligibility of ESRD beneficiaries. These systems rely on both claims 

activity (an estimated 15 percent of the Medicare ESRD beneficiaries are enrolled in managed 

care plans, meaning that these beneficiaries do not have individual dialysis claims filed for their 

treatments) and Patient Status data. The CMS formerly relied on the Networks’ bi-annual 

facility census to verify the status of patients. However, with the implementation of SIMS, the 

Networks no longer send this information. The REBUS is supposed to load the information 

continuously from SIMS, but the system is incompatible with SIMS and is unable to upload 

information directly. Therefore, patient status information in REBUS remains incomplete. 

Managed care beneficiaries run the risk of incorrect termination of benefits because CMS will 

terminate eligibility after 12 months of no claims activity and no update in Patient Status 

information. 

Renal Beneficiary and Utilization System Review 9 OEI-07-01-00250 
Basic patient information in the Identification dataset is inaccurate 

The Networks, CMS, and USRDS all acknowledged problems with data in the Identification 

dataset. Information for this dataset is uploaded daily into REBUS based on information 

received from SSA. The ESRD Networks also maintain beneficiary identification information 

derived from the facility and patient forms. For several years, the SSA and Network data have 

not matched. During this time, CMS generated reports of non-matching data and sent these to 

both SSA and the Networks for verification or correction, as appropriate. The CMS officials 

reported that they have held discussions with various components within SSA regarding data 

errors. In addition, the Networks have and continue to report that they find their information is 

correct. Because the information in the Identification dataset is overwritten nightly based on 

information received from the SSA Master Beneficiary Record, it is not possible to correct the 

information in the Identification dataset permanently unless the SSA corrects its data. The SSA 

acknowledges that data corrections are a low priority unless the data directly effects beneficiary 

benefits and so data problems remain unresolved. 

Data Problems Result in Duplication of Effort, Delays, and 

Program Vulnerabilities 

We found that problems with REBUS data have created complications for data users. For 

example, CMS requires the ESRD Networks to produce annual reports. Sections of these 

reports are based on transplant information. As previously stated, transplant data from UNOS 

was, for a time, not loaded into REBUS. The Networks had to request the information directly 

from UNOS to complete their annual reports, which resulted in UNOS producing the same 

data twice. In addition, UNOS representatives reported that such work results in additional 

charges to the HRSA-administered contract. 

The USRDS reported that its 2001 annual report was delayed due to shortcomings in the 

REBUS data. Representatives stated that some of the datasets they received had not been 

updated for some time. Because of outdated datasets, the USRDS had to obtain information, 

which should have been maintained in REBUS, from other sources to supplement the missing or 

incomplete data. 

Moreover, problems with specific datasets in REBUS have created program vulnerabilities. 

The CMS reported delays in updating the Transplant Follow-up dataset, which tracks ESRD 

Medicare beneficiaries after transplantation. Beneficiaries who have undergone a kidney 

transplant are eligible for Medicare benefits for a statutorily set period of 36 months. If the 

transplant is successful, coverage should be terminated after the 36-month period. 

Representatives from both CMS and USRDS estimate that past problems with updating the 

Transplant Follow-up dataset has allowed an estimated 50,000 individuals with successful 

transplants to continue receiving Medicare benefits beyond their period of eligibility. Now that 

the Transplant Follow-up dataset is current, CMS representatives report that ESRD 

beneficiaries with successful transplants are being terminated properly. (The CMS 

Renal Beneficiary and Utilization System Review 10 OEI-07-01-00250 
representatives stated that their plans are to retroactively adjust all individuals no longer entitled 

to Medicare due to successful transplants coverage, but not to collect any lost funds.) 

Data Problems are the Result of Historical Complications, a 

Lack of Resources, and an Outdated Database 

Data problems have plagued the ESRD Program since its inception in 1973. As previously 

stated, CMS experienced problems in the development of the original ESRD data system. 

While REBUS has centralized much of the data, many of the earlier identified problems remain. 

For example, in a report to the Secretary of Health, Education and Welfare in 1980, the history 

of the original ESRD system is described: 

. . . at no time in the design, development, or operation of the system was sustained, 

informed policy direction given to the system. Consequently, issues of feasibility, need, 

and cost either went unanalyzed or were poorly investigated. [There was no] sufficient 

authority or power to give policy leadership . . . furthermore, familiar problems of the 

existing Medicare system nourished a belief that a new system could be created which 

would avoid these problems and that awarding an external contract was the means to 

this end.7 

Although this is a description of the complications faced from 1973 to 1979, many of the 

problems are similar to those CMS currently experiences. The plan for the transfer to REMIS 

was first announced in the “Information Technology Architecture Sketches” newsletter in July 

1999, with plans for implementation by Spring 2000. Two years later, the transfer still has not 

occurred. 

The CMS cited various reasons for this delay. In 1997, CMS undertook an agency-wide 

reorganization, which resulted in the operation and oversight of REBUS moving from the Office 

of Information Systems to the Office of Clinical Standards and Quality. In this move, several 

crucial staff members were reassigned, including the two original architects of REBUS. Since 

this time, there have been numerous staffing changes, with new members frequently lacking 

experience in the ESRD program. Continuous staffing turnover and general lack of expertise 

have contributed to data problems. 

The CMS has made efforts to address some of these shortcomings. The agency has re-hired 

one of the original architects of REBUS and has contracted with a private company to develop 

REMIS. 

7 “Implementing the End Stage Renal Program of Medicare,” Richard Rettig, R-2505-HCFA/HEW, 

September 1980. 

Renal Beneficiary and Utilization System Review 11 OEI-07-01-00250 
Obsolete technology renders REBUS incompatible with other systems and makes 

the system difficult to maintain 

The REBUS was created in 1980 to run as a mainframe application. Now, more than 20 years 

later, individuals with whom we spoke noted problems with the age of the system, its 

incompatibility with other systems, and the difficulty of finding programmers who know the 

programming language used to create the system. Each of these hinders CMS’s ability to keep 

data within the system up-to-date. 

The CMS has had to take special steps to allow data to be updated from several sources. 

Staff reported the three datasets they have been able to fix (Quarterly Dialysis, Transplant, and 

Transplant Follow-up) have all taken extra effort, such as rewriting the program and manual 

uploading. Staff also stated that the remaining five datasets plan to be up-to-date by the end of 

calendar year 2001. It is unclear, given competing priorities, if CMS will meet these target 

dates. 

Lack of Defined Roles and Relationships Leads to Poor 

Communication 

Despite CMS’s reliance on external providers for REBUS data, representatives from each of 

the external groups with whom we spoke cited long standing communication problems with 

CMS. For example, even though UNOS is a major supplier of data and USRDS is a major 

user of REBUS data, there are no formalized communications between these two groups with 

CMS. The CMS representatives reported the occurrence of infrequent meetings to discuss 

data quality issues with UNOS or USRDS, but stated the reason for no formal communications 

with either organization is because they are under contract with HRSA and the National 

Institutes of Health, respectively, making regularly scheduled meetings inappropriate. 

The lack of communication with CMS has frustrated representatives of UNOS and USRDS. 

The UNOS representatives reported the inability of CMS to load their transplant and wait list 

data into REBUS. The UNOS representatives believed regular communications could have 

prevented many of these problems. Representatives from the USRDS expressed frustration 

with learning that CMS knew of data problems, but did not share them with data users. The 

USRDS representatives said that they made efforts to verify the accuracy of data, and, after 

identifying the problems, contacted CMS only to learn that CMS was already aware of the 

problems. 

Networks also noted communication problems and stated their desire for more formalized 

contact with CMS. Although CMS representatives reported that they hold quarterly 

conference calls and that individual Networks are welcome to participate, Network 

representatives seemed unaware of these calls. The Networks are looking for a forum to 

express their concerns with their role. For example, CMS is in the testing phase of this new 

data system, the Vital Information System to Improve Outcomes in Nephrology or VISION. 

This system will allow facilities to electronically submit all facility and patient 

Renal Beneficiary and Utilization System Review 12 OEI-07-01-00250 
information, thus replacing the need for the Networks’ to enter the data from the paper forms. 

Although CMS sees this as a way of streamlining the data entry process, Networks 

representatives with whom we spoke believe VISION will replace their role of editing and 

reconciling the data. 

Staff within the CMS acknowledged the validity of the Networks’ complaints regarding 

communication, and stated that the group is working to improve communication. The CMS 

representatives reported they are in the process of assembling several workgroups with 

representatives from CMS, both headquarters and regional offices, and the ESRD Networks to 

encourage communication. The workgroups are being formed to “address current ESRD 

concerns and functionality of the Standard Information Management System software 

application” and to “. . . improve communication between CMS and the Networks regarding 

reporting requirements and clarification of policy issues.” 

Renal Beneficiary and Utilization System Review 13 OEI-07-01-00250 
RECOMMENDATIONS 

The CMS is well aware of problems within REBUS. The CMS has expended considerable 

effort maintaining and updating REBUS, and steps have been underway for some time to 

develop a replacement system (REMIS). Nevertheless, considering the history of data 

problems with REBUS and the various delays that have stalled the implementation of REMIS, 

we recommend that CMS: 

Develop a Strategic Plan for Addressing ESRD Data 

Management 

The strategic plan should build on CMS’s current efforts to address data shortcomings. At a 

minimum, the plan should address the following four areas: 

< Short and Long-Term Targets 

Data providers and end users are currently experiencing problems with REBUS. The CMS’s 

strategic plan should address target dates for updating REBUS and restoring out-of-date 

datasets. In addition, the plan should establish realistic target dates for the completion of 

REMIS and the transfer of data from REBUS into REMIS. This plan should be communicated 

to both data providers and end users for use in their planning. 

< Data Needs 

Although CMS describes REBUS as “ . . . a mission critical system . . . ” problems with the 

timeliness, completeness, and accuracy of some datasets within REBUS raise questions as to 

the importance of these datasets to the operation of CMS’s ESRD program. The CMS should 

assess internal data needs and the needs of external data users to determine the appropriateness 

of CMS maintaining these datasets, whether in REBUS or in REMIS. 

< Efficiency of Data Distribution 

Within the constraints of the Privacy Act and other applicable laws and regulations, CMS 

should reassess where and how ESRD data users obtain needed data End users have 

expressed a preference for receiving data directly from the source, largely because of problems 

with REBUS. If CMS decides that it is most appropriate for end users to obtain data directly 

from the source, it should factor this decision when determining which datasets should be 

maintained within REBUS and/or REMIS. The CMS also should work with end users to 

develop the most efficient methods for obtaining data from the providers. These efforts should 

improve overall efficiency and reduce duplication of effort and increased costs. 

Renal Beneficiary and Utilization System Review 14 OEI-07-01-00250 
< On-going Communication 

All groups who interact with REBUS suggested they would benefit from improved 

communication with CMS, and CMS has agreed. The CMS should establish regular, periodic 

meetings to discuss ESRD data management issues with internal and external data providers 

and end users. 

Coordinate with the Social Security Administration to Address 

Errors in Basic Beneficiary Information 

Efforts to correct errors in the Identification dataset are not effective as information within this 

dataset is overwritten nightly using information received from SSA. The SSA data will 

overwrite any corrections made to the dataset. According to CMS representatives, SSA has 

given low priority to correcting errors in ESRD beneficiary records. The CMS may want to 

consider holding high-level meetings with SSA to develop a mutually acceptable solution for 

addressing problems with basic beneficiary information. 

Renal Beneficiary and Utilization System Review 15 OEI-07-01-00250 
AGENCY COMMENTS 

In its written response to our report, CMS acknowledged limitations with REBUS and 

concurred with our recommendations. The CMS highlighted various actions taken since 

completion of our draft report, including devising short and long-term strategic plans, initiating 

meetings with data providers and users, and reaching agreements to reduce or eliminate nonessential data transfers. In addition, CMS is now encouraging various data users to seek 

information directly from the source rather than relying on CMS’s system. 

We made minor changes to reflect technical comments received from CMS. The full text of 

CMS’s comments are included in Appendix A. 

Renal Beneficiary and Utilization System Review 16 OEI-07-01-00250 
APPENDIX A 

DEPARTMENT OF HEALTH & HUMAN SERVICES Centers for Medicare & Medicaid 

Services 

Administrator 

Washington, DC 20201 

DATE: DEC 21 2001 

TO: Janet Rehnquist 

Inspector General 

FROM: Thomas A. Scully 

Administrator 

SUBJECT: Office of Inspector General (OIG) Draft Report: Problems Pervade the Renal 

Beneficiary and Utilization System (REBUS) (OEI-07-01-00250) 

Thank you for the opportunity to review and comment on the above-referenced draft report, 

which examines problems resulting in duplication of effort, delays, and program vulnerabilities 

in end-stage renal disease (ESRD) data management. The Centers for Medicare & Medicaid 

Services (CMS) acknowledges the many limitations of the existing REBUS operational 

environment. We have expended considerable resources to address these shortcomings and have 

developed a short- and long-term strategy to correct these problems. We are confident that our 

efforts have made considerable progress since your work on this OIG draft report was 

completed. We will continue in our efforts to keep REBUS current and accurate as we redesign 

ESRD systems to better meet our business challenges. 

We appreciate the effort that went into this report and the opportunity to comment on the issues 

it raises. Our detailed comments on the OIG recommendations follow. 

OIG Recommendation 

The CMS should develop a strategic plan for addressing ESRD data management. The strategic 

plan should build on CMS' s current efforts to address data shortcomings. At a minimum, the 

plan should address the following four areas: 1) short- and long-term targets; 2) data needs; 3) 

efficiency of data distribution; and 4) ongoing communication. 

CMS Response 

Short- and Long- Term Targets 

The CMS understands the need for a strategic plan to address the shortcomings outlined in the 

above-referenced report and has begun the development of this plan. As part of the plan, CMS 

will adopt an integrated approach to ESRD systems development. Currently, the REBUS and 

Standard Information Management System (SIMS) are independent, stand alone data repositories 

that communicate with each other via a complicated file exchange. Phase I of the Renal 

Management Information System (REMIS) redesign will concentrate on integrating these 

Renal Beneficiary and Utilization System Review 17 OEI-07-01-00250 
Page 2 -Janet Rehnquist 

systems. A detailed validation of the current REBUS and SIMS is currently underway. In Phase 

I, CMS will cleanse the current REBUS and SIMS data and integrate these data into one 

common ESRD data repository (warehouse). We are also implementing the Vital Information System for

Improved Outcomes in Nephrology (VISION) as a standard, front-end forms 

collection tool for ESRD dialysis centers as part of our Phase I effort. VISION will greatly 

improve the quality of our ESRD data warehouse. Phase I of the REMIS redesign is scheduled 

for completion in July 2002. Phase II will commence in the fall of 2002 and will concentrate on

identification of existing and new requirements. These additional user requirements will be incorporated

into logical quarterly releases of VISION/SIMS/REMIS software. Strict 

configuration management, testing procedures, and protocols will be used in this new operational paradigm

to ensure integrity of data and software. 

Data Needs and Improved Efficiency of Data Distribution 

The CMS is addressing its internal data needs for the ESRD program, as well as the needs of 

external customers for ESRD data,as part of its integrated ESRD systems effort. This effort 

encompasses the following: 

Improved Techniques for Data Transmission and Receipt 

As recently as October 2000, obsolete technology affected essentially all of the processes that supplied

REBUS with data essential to its business purpose. Even in cases where improved technology was

available to the data source organizations, REBUS accepted data only in the 

modes and formats used when REBUS was developed. Since November 2000, REBUS/REMIS

developers have been working toward methods requiring less workpower. 

Patient Status Information 

In November 2001, REBUS began drawing information from the ESRD networks' SIMS, whose central

server is located in CMS headquarters. (Previously, the ESRD networks had been 

required to extract information from the PC-based SIMS system and prepare 18 separate 

sequential datasets on the CMS mainframe.) 

Transplant Information 

Also in November 2001, the data prepared by the United Network for Organ Sharing (UNOS) 

for use in REBUS have drastically reduced in volume, in frequency, and in workpower required 

for processing. Additional improvements are planned for Phase II of REMIS. 

Consultation with Users of REBUS/REMIS Data 

See Ongoing Communication below. REBUS/REMIS system representatives attend ongoing meetings 

focusing on the data needs of customers. REBUS/REMIS managers will present information on the 

integrated ESRD system effort to these audiences. 

Renal Beneficiary and Utilization System Review 18 OEI-07-01-00250 
Page 3 -Janet Rehnquist 

Consultation with Providers of Data 

REBUS/REMIS is "fed" by transplant and dialysis data from CMS's systems, current ESRD 

patient status data from SIMS, and transplant data from UNOS. 

The CMS initiated regular monthly coordination meetings with UNOS and the Health Resources 

and Services Administration's (HRSA) representatives on November 7. That first conference achieved 

several agreements: 

C The UNOS may discontinue weekly files for CMS -- monthly files suffice for CMS's needs. 

C The CMS does not need non-ESRD data from UNOS. 

C The CMS will not house UNOS's data to meet United States Renal Data System's (USRDS) 

needs. (USRDS will be encouraged to "go to the source" of the data; HRSA 

C has no objection to this approach.) 

C Pending consultation with the ESRD networks, CMS will no longer house transplant wait list 

data, since the networks can obtain them from UNOS (and many of them have done so). The 

networks will be encouraged to "go to the source" of the data. 

C After confirming specifications, CMS will reinstate REBUS reports that provide information 

requested by UNOS (including information on transplant providers, deaths, and transplants not 

recorded by UNOS). 

The CMS has met regularly with SIMS developers and stakeholders since the start of the SIMS

development effort (frequently through teleconferencing). In recent months, as part of the 

integrated ESRD systems effort, in-person meetings have been held to: 

C plan the integration of SIMS data into REMIS; and 

C plan the integration of the VISION system with REMIS and SIMS. 

The integrated ESRD systems effort will result in the use of SIMS data as the "gold standard" for

current ESRD patient status. 

Timeliness, Completion, and Accuracy 

Each dataset used by REBUS is under evaluation as part of the migration to REMIS. This 

evaluation process, known as Data Quality Assurance (DQA), assesses each field within each REBUS

dataset for compliance with the documented standards ("metadata," roughly speaking) 

for that field. While there are no plans to add new functionality to REBUS, the DQA findings identify

REBUS data that are no longer usable and help determine the appropriateness of maintaining datasets

or their individual fields in REBUS/REMIS. This approach allows CMS to focus more narrowly on

information essential to the REBUS/REMIS business purpose. 

Renal Beneficiary and Utilization System Review 19 OEI-07-01-00250 
Page 4 -Janet Rehnquist 

Phased Approach 

Under the integrated ESRD systems effort, REBUS functionality will be transferred to REMIS. 

Phase I of REMIS calls for the new Oracle-based system to "do what REBUS does" with certain 

exceptions: 1) any processing errors found will be corrected; 2) any unnecessary data or 

functionality will be dropped; and 3) the existing multi-platform feed of patient status 

information from SIMS to REBUS will be replaced by read access to SIMS tables by REMIS. 

(Acquisition activities to strengthen the SIMS hardware platform have been initiated.) The 

resulting system will conform to applicable CMS standards and reasonable expectations for 

modem database application systems. 

Phase II will see a more thorough analysis of data needs, with the expectation of efficiency, 

timeliness, reporting, and reliability improvements. For example, Phase I of REMIS is expected 

to use essentially the same UNOS data as REBUS uses (although unnecessary elements will be 

dropped as a result of narrowing the focus of REBUS /REMIS to essential data). However, in 

Phase II, the use of UNOS data in REMIS will be fully reviewed. It is anticipated that the 

current process (receipt of compact discs (CDs) containing full-file copies prepared by UNOS; 

loading of data from CD to mainframe; unzipping of data on mainframe; use of mainframe 

Statistical Analysis Software to prepare inputs to REBUS; adding records to the REBUS Model 

204 database files via FASTLOAD) will be replaced by a more efficient process, possibly 

involving selection of only the required data by code executing on the UNOS platform. 

As part of the current REMIS phases, ESRD facilities will be able to use VISION to transmit 

forms electronically to CMS. Information transmitted via VISION will become part of the SIMS 

database. The SIMS data will in turn be treated as a part of REMIS; i.e., SIMS patient data will 

not be copied into REMIS, but will be read from SIMS. 

Additional activities have been instituted to make the current REBUS system more current 

and accurate during the transition to the new REMIS environment. 

The OIG report states that, “Data sets within the Renal Beneficiary and Utilization System are 

out-of-date, incomplete, and inaccurate” and that “problems existed with 9 of the 12 REBUS 

datasets in the past 12 months.” That statement is somewhat misleading. Two of those datasets, 

the Social Security Administration's (SSA) district office file and the waitlist file, in no way 

impact the REBUS business function. As a result of our review of the appropriateness of 

maintaining the various data stores in REMIS, we have determined not to maintain these two. 

We are testing new matching and analysis routines in order to better take advantage of the event 

data in SIMS and more accurately update the patient status records in REBUS. We will be 

loading data directly from the SIMS central repository on a regular basis. These improvements 

were implemented in early December 2001. We are working closely with the networks to 

improve the feedback that we give to them as a result of these regular census updates. We will 

also soon be pulling the monthly medical evidence and death notice accretions directly from 

the SIMS central repository, rather than have each network transmit those files to the CMS 

mainframe. 

Renal Beneficiary and Utilization System Review 20 OEI-07-01-00250 
Page 5 -Janet Rehnquist 

The table below shows the current status of REBUS datasets and is an update to the same table on

page 8 of the OIG draft report. 

Table 2: REBUS Dataset Status 

Dataset Description Status Plans for updating 

Death Notice Date, place, and cause of death Current N/A 

Facility Certification Annual provider-specific treatment Current N/A 

and transplant data 

Identification Basic beneficiary information, 99.9 Percent Dependent on other 

entitlement, and ESRD termination Current datasets 

data 

Inpatient Stay Hospital stay dates, provider Current N/A 

number, surgery information 

Medical Evidence Medical conditions, lab results Current N/A 

Method Selection ESRD payment method chosen by Current N/A 

home dialysis patients 

Patient Status Verified status, dialysis type, most Current N/A 

recent treatment setting 

SSA District Office Address of local SSA offices Not Current No plans to maintain/no 

longer review 

Transplant Date of transplant, organ donor data Current N/A 

Transplant Follow-up Tracks status of beneficiary 

transplant 

Current N/A 

Quarterly Dialysis Aggregated information for all Current N/ A 

dialysis claims in quarter 

Wait List Potential kidney transplant Not Current No plans to maintain/no 

recipients awaiting transplant longer review 

Ongoing Communication 

The CMS ESRD software development staff currently communicates with several of its data users and 

partners in a variety of ways. 

Annual Managed Care Enrollment and Payment Conference 

The Annual Managed Care Enrollment and Payment Conference serves to assist the managed care 

contractors in their understanding of CMS' s regulations, policies, and program developments that 

affect the operation of managed care enrollment and payment processes. 

Renal Beneficiary and Utilization System Review 21 OEI-07-01-00250 
Page 6 -Janet Rehnquist 

The ESRD and other similar workshops are conducted to enhance communication and address 

concerns of managed care organizations regarding ESRD data validation processes. 

SIMS/REMIS Task Groups 

The CMS has created a new task group structure, comprised of CMS and network staff, in order to 

address current ESRD concerns and functionality of the SIMS and REMIS software applications. This 

structure will improve communication between CMS and the networks regarding reporting 

requirements and clarification of policy issues. The SIMS/REMIS task groups will consist of a body of 

individuals tasked to perform set functions such as identifying a need, specifying the functionality needed 

in SIMS and REMIS, and finally testing each new process to ensure it works properly and meets all 

required needs. The groups will have a co-chair from CMS and a co-chair from the ESRD networks. 

The CMS believes it essential that the task groups be populated with network and CMS staff who are 

knowledgeable about the topic and who can commit the time necessary to do the work. 

WebEx Meeting Center 

To facilitate communication between application developers, task groups, and CMS staff, a new

technology called WebEx Meeting Center will be utilized. WebEx is a service that enables the easy

sharing of information on the Internet (i.e., the Web) through interactive online meetings. 

Through WebEx the user can: 

C Give any presentation to anyone, anywhere; 

C Demonstrate software, live; 

C Allow anyone in the meeting to view, annotate, and edit any document electronically; .

C Share an application on your system or share the entire desktop;

C Use remote control to provide support on the Web; 

C Take meeting participants on a Web tour; 

C Integrate teleconferencing into your meeting; and 

C Add video to personalize your meeting. 

Workgroups can collaborate on any project, at any time, from anywhere; e.g., from sharing

presentations to sharing any type of document, to Web tours, to full application and desktop remote

control, and provide all the capabilities necessary to support real-time meetings on the Web.

OIG Recommendation 

The CMS should coordinate with SSA to address errors in basic beneficiary information. 

Renal Beneficiary and Utilization System Review 22 OEI-07-01-00250 
Page 7 -Janet Rehnquist 

CMS Response 

CMS has worked diligently with SSA to try and resolve disagreements between our databases. More 

work needs to be done on this and we will continue to work with SSA to resolve these issues. 

The first is that identification data on the SSA Numerical Identification (NUMIDENT) record may 

disagree with data on the SSA Master Beneficiary Record (MBR) that updates the CMS Enrollment 

Database (EDB). The second is that SSA may have documentation that contradicts information that 

providers of CMS data (the ESRD networks) insist is correct. Below follows a brief history. 

In 1995, when REBUS was designed, a mechanism was created to enter discrepant patient identifier 

records (name, claim number, date of birth, and sex) in REBUS. The CMS would generate a list on 

an as-needed basis and forward it to SSA for investigation and correction. In 1996, we realized the 

data that were forwarded to SSA for update were not being changed. The CMS contacted the Office 

of Disability, SSA, and was told the list may be forwarded to the SSA field offices for resolution. The 

CMS again contacted SSA concerning the outstanding data correction requests. The CMS was 

informed that its request would be transferred to an area responsible for data corrections. In 1997, 

SSA notified CMS that it reviewed the lists and found written documentation which confirmed that the 

SSA record showed the correct date of birth, which was different from what the beneficiary reported 

to the network. According to SSA, its NUMIDENT file confirms the beneficiary's name and date of 

birth. The CMS has noted data discrepancies between the NUMIDENT and SSA's MBR, which 

updates CMS's EDB. In these instances and with surname changes, SSA suggested that the 

beneficiary contact his or her local SSA field office. The SSA also noted that data corrections are a 

low workload priority unless these changes have a direct effect on the beneficiary's benefits. The 

SSA's average workload backlog is 6 months. 

In addition to the above-described situation, we have also been attempting for the past year to 

coordinate with SSA regarding the VISION project and our ability to send, and SSA's willingness to 

receive, electronic ESRD form data in place of the paper forms it receives today. As with the errors, 

we have been unsuccessful in obtaining SSA's firm commitment to receive data electronically. 

In our discussions with OIG during the exit conference held for discussing this draft report, we strongly 

suggested that OIG include more detail regarding our efforts with SSA, which we again reiterate. We 

also suggest that this report in final form be sent to SSA. 

Again, we appreciate the effort that went into this report and the opportunity to review and comment 

on the issues it raises. 

Renal Beneficiary and Utilization System Review 23 OEI-07-01-00250