Contract No.: FNS-53-3198-7-025

MPR Reference No.: 8611-700

OPTIONS FOR A

NATIONAL DATABASE TO

TRACK PARTICIPATION IN

FEDERAL MEANS-TESTED

PUBLIC ASSISTANCE

PROGRAMS: REPORT TO

CONGRESS

November 1999

Myles Maxfield

 James Ohls

William S. Borden

Submitted to:

USDA, Food and Nutrition Service

Office of Analysis, Nutrition and Evaluation

3101 Park Center Drive

Alexandria, VA 22302

Project Officer:

Sharron Cristofar

Submitted by:

Mathematica Policy Research, Inc.

600 Maryland Avenue, Suite 550

Washington, DC 20024

(202) 484-9220

Project Director:

Myles Maxfield
ii

PAGE IS INTENTIONALLY LEFT BLANK TO ALLOW FOR DOUBLE-SIDED COPYING
iii

ACKNOWLEDGMENTS

The authors would like to acknowledge the substantial contributions of Sharron Cristofar and Ed

Speshock of the Food and Nutrition Service, U.S. Department of Agriculture, as well as those of Ram

Krishnamoorthi of Mathematica. Daryl Hall edited the manuscript, and Melanie Lynch prepared the

manuscript. All errors and omissions are the responsibilities of the authors.
iv

PAGE IS INTENTIONALLY LEFT BLANK TO ALLOW FOR DOUBLE-SIDED COPYING
v

CONTENTS

Chapter Page

EXECUTIVE SUMMARY.......................................................................................... xi

I INTRODUCTION....................................................................................................................... 1

Background Information and Policy Context ................................................................... 2

Cross State Computer Matching Activity........................................................................... 5

Data Sources and Limitations .............................................................................................. 6

Plan of the Report.................................................................................................................. 8

II THE DHHS REPORT.............................................................................................................. 9

State Capabilities..................................................................................................................... 9

Functional Requirements.................................................................................................... 10

Alternative System Architectures....................................................................................... 10

Other Issues Considered by DHHS ................................................................................ 12

Developments Since the DHHS Report.......................................................................... 12

III FUNCTIONAL REQUIREMENTS AND TECHNICAL FEASIBILITY ................................. 15

Conceptual Framework for a National Database............................................................ 15

How a National Client Database Would Work ............................................................... 16

Central Facility ...................................................................................................................... 19

States Technical Capabilities............................................................................................... 20

Data Availability.................................................................................................................... 22

Feasibility of Each Architecture......................................................................................... 22

IV COST-EFFECTIVENESS ......................................................................................................... 27

Scope and Basic Assumptions............................................................................................ 27

Analysis 29

System Architecture............................................................................................ 34

Sensitivity of the Results to Key Assumptions...................................................... 35

Findings ................................................................................................................................ 36
vi

CONTENTS (continued)

Chapter Page

V SAFEGUARDS TO PROTECT AGAINST UNAUTHORIZED DISCLOSURE

OR UNINTENDED USE OF NATIONAL DATABASE............................................................ 37

VI CONCLUSIONS ....................................................................................................................... 41

Key Findings......................................................................................................................... 41

Future Directions................................................................................................................. 44

REFERENCES....................................................................................................... 47

APPENDICES

A: CURRENT INTERSTATE MATCHING FOR DUPLICATE ...................................A-1

PARTICIPATION

B: SELECTION OF STATES FOR INTERVIEWS ABOUT

STATE CAPABILITIES..........................................................................................B-1

C: NATIONAL CLIENT DATABASE ARCHITECTURES 

PROPOSED IN THE DHHS REPORT.................................................................C-1

D: OTHER NATIONAL DATABASES......................................................................D-1

E: DETAILED ASSUMPTIONS FOR THE COST AND BENEFIT ESTIMATES

OF A NATIONAL CLIENT DATABASE ...............................................................E-1

F: STATE AND FEDERAL PRIVACY LAWS ............................................................. F-1
vii

TABLES

 Table Page

III.1 ASSESSMENT OF FEASIBILITY OF ALTERNATIVE ARCHITECTURES........................... 23

IV.1 PROJECTED COSTS AND BENEFITS OF A TRACKING SYSTEM .................................. 30

IV.2 PROJECTED COSTS AND BENEFITS OF A TRACKING SYSTEM ................................... 31

A.1 CURRENT INTERSTATE MATCHING FOR DUPLICATE PARTICIPATION.................... A-1
viii

PAGE IS INTENTIONALLY LEFT BLANK TO ALLOW FOR DOUBLE-SIDED COPYING
ix

FIGURES

 Figure Page

III.1 RELATIONSHIP BETWEEN FUNCTIONAL REQUIREMENTS AND

TECHNICAL FEASIBILITY...................................................................................................... 16

III.2 ACTIVITIES IN THE NATIONAL CLIENT DATABASE ......................................................... 18
x

PAGE IS INTENTIONALLY LEFT BLANK TO ALLOW FOR DOUBLE-SIDED COPYING
xi

EXECUTIVE SUMMARY

This report responds to P.L. 105-379, which mandated the U.S. Department of Agriculture to

examine options for the design, development, implementation and operation of a national database to

track participation in federal means-tested public assistance programs. Such a database would:

ß Identify interstate duplicate cases, that is, individuals receiving program benefits in two or more

States at the same time,

ß Help track the time limits required by the Personal Responsibility and Work Opportunity

Reconciliation Act of 1996 (PRWORA) across State boundaries. The time limits restrict the

amount of time certain clients of the Food Stamp Program (FSP) and Temporary Assistance

to Needy Families (TANF) can receive benefits.

Duplicate participation is a concern across all means-tested programs. However, because the FSP

and TANF programs are the only two means-tested programs that require tracking of time limits, they

pose the critical test of the feasibility of a national database. Therefore, in this report we focus on the

FSP and TANF programs. If a system for FSP and TANF is feasible and cost-effective, then adding

other means-tested programs (such as Medicaid) is unlikely to significantly decrease cost-effectiveness

(and may increase it).

The current study builds on existing information about the feasibility of a national database, the

most important of which is a study conducted by the U.S. Department of Health and Human Services

(DHHS) in 1997, hereafter called the DHHS report. The current study also draws on several additional

sources of data, including a survey conducted by the U.S. Department of Agriculture (USDA) of State

FSP agency data processing capabilities in 1991, ongoing monitoring by USDA of interstate computer

matching programs, in-depth interviews with officials in seven selected State FSP agencies, and

interviews with representatives of four on-going national matching systems with functions similar to

those of the national client database.

The major contribution of the DHHS report was to identify five alternative system architectures

for a national client database. The national client database could be developed using any one of the five

architectures. The functionality, feasibility, and cost-effectiveness of the national client database depend

on which architecture is used. The five architectures are:
xii

C File Match. At the end of each time period such as a month or a quarter, each State

sends a file of current recipients, represented by their social security numbers (SSNs) and

name, to the national client database. Software associated with the central database

compares each case to every other case in every other State searching for duplicate cases.

 If a recipient is found in more than one State, the central facility sends the SSN and name

of the duplicate case to both State agencies. The national client database does not

accumulate historical data on program participation, nor does it send data other than SSN

and name to the two State agencies.

C Broadcast. Each State agency periodically transmits a file containing the SSNs and names

of its active cases to every other State agency. There is no centralized national client

database, and the central facility provides no data to State agencies. The task of identifying

duplicate cases is left to State agencies.

C Eligibility Index. This architecture is similar to the file match architecture, except that

each State agency sends SSNs and names of new applicants and recertifications to the

central facility at any time, and SSNs and names are retained in the national client database

so that historical data on program participation is accumulated.

C Eligibility Database. This is similar to the eligibility index option, except that the State

agency transmits an extract of each case record, rather than just the SSN and name, to the

national client database. The central facility identifies interstate duplicate cases, and sends

the case record extract from both State agencies to each of the two State agencies. The

national client database accumulates historical data on program participation. Thus, the

central client database sends sufficient data to State agencies for them to minimize the

amount of data they need to retrieve directly from other State agencies.

C One-Stop Database. This is similar to the eligibility database architecture, except that the

national client database also performs two other major program functions. First, it links

to several other federal and State databases to allow direct verification of client-reported

income, assets, and employment. Second, it performs a variety of checks and

computations to determine eligibility for TANF.

Using these models developed in the DHHS as a starting point, this study assesses the

feasibility and cost-effectiveness of a national client database. A secondary objective is to assess

the impact of such a database on the privacy of FSP and TANF clients. 

P.L. 105-379 also requires USDA to assess current State agency efforts to identify interstate

duplicate benefits, as well as State agency capabilities to participate in a national client database.

 Both of these assessments are incorporated into the evaluation of the feasibility of such a

database.

The conclusions of this report are:

1. A national client database is feasible if it is configured using either an eligibility database

or a one-stop database architecture. 
xiii

In order to be considered feasible, the database must meet all of the following conditions:

ß It must be consistent with the functional requirements for the database in helping to

administer FSP and TANF.

ß The technical risk of the system’s not working after development should be minimal.

ß The centralized component of the database needs to be developed and operated at a

reasonable cost.

ß The State agency component of the database must be developed and operated at a

reasonable cost and must not require significant increases in agency staff.

Functional requirements for the national client database are to provide data to State FSP and

TANF agencies that enables them to identify interstate duplicate cases and to enforce PRWORA

time limits for both programs.

Feasibility. Both the eligibility database and one-stop database architectures meet the

functional requirements for a national client database. They also provide State agencies with

sufficient data that they can follow-up interstate duplicate cases and enforce PRWORA time limits

without significant staff increases. The other three architectures do not directly support the

enforcement of PRWORA time limits. They also require State agencies to engage in a very

inefficient procedure of exchanging data files with every other State agency every month. This

procedure would likely require significant State agency staff increases.

Current State Agency Activity in Detecting Interstate Duplicate Benefits. There are two

types of evidence supporting the feasibility of a national client database. The first is that a number

of State FSP and TANF agencies participate in programs designed to identify interstate duplicate

cases. Ongoing monitoring, by FNS, of State FSP agencies indicates that the majority of States

have participated at least once in the past several years in an interstate match designed to identify

interstate duplicate FSP cases. Twenty-five State FSP agencies routinely conduct such matches for

interstate duplicate FSP cases. The largest existing system for detecting interstate duplicate TANF

cases is the PARIS system. Thirty-two States participated in PARIS for at least one match.

State Capabilities to Participate in a National Client Database. The second source of

evidence for the feasibility of a national client database is in-depth interviews by USDA with officials

in the FSP agencies of seven States regarding their capability to participate in a national client database.

Each agency reported having the capability to participate in such a database. The officials assumed the

centralized portion of the database would be developed and operated by a federal agency. They also

realized they would need to develop and operate the State agency portion of the system. However, they

assumed the system would be designed so that the State agency’s activity would be limited to preparing

and sending an extract of its case records to the central facility, receiving case record extracts from the

central facility, and verifying and following-up on the matched cases. Under this assumption, the

officials felt that developing and operating their portion of the national client database would not be

difficult.

The seven States should not be viewed as a statistically representative sample of all States. While

these conclusions cannot be generalized to all State agencies, they suggest States’ capabilities. USDA

is currently conducting a comprehensive survey of all State FSP agencies on their computer capabilities.
xiv

2. If developed for both the FSP and TANF, it is likely that the use of an eligibility database

architecture would be cost-effective. However, it would not be cost effective if it were

developed for the FSP alone. An eligibility database developed by the Federal government within current

funding arrangements for FSP and TANF, however, is likely to increase Federal costs

Available data are inadequate to estimate the costs or benefits of a national client database reliably.

 However, calculations using the data that are available, supplemented by a number of assumptions,

suggest that a national client database is cost-effective if it is configured using an eligibility database or

one-stop database architecture. This conclusion holds even though in the calculations the benefit

portion of the benefit-cost ratio is limited to detecting interstate duplicate FSP and TANF cases and

excludes the benefit from enforcing ABAWD and TANF time limits across State boundaries.

This analysis makes no assumption about how costs or benefits are allocated among Federal or

State agencies. An eligibility database developed by the Federal government within current funding

arrangements for FSP and TANF, however, is likely to increase Federal costs. This would occur

primarily because the savings from recovered and avoided TANF benefits would accrue only to States

under the existing block grant, while the Federal government would bear most of the developmental

and operational costs.

The cost-effectiveness of the file match, broadcast, and eligibility index architectures cannot be

estimated. However, they cause the State agency component of the system to be substantially less

efficient than under the eligibility database or one-stop database architectures. This loss of efficiency

means that these three architectures would be less cost-effective than the eligibility database or onestop database architectures. 

The one-stop architecture may be less cost-effective than the eligibility index because it is more

expensive to develop and operate. The extra expense of the one-stop architecture results from it

providing two major programmatic functions that are not required for the functional requirements

identified here for a national client database. The one-stop architecture may be viewed as a future

enhancement of the national client database.

3. Most privacy issues are addressed in straightforward ways, but the possibility of

unintended uses of the data remains a significant risk.

A national client database raises concerns about protecting the privacy of FSP and TANF clients.

 Privacy concerns fall into three categories. The first is that FSP and TANF data are owned by the

State agencies providing benefits to the FSP or TANF case and may not be disclosed to an agency of

another State or federal agency. A solution to this problem is to execute privacy agreements between

State agencies and the sponsoring federal agency.

The second category of privacy concerns is unauthorized physical or electronic access to the

national client database. This threat to security could be controlled by building physical, electronic, and

procedural safeguards into both the centralized component and the State agency component of the

database. 

The third category of privacy concern is the threat of authorized but unintended uses of the data.

 This risk to client privacy is the most difficult to control. The wide variation among State privacy laws
xv

suggests that this risk is minimized by construing the national client database as a federal system of

records subject to the Privacy Act and the Computer Matching and Privacy Act.

NEXT STEPS

If a decision to develop a national client database is made, two considerations affect how rapidly

development can start. First, adequate time must be allowed to appropriate sufficient funds to the

primary federal agency managing the effort. Second, time must be allowed for the agency to either hire

and organize qualified staff with appropriate expertise or to pursue the procurement processes involved

in soliciting and choosing a national database contractor.

This investigation also revealed potential concerns that should be further investigated. One

concern is that a federally sponsored national client database may have the appearance of altering the

governance of the FSP and TANF programs, both of which are administered by State agencies. A

second related concern is the potential public perception of a national database of individuals who

received benefits from a means-tested program at any point in their lives. This concern is particularly

acute because enforcing TANF time limits will eventually result in the database containing data on

program participation throughout much of an individual’s adult life, perhaps covering over forty years.

 The dynamics of poverty and welfare receipt imply that such a database may eventually contain data

on a substantial fraction of the population of the nation.
xvi

PAGE IS INTENTIONALLY LEFT BLANK TO ALLOW FOR DOUBLE-SIDED COPYING
1

CHAPTER I

INTRODUCTION

Late in 1998, the U.S. Congress enacted P.L. 105-379,1 Section 2(a) of which requires the U.S.

Department of Agriculture (USDA) to:

“...conduct a study of options for the design, development, implementation, and operation of a national

database to track participation in Federal means-tested public assistance programs.”

It specifies that the report address the following areas:

“(b) Administration.--In conducting the study, the Secretary shall--

(1) analyze available data to determine—

(A) whether the data have addressed the needs of the food stamp program established under

the Food Stamp Act of 1977 (7 U.S.C. 2011 et seq.);

(B) whether additional or unique data need to be developed to address the needs of the food

stamp program; and

(C) the feasibility and cost-benefit ratio of each available option for a national database;

(2) survey the States to determine how the States are enforcing the prohibition on recipients

receiving assistance in more than one State under Federal means-tested public assistance

programs;”

(3) determine the functional requirements of each available option for a national database; and

(4) ensure that all options provide safeguards to protect against the unauthorized use or

disclosure of information in the national database.

 

1

“An Act to Amend the Food Stamp Act of 1977 to Require Food Stamp State Agencies to Take Certain Actions to Ensure

that Food Stamp Coupons Are Not Issued to Deceased Individuals, to Require the Secretary of Agriculture to Conduct a Study

of Options for the Design, Development, Implementation, and Operation of a National Database to Track Participation in

Federal Means-Tested Public Assistance Programs and for Other Purposes.”
2

This report responds to that mandate to submit a report to Congress on the feasibility of a

national client database containing information on recipients of the federal means-tested public

assistance programs. Such a database would document interstate duplicate participation and track time

limit requirements in the Food Stamp Program (FSP) and the Temporary Assistance to Needy Families

(TANF) program. The Food and Nutrition Service (FNS) was given the task of conducting the study

which builds on previous research conducted by the Department of Health and Human Service

(DHHS) that assessed States’ readiness for establishing a system capable of tracking recipients over time

and across States.2

In particular, the report examines the functional requirements, technical feasibility and costeffectiveness of a national client database, as well as safeguards to protect against unauthorized or

unintended use of the data. The report reviews potential design issues of such an information system

and highlights concerns that should be addressed before a national database could be implemented.

 The report focuses primarily on the FSP and secondarily on TANF.

Duplicate participation is a concern across all means-tested programs. However, because the FSP

and TANF programs are the only two means-tested programs that require tracking of time limits, they

pose the critical test of the feasibility of a national database. Therefore, in this report we focus on the

FSP and TANF programs. If a system for FSP and TANF is feasible and cost-effective, then adding

other means-tested programs (such as Medicaid) is unlikely to significantly decrease cost-effectiveness

(and may increase it).

This introductory chapter describes the background and policy context of the study, current

activity in cross State computer matching, information sources on which the report is based, and the

organization of the remainder of the report.

BACKGROUND INFORMATION AND POLICY CONTEXT

The FSP is a federal program, with program benefits paid by the federal government and with

program administrative responsibilities shared with the States and subject to the requirements of the

Congress. FNS is responsible for promulgating regulations, financial planning, review and

reimbursement of State agency expenditures, monitoring State agency operations, and evaluating the

program. Day-to-day operations of the program, including the determination of eligibility and the food

stamp benefit amount, are conducted at the state and local levels of government. As a result, most data

on program clients reside at the State or, in a few States, the county levels of government.

Title I of the Personal Responsibility and Work Opportunities Reconciliation Act (PRWRORA)

of 1996 (P.L. 104-193) contained a variety of legislative provisions that reflected Congress’ longstanding

interest in and desire to reduce fraud, waste and abuse in the FSP. These included time limits on

participation for able-bodied adults without dependent children (ABAWDS), the exclusion of most

legal immigrants from participation until they become citizens, new requirements for complying with

child support enforcement agencies, a tighter definition of eligible household; and new sanctions

resulting in more frequent and longer program disqualifications. It also created the Temporary

Assistance for Needy Families (TANF) which replaced the Federal Aid to Families with Dependent

Children (AFDC). The legislative provisions for TANF included very specific work requirements, a

 

2To assure successful completion of this effort in a timely manner, FNS contracted with Mathematcia Policy Research, Inc.

(MPR) to assist in data collection, analysis and the generation of the report.
3

prohibition on Federal TANF assistance to a family that includes an adult after 60 months, barring of

convicted drug felons and fugitive felons from benefit receipt, and new program and fiscal reporting

requirements.

This legislation has created significant challenges for State casefile database information systems.

 States now need to have the ability to track recipient households and participating individuals within

those households, over time and across jurisdictions. Both active and inactive cases, including

disqualified recipients or subpopulations barred from participation (i.e. convicted drug felons), need

to be tracked. Such tracking capability would provide a tool that could enhance a State’s ability to

identify duplicate participation and administratively disqualified cases and individuals. 

In order to assess State’s readiness for establishing a system capable of tracking recipients over

time and across States, Section 106 of PRWORA directed the Secretary of DHHS to prepare a report

on the status of State automation systems to support the requirement of welfare reform and to discuss

options for establishing a system capable of tracking recipients over time and across States. This report

provided information on (1) the status of automated data processing systems operated by the States

to assist in the administration of State programs under Part A of Title IV of the Social Security Act;

and (2) the requirements to (a) establish a system capable of tracking participants in public programs

over time; and (b) check case records of the States to determine whether individuals are participating

in public programs in 2 or more States. Congress also directed that the report include a plan for

building on the automated data processing systems of the States to establish a system with the

capabilities described in item (2) above; an estimate of the amount of time required to establish such

a system; and an estimate of the cost of establishing such a system.

At the time of information gathering (1996), States were in the planning stage for TANF

automation. Since this was a time of transition, it was difficult to completely assess the status of the

automated data processing systems. It was determined, however, that when available system

architectures were associated with appropriate levels of functionality, there were five system

architectures available that met the required parameters (File Match, Broadcast, Eligibility Index,

Eligibility Database and “One-Stop” Database). These are discussed in Chapter II.

INTERSTATE DUPLICATE PARTICIPATION

Occasionally a participant is identified as receiving benefits, concurrently, in more than one

location within a State, (intrastate duplicate participation); or concurrently, in more than one State or

jurisdiction (interstate duplicate participation). In recent years, many States have used their Statewide

client database to address the problem within the State. However, interstate duplicate participation

continues to be a concern. 

In August 1998, the General Accounting Office (GAO) published the results of an investigation

of interstate duplicate food stamp benefits (GAO 1998). GAO matched the FSP caseloads in four large

States – California, Texas, Florida, and New York – finding over twenty thousand duplicate individuals

and an overpayment of nearly $4 million. Based on this finding, GAO recommended the development

of a national information system to check for such duplicate benefits, and suggested that such a system

could also be used for implementing the time limits mandated by the welfare reform law. GAO’s

evidence that duplicate issuance is a problem is further supported by the findings of several States that

have established agreements with other States to match FSP and/or TANF case records. These
4

arrangements, which are discussed in Chapter IV, have identified significant numbers of interstate

duplicate cases in those States.

FSP AND TANF TIME LIMITS

PRWORA made important changes in both the FSP and the welfare system (now TANF) which

increased the need for information about program participants to be shared among States.3 In

particular, that legislation set time limits that constrain the periods over which certain groups of

recipients can receive benefits under each program. Also, these legislated time limits apply to benefits

received in all States.

The FSP time limit applies to able-bodied adults without dependents (ABAWD), between the ages

of 18 and 50 who are able to work and do not have any children or other dependents. Those persons

can receive food stamp benefits for only three months out of every 36-month period, unless they meet

one of three work requirements: Work at paid employment for 20 or more hours per week; participate

in a workfare program; and participate at least 20 hours per week in an allowable work activity, such

as a Food Stamp Employment and Training program. ABAWDs remain eligible for food stamp

benefits as long as one of these work regulations is met.

The TANF time limit applies to all adult participants. An individual may not receive benefits from

the TANF program for more than five years during the client’s lifetime.

 

3

The TANF limits are set by Section 408 of PRWORA. Those for the FSP are set by Section 824.
5

CROSS STATE COMPUTER MATCHING ACTIVITY

IMPACT OF COMPUTER MATCHING

Prior to 1986, investigation of questionable information given by an applicant for food stamps was

a labor-intensive activity that often severely taxed the capabilities of local welfare offices. Conventional

methods to detect program violations, such as duplicate participation, relied on information obtained

from the documents a person submitted as proof of identification. The resulting information, based

on interviews with employers, landlords, friends and neighbors contacted to confirm the information

provided by the applicant, was often of limited reliability.

Advances in computer technology permitted the development of strategies that increased the

amount of reliable information necessary to determine benefit eligibility and made fraud more difficult

to commit and easier to detect. As the technology became more available, the existing activities were

expanded to detect any inconsistencies in information in ongoing cases.

Computer matching is most frequently used to verify the eligibility of new applicants (intake) or

to verify the continuing eligibility of current recipients (recertification). It is a powerful management

tool that has significantly increased program integrity and efficiency. For example, the Income

Eligibility Verification System (IEVS), established in 1986, matches case records with six external

federal databases which contain information such as wages, income taxes, unemployment insurance

benefits, that can be used to verify the income or assets of a recipient or applicant household. Some

additional computer matching strategies with the potential to verify information and ensure that

ineligible individuals are not included as members of the recipient or applicant household include (1)

the Social Security Administration’s Death Master File; and (2) comparison of case records to records

of inmates in State prisons.

CURRENT ACTIVITY

The Food Stamp Act as amended requires each State agency to establish a system to assure that

no individual participates in the FSP more than once a month, in more than one jurisdiction, or in

more than one household within the State. There is no current requirement for interstate tracking for

the FSP. However, Title I of PRWORA includes a provision that States track TANF recipients across

State boundaries as well as within their own jurisdiction and that they track recipients over time to

ensure they do not participate beyond legislated time limits.

States have been very active incorporating systems changes to track TANF and ABAWDS.

Although there is presently no systematic cross-State tracking at a national level, States often exchange

information and data with other individual States. Matching is often conducted against caseload data

from neighboring States (often only including border counties). Many States also conduct matches

based on profiling or targeting strategies.

Participation in a cross-State match can either be Active or Passive. For example, State A

requests data from States B, C, and D and conducts the match on a regular basis (monthly,

quarterly or yearly). This would be considered an Active routine match for State A and a Passive
6

routine match for the other participating States. If the State A match results in a ‘hit’ on a case in

State B, both States benefit from the match.

Ongoing monitoring, by FNS, of State FSP agencies indicates that the majority of States have

participated at least once in the past several years in an interstate match designed to identify interstate

duplicate FSP cases (See Appendix A). Twenty-five State FSP agencies routinely conduct matches for

interstate duplicate FSP cases. Thirty-two States have participated in Public Assistance Reporting

Information System (PARIS), a system designed to detect interstate duplicate participation and TANF

time limits for at least one match.

DATA SOURCES AND LIMITATIONS

SOURCES

The information used in preparing this report is based on data from several sources. Because

Congress required this report within a year of passage of P.L. 105-379, it was not possible to engage

in extensive new data collection. Therefore, to the extent possible, information was obtained from

available data, supplemented by telephone interviews with knowledgeable staff, such as State

information systems directors, in 7 selected States, and personal communications and interviews with

experts in the field. 

DHHS REPORT

In response to a mandate in PRWORA, DHHS investigated the feasibility and cost of a national

client database (DHHS1997). This report, which is discussed in detail in Chapter II, provided a valuable

starting point for this study.

FNS RESEARCH STUDIES

Food Stamp Program Operations: Update (STOPS)

In 1991, FNS conducted a State census of selected State operations which included modules on

computer matching and automated case management systems (USDA 1992). The data from that

census was used to provide a basis for assessing State capabilities. Although the information in this

earlier study is somewhat dated - many States have updated their computer systems significantly since

that time - it has been useful in indicating a baseline estimate of the computer capabilities of the States.

NEW DATA COLLECTION

Interviews with Seven Selected States

In order to supplement the available data interviews were conducted with FSP agency officials in

seven States to obtain information about their current computer matching activities and their

capabilities for participating in a national client database, if one were created. As described in Appendix
7

B, these States were chosen by FNS to reflect a variety of state systems. While a sample of seven States

does not support statistical generalizations to the remaining States, these discussions were valuable in

suggesting trends in State FSP agency computer capabilities. The seven states were Arizona, Arkansas,

Florida, New Jersey, New York, Pennsylvania and Utah.

FNS In-House Monitoring of Food Stamp Operations

Routine in-house surveys of the States are conducted by FNS as part of its monitoring of food

stamp operations. This was the major data source for information on interstate computer

matching for duplicate participation.

Discussions with Staff of Four Ongoing Matching Systems

To increase FNS’ knowledge about the function, policy implications and capabilities of matching

systems, selected existing client databases were reviewed. Interviews were conducted with

knowledgeable staff from each agency responsible for development and/or administration of the

matching systems. The interviews focused on major issues regarding the design, development and

implementation of national databases. The discussions provided information about the feasibility of

developing and operating a national database; implementation challenges and how they were or were

not resolved; and client issues and concerns. The four matching systems were Public Assistance

Reporting Information System (PARIS), coordinated by DHHS; the Criminal Justice Information

System (CJIS), coordinated by the Federal Bureau of Investigation; the Federal Parent Locator Service

(FPLS) operated by DHHS; and the Wage Record Interchange System (WRIS), jointly administered

by the U.S. Department of Labor and the Interstate Committee of Employment Security Agencies

(ICESA).

LIMITATIONS

Additional data are required to increase the reliability of the estimates derived for the costs/benefit

analysis and the assessment of computer capabilities of the States as existing data cannot adequately

support the development of precise estimates for either.

The cost/benefit analysis was based on relevant available data, supplemented by a number of

assumptions. This being the case, the estimate presented in this report should be considered a rough

approximation and used cautiously. Additional data required includes: A prototype of a technical design

for a national client database; estimates of the number of interstate duplicate cases in the States (no

estimates are currently available); and data on the characteristics of interstate duplicate cases, including

client demographics, the number of months receiving FSP and TANF benefits, and benefit amount.

Although the information from previous research conducted by DHHS and FNS have been useful

in indicating a baseline estimate of the computer capabilities of the States the conclusions are

inconclusive without current corroborating data. FNS is currently conducting a detailed and systematic

census of States FSP operations regarding current computer matching activities. The new study will

include modules on interstate matching and automated case management systems. Results should be

available before FY2001. Information will be collected from all 50 States, Puerto Rico, Guam and the

Virgin Islands.
8

PLAN OF THE REPORT

Chapter II summarizes the results of the DHHS report. Chapter III presents the functional

requirements the national client database would fulfill and assesses the feasibility of a national client

database. Chapter V estimates the cost-effectiveness of such a database. Chapter VI reviews the

privacy and security issues of a national client database. Chapter VII concludes the report with a

summary of the key findings.
9

CHAPTER II

THE DHHS REPORT

In order to assess State’s readiness for establishing a system capable of tracking recipients over

time and across States, Section 106 of PRWORA directed the Secretary of DHHS to prepare a report

on the status of State automation systems to support the requirement of welfare reform and to discuss

options for establishing a system capable of tracking recipients over time and across States. This report

was written to provide information on (1) the status of automated data processing systems operated

by the States to assist in the administration of State programs under Part A of Title IV of the Social

Security Act; and (2) the requirements to (a) establish a system capable of tracking participants in public

programs over time; and (b) check case records of the States to determine whether individuals are

participating in public programs in 2 or more States. Congress also directed that the report include a

plan for building on the automated data processing systems of the States to establish a system with the

capabilities described in item (2) above; an estimate of the amount of time required to establish such

a system; and an estimate of the cost of establishing such a system.

In December 1997, DHHS responded to this mandate by submitting a report to Congress, entitled

Temporary Assistance for Needy Families (TANF) Report of Data Processing, hereafter called the DHHS report.

 The DHHS report made a substantial contribution to the current investigation of a national client

database, and this chapter reviews it in some detail.

STATE CAPABILITIES

The first task undertaken by the DHHS study was to assess the capabilities of State TANF

agencies to implement the provisions of PWRORA. DHHS conducted a survey in 1996 of TANF

agency information system managers and welfare reform coordinators in all States and U.S. territories.

 The key relevant findings included:

ß Most State TANF agencies (81 percent) were able to identify duplicate TANF cases within

the State. 

ß A small minority of agencies (12 percent) were able to implement the TANF time-limit

within the State. The majority (66 percent) of State agencies were still in the planning

stages of developing a capability to implement TANF time limits within the State.

ß Virtually no State agency could identify duplicate TANF cases or implement the TANF

time-limit across State boundaries.
10

ß States reported several barriers to the implementation of TANF time limits, in the short

run, including:

S The complexity of TANF

S The age of State agency information systems, and the rigidity of their designs

S Development costs, in terms of agency budgets and staff availability

FUNCTIONAL REQUIREMENTS

A second task of the DHHS report was to specify the functional requirements of a potential

national client database. Functional requirements specify the programmatic objectives of the database,

but do not specify the techniques by which those objectives are achieved.4 DHHS specified an

extensive list of functional requirements that included two that are the focus of the current report:

ß Provide data to support the tracking of TANF time limits.

ß Identify interstate duplicate TANF cases.

DHHS also included in its list of functional requirements the determination of eligibility and verification

of client-reported information on income, assets, and employment. Since the DHHS focussed on the

TANF program rather than the FSP, its list of functional requirements did not include identifying

interstate duplicate FSP cases, or providing data to support the tracking of ABAWD time limits.

ALTERNATIVE SYSTEM ARCHITECTURES

A major contribution of the DHHS report was to define five alternative architectures for the

centralized component of a national client database. A system architecture is a general description of

how the national client database would work. Just as TANF and FSP are partnerships between federal

and State agencies, so too was the national client database which the DHHS report considered. A

national client database was viewed as the entire system of national and State agency automated and

manual processes required to achieve the functional requirements of the system. Thus, the national

client database is composed of a centralized component, assumed to be administered by a national

contractor, and a set of automated and manual processes performed by State agencies. The description

of each system architecture presented below includes both the centralized component of the system

and the State agency component of the system. More detailed descriptions of the five architectures

may be seen in Appendix C.

The alternative architectures are arranged from simple systems performing fewer functions, to

more complex systems performing more functions. Simple architectures impose more burden on State

agencies because those agencies must perform the functions not performed by the national client

database. As shown in Chapter V, recognizing that the national client database has a State agency

component is important for the assessment of cost-effectiveness. Simple architectures generally cost

 

4

 Functional requirements are discussed fully in Chapter III.
11

less to develop and operate than more complex architectures, however simple architectures cause the

State agency component to be more expensive.

The alternative architectures examined by the DHHS Report are:

C File Match. At the end of each time period such as a month or a quarter, each State

sends a file of current recipients, represented by their social security numbers (SSNs) and

name, to the national client database. Software associated with the central database

compares each case to every other case in every other State searching for duplicate cases.

 If a recipient is found in more than one State, the central facility sends the SSN and name

of the duplicate case to both State agencies. The national client database does not

accumulate historical data on program participation, nor does it send data other than SSN

to the two State agencies.

C Broadcast. Each State agency periodically transmits a file containing the SSNs and names

of its active cases to every other State agency. There is no centralized national client

database, and the central facility provides no data to State agencies. The task of identifying

duplicate cases is left to State agencies.

C Eligibility Index. This architecture is similar to the file match architecture, except that

each State agency sends SSNs and names of new applicants and recertifications to the

central facility at any time, and SSNs and names are retained in the national client database

so that historical data on program participation is accumulated.

C Eligibility Database. This is similar to the eligibility index option, except that the State

agency transmits an extract of each case record, rather than just the SSN and name, to the

national client database. The central facility identifies interstate duplicate cases, and sends

the case record extract from both State agencies to each of the two State agencies. The

national client database accumulates historical data on program participation. Thus, the

central client database sends sufficient data to State agencies for them to minimize the

amount of data they need to retrieve directly from other State agencies.

ß One-Stop Database. This is similar to the eligibility database architecture, except that

the national client database also performs two other major program functions. First, it

links to several other federal and State databases to allow direct verification of clientreported income, assets, and employment. Second, it performs a variety of checks and

computations to determine eligibility for TANF.

DHHS found each of the five architectures to be feasible. Although the definition of feasibility

in the DHHS report is not completely clear, it appears to define feasibility narrowly to be the

technological feasibility of a contractor developing and operating the central component of the national

client database. The DHHS feasibility assessment did not appear to account for the different level of

burden placed on State agencies by the different system architectures.
12

DHHS estimated the cost of a contractor developing and operating the centralized component

of a national client database. The FNS review of these cost estimates indicates they are sound. The

DHHS analysis did not include estimates of the costs of the State agency component of a national

client database, nor did it estimate program savings resulting from the database. Without estimating

the benefits side of the ledger, DHHS did not reach any conclusions regarding the cost-effectiveness

of a national client database.

OTHER ISSUES CONSIDERED BY DHHS

DHHS also discussed several additional issues pertaining to the development of a national client

database, including privacy, funding, developmental responsibility, and operational responsibility. Key

points are:

ß Since the national data system involves the sharing of confidential data among different

jurisdictions, the privacy of recipients must be protected. DHHS does not propose

specific safeguards.

ß DHHS does not definitively place the responsibility for the centralized portion of the

national client database with the federal government, nor does it propose an allocation

of funding between federal and State governments.

DEVELOPMENTS SINCE THE DHHS REPORT

In August 1998, the General Accounting Office (GAO) published a report on interstate duplicate

FSP cases (GAO 1998). The report recommended the development of a national client database to

check for such duplicate benefits, and suggested that such a system could also be used for implementing

TANF and ABAWD time limits. The GAO report was one of the factors leading Congress to enact

the P.L. 105-379, which requires the Secretary of the U.S. Department of Agriculture (USDA) to

submit a report to Congress on the feasibility and desirability of developing a national client database

to track participation in federal means-tested programs. As noted in Chapter I, this law led to the

current study.
13

PAGE IS INTENTIONALLY LEFT BLANK TO ALLOW FOR DOUBLE-SIDED COPYING
14

CHAPTER III

FUNCTIONAL REQUIREMENTS AND

TECHNICAL FEASIBILITY

This chapter discusses the technical requirements and assesses the feasibility of developing and

operating a national client database. It begins by proposing a conceptual framework for a national

client database; and describes how a client tracking system would work. Also discussed are the system

functional requirements, the feasibility of developing a central processing component, the States’

technical capabilities, the feasibility of States’ being able to effectively interact with a national database,

and data availability. The DHHS report suggested five alternative system architectures for the national

client database. The chapter concludes by assessing the technical feasibility, within the context of the

structure developed earlier in the chapter, for each of the five alternative systems architectures

suggested by DHHS.

CONCEPTUAL FRAMEWORK FOR A NATIONAL DATABASE

A model was developed to assess the technical feasibility of a national database. There are three

major components of the model: system requirements, States’ technical capabilities, and data

availability. Identifying the functional requirements of a national client tracking system provides a

structure that can be used to assess technical feasibility.

Given a set of functional requirements of the system, the technical feasibility of such a system is

determined by the degree to which the States have the technical capability to interact with it and the

degree to which data is available for its effective use. The technical risk of the system not working after

development would need to be minimal. Therefore, the greater the overlap of the States capabilities

and data availability with the system functional requirements, the lower the expected technical risk

associated with the design, development, and operation of a national database. Figure III.1 illustrates

this relationship.
16

A database is constructed on the basis of

participation data supplied by State agencies

and housed at a central processing facility.

State FSP and TANF agencies send an extract

of its active case records or new applicants to

the central national client database facility.

The central facility matches the extract with

similar data from other participating States.

The match would produce a list of suspected

duplicate cases and data on ABAWD and TANF

participation in other States.

For each potential duplicate case, the central

facility sends the case record extract from the

other States back to the State agency.

For matched cases, the State agency verifies

that the cases in the two States are the same

individuals and takes appropriate action.

Figure III.1. Relationship Between Functional Requirements and Technical Feasibility

HOW A NATIONAL CLIENT DATABASE

WOULD WORK

Initial development of a national client

database would involve a central processing

facility containing data on all current FSP and

TANF participants in the nation, as well as

month-by-month data on past participation in

those programs since the implementation of

PRWORA. These data would be supplied by

the States from their automated case

management systems.

States would upload a file containing

 Degree

of 

Technical

Feasibility

System Functional Requirements

Data

Availability

States

Technical

Capabilities
17

identifying data either on new applicants or on the State’s full caseload in a recent month. The central

processing facility would then process this new information by comparing it to the cross-state database,

matching on the person-level identifying information. During this data processing, the central facility

would identify cases that were apparently certified to receive food stamps in more than one State. It

would also list past receipt of program benefits in other States by the persons on the newly supplied

file, thus generating information that could be used to determine whether time limits had been reached.

 When States received this match information, they would examine the data and identify cases that

seemed to be receiving benefits incorrectly. It is likely that, at least in the initial phases of system

operation, the States would manually verify much of this information, both by examining their files and

by contacting program staff in the relevant other States. Once States had identified persons that were

receiving benefits incorrectly, they would then discontinue issuances to those cases and initiate attempts

to recover past overpayments, as appropriate.

The above process would then continue on a regular basis, with States sending requests for

information on new applicants at least every few days. Also, States would routinely supply updates to

the central database on program participation at regular intervals—probably once a month, reflecting

the monthly issuance cycle used in both the FSP and TANF. The steps are illustrated in Figure III.2.
18

Figure III.2. Activities in the National Client Database

 

 Match No match

 

 ABAWD TANF

 

 Query source State for

 additional details

 

 

 

 Update client database

Match caseload against

the national client database

 Suspected duplicate 

 participation

 

 Take appropriate action

ABAWD TANF

Suspected time limit violation
19

Receive and store identifying data

Obtain or retrieve information from states

Compare identifying information on cases

Ensure timely distribution of the information

CENTRAL FACILITY

The central facility would need the capability to receive and store data extracted from FSP and

TANF files provided by States. The data would include:

ß Whether the case is currently active in the State in each program (interstate duplicate

participation)

ß The start and stop dates of spells of employment since the State PRWORA program was

implemented. (ABAWD time limits)

ß Exemptions from ABAWD time limits

ß The number of months each individual in the case participated in the program since the

State PRWORA program was implemented, regardless of the number of the number of

spells of participation (TANF time limits)

ß Exemption from TANF time limits

Only current information would be necessary if the objective were limited to detecting current

duplicate issuances. However, the objective of assessing whether time limits have been exhausted

requires month-by-month data on benefit receipt in each program, together with information on

whether recipients were subject to the time limit rules in those earlier months—whether they were

working or had exemptions. 

The central facility must have the ability to scan newly submitted identifiers against this basic

database and retrieve the relevant information.

Finally, it must have the capacity to transmit information on matches back to the relevant states

in a timely manner. The receipt, matching, and distribution process should be completed within a few

days.

To assess whether such a system would be technically feasible, FNS interviewed staff and

reviewed documentation of four current matching systems: Federal Parent Locator System (FPLS);

Criminal Justice Information System (CJIS); Public Assistance Reporting Information System (PARIS);

and Wage Record Interchange System (WRIS). (A description of each system is provided in Appendix
20

Automated certification and case management system

Upload caseload data on new and active cases in TANF and FSP

Receive and download caseload data

Integrated State client database across programs

Short turn-around time to conduct and process routine computer match

Database maintenance: update caseload data on a regular basis

D). Each of these four matching systems currently performs many of the same functions as a national

client database would. Each collects data from every State and matches State records to a central

database. The matches are designed to identify the following variables: earnings in another State (FPLS

and WRIS), committed a crime in another State (CJIS), and receipt of TANF or Food Stamp benefits

in more than one State (PARIS). The FPLS system, and for some States the CJIS system, represent

successful implementations of centralized databases that store detailed information provided by States

and are updated frequently. The PARIS system is a successful implementation of a system that collects

case record extract data from participating States and matches them to data from other States agencies

in order to detect interstate duplicate participation as well as TANF and ABAWD time limits.

The WRIS system, and for some States the CJIS system, involve a slightly different approach in

which the central database is limited to identification data. This index database is embedded in software

that automatically queries a State agency database every time a pair of duplicate records is identified.

 The query retrieves the required data from the database of the two State agencies involved, assembles

a case extract record and then sends the newly assembled extract record to each of the involved State

agencies. This approach avoids the necessity of storing large amounts of confidential data at a central

location.

STATES TECHNICAL CAPABILITIES

To interact effectively with a national client database, State agencies must be able to:
21

ß Prepare a case record extract containing ID data and the data listed in the previous section

for FSP and TANF for all active cases as well as new applicants

ß Transmit the resulting data file to the central national client database facility

ß Receive the data from matching records in other States

ß Verify that apparently duplicate cases are actually duplicate cases

ß Process duplicate cases as other overpayment situations are handled

ß Compute whether each individual in a matching case has exceeded the relevant PRWORA

time limit

States have performed many of these functions for many years. FNS conducted a State Census

of FSP operations in 1991, which included detailed questions about computer matching activities and

automated case management systems. Data from the census show States agencies were capable of

providing SSNs of applicants to external databases and following up on matches. Every State FSP

agency performed some type of computer matching using SSNs as identifiers to match against external

databases.

A Statewide automated case management system is critical if a national client database is to be

effective. Only three State agencies—Montana, Minnesota and California—did not have such a system

in 1992. All three had plans to implement at that time. In addition it is highly recommended that the

State client database be integrated with other assistance programs, especially TANF. Currently, only

five States do not have an integrated database—Arkansas (planned in near future), Massachusetts

(planned), Missouri, Nevada, and the Virgin Island. In addition they must be able to effectively process

the match data that are returned to them.

To supplement the available data, FNS conducted interviews with seven State FSP agencies in

the Summer of 1999. The seven State agencies were Arizona, Arkansas, Florida, New Jersey, New

York, Pennsylvania, and Utah.5 The interviews focused on (1) changes in their capabilities since the

1991 study and since the passage of PRWORA in 1996 and (2) whether they could perform the

functions required to participate in a national client database.

None of the seven States agencies raised serious concerns about their ability to interact with a

national client database. Each also reported being able to extract and transmit case record data to an

external database, and receive data files through electronic means. Some States, however, did not have

the client data necessary to track ABAWDs time limits.

 

5The method by which these seven States were selected is presented in Appendix B.
22

Identifier should include, at a minimum, the SSN,

name and date of birth

Individual is the unit of analysis of data stored in

database

Historical data for each individual in the household,

including: start and end dates of each participation

‘spell’ for each program, and penalties applied, as

follows:

TANF:

Number of months participated

Number of payments actually made

Exemptions granted

ABAWDS:

Work history

Exemptions granted

DATA AVAILABILITY

A national client database would require that

State agencies maintain specific types of data in

their case records. First, case records would

include identification variables, including SSN,

name, and date of birth. This data should be

maintained for each adult in the household in

a format that would allow individual adult

members of the household to be tracked when

household composition changes.

The second major data requirement would

be historical data on program participation and

employment. Program participation history

should include start and stop dates for each

spell of participation, number of months

participated, number of payments made,

exemptions granted, and penalties applied. 

Employment history should include start and

stop dates for each spell of employment, as

well as exemptions granted. A ‘period of

employment’ is defined as the number of months each adult satisfied a work requirement or, for food

stamps, was waived from the work requirement.

Data from a census of States conducted by FNS in 1991 indicate that historical data are maintained

as part of the automated case management system in all but six State agencies. Of the six, four archived

historical case data in such a way that they may be retrieved. Three States–Montana, Minnesota, and

California–reported that historical data was not maintained statewide. All State agencies use SSN,

name, address and date of birth of the head of household as an identifier. All but one State agency–

Florida–store SSN, name, and date of birth for individuals in the household. In all but six State

agencies, such individuals include the head of household, spouse, other adults, and children.

FEASIBILITY OF EACH ARCHITECTURE

Table III.1 presents an assessment of the feasibility and practicality of each of the five system

architectures proposed by the DHHS report. For each architecture, a review of how the architecture

works is presented, followed by whether the architecture meets each of the three
23

TABLE III.1. ASSESSMENT OF FEASIBILITY OF ALTERNATIVE ARCHITECTURES

Assessment Criteria

How the Architecture Works

Consistency with Functional

Requirements Centralized System

Component State Agency System Component

File Match

At the end of each quarter, each State

sends a list of recipients, represented

by their Social Security numbers

(SSNs), to a central facility, which

searches for matches in other States.

If a recipient is found in more than

one State, the facility notifies both

States. No data are retained at the

central facility.

This architecture cannot support the

enforcement of ABAWD or TANF time

limits for two reasons. First, the

database does not accumulate historical

data on participation or employment. 

Second, the system provides only ID

information to the State agency. None of

the other types of data listed in the

functional requirements is provided.

This architecture involves

minimal development risk,

and could be developed

within a year or two at a

reasonable cost.

Since the State agency receives only the ID of the

matching case, it would have to request the necessary

case record data for each matched case from the FSP

agency in the other State. Since this retrieval process

is not performed by the automated system, under this

architecture, the procedure is likely to be manual. 

Such a manual procedure would require additional

State agency staff. Thus, this architecture does not

fulfill this set of functional requirements.

Broadcast

Each State periodically transmits a

list of its recipients to every other

State.

This architecture does not even provide

the State agency with a list of matching

cases. It also cannot support the

enforcement of ABAWD or TANF time

limits because the only information

provided by the system to the State

agency is the matching case’s ID

information. None of the other types of

data listed in the functional requirements

is provided.

There is no centralized

component.

State agencies would receive over 50 databases each

month, and would have to match each one to its own

case records. Thus, State agencies as a group would

perform over 2,600 separate database matches each

month for each program. This does not meet the

reasonable cost requirements. Further, since the

matches contain only the IDs of the matching cases,

the agencies would have to request the necessary

case record data for each matched case from the FSP

agency in the other State. Since this retrieval process

is not performed by the automated system, under this

architecture, the procedure is likely to be manual. 

Such a manual procedure would require additional

State agency staff. Thus, this architecture does not

fulfill this set of functional requirements.
TABLE III.1 (continued)

24

Assessment Criteria

How the Architecture Works Consistency with Functional

Requirements

Centralized System

Component State Agency System Component

Eligibility Index

This is similar to the File Match option,

except that the SSNs of new

applicants and recertifications are

transmitted to the central facility at

any time, and data are retained by the

facility.

This architecture cannot support the

enforcement of ABAWD or TANF time

limits because the only information

provided by the system to the State

agency is the matching case’s ID

information. None of the other types of

data listed in the functional requirements

is provided.

This architecture involves

minimal development risk,

and could be developed

within a year or two at a

reasonable cost.

Since the State agency receives only the ID of the

matching case, it would have to request the necessary

case record data for each matched case from the FSP

agency in the other State. Since this retrieval process

is not performed by the automated system, under this

architecture, the procedure is likely to be manual. 

Such a manual procedure would require additional

State agency staff. Thus, this architecture does not

fulfill this set of functional requirements.

Eligibility Database

This is similar to the Eligibility Index

option, except that the State agencies

transmit the extract of the case

records, rather than just the SSN. 

The system delivers the case record

extract data for matching cases to the

State agency. The database

accumulates historical data.

Since the system sends the required data

to the State agency, and since historical

data are accumulated, all the functional

requirements in this category are fulfilled.

This architecture involves

minimal development risk,

and could be developed

within a year or two at a

reasonable rate.

Since the system provides the necessary data to the

State agency, it can perform its steps in the process

of identifying duplicate cases and enforcing ABAWD

and TANF time limits without adding staff.

One-Stop Database

This is similar to the Eligibility

Database option, except it performs

two additional functions. The first

function is income and asset

verification currently performed by the

Income and Eligibility Verification

System (IEVS). The second function

is determining eligibility for FSP and

TANF.

This architecture exceeds the functional

requirements. Performing some

functions currently performed by IEVS

and State eligibility determination

systems is not required for the national

client database.

This architecture involves

minimal development risk,

and could be developed

within a year or two at a

reasonable cost.

Since the system provides the necessary data to the

State agency, it can perform its steps in the process

of identifying duplicate cases and enforcing ABAWD

and TANF time limits without adding staff.
25

sets of criteria listed above. All five system architectures meet the functional requirements for the

central facility of the national client database. Three of the five architectures–file match, broadcast, and

eligibility index–provide less than the minimum functionality. One of the five–one-stop database–

provides more than the required functionality, raising a concern about its cost-effectiveness. The only

architecture that meets, but does not exceed, the requirements is the eligibility database.

While it is feasible to develop and operate the central component of a national client database

using any one of the five system architectures proposed by DHHS, only one of them–the eligibility

database architecture–is consistent with the functional requirements for a national client database and

is feasible and practical from the State agency’s perspective. It (1) provides the State agency with all

the data from agencies in other States necessary to investigate potential interstate duplicate cases and

track PRWORA time limits and (2) does not incur the cost of unnecessary functionality. The next

chapter on the cost-effectiveness of a national client database focuses on this architecture.
26

PAGE IS INTENTIONALLY LEFT BLANK TO ALLOW FOR DOUBLE-SIDED COPYING
27

CHAPTER IV

COST-EFFECTIVENESS

This chapter presents the cost/benefit analysis for a national client database. Existing data cannot

adequately support the development of precise estimates for either costs or benefits. Therefore, the

estimate is based on relevant available data, supplemented by a number of assumptions. This being the

case, the estimate presented here should be considered a rough approximation to be used cautiously.

The chapter begins by describing the scope and broad assumptions underlying the cost and benefit

estimates. This discussion continues with a simplified cost-benefit calculation followed by the detailed

assumptions and cost-benefit results. Also covered is the impact of alternative system architectures on

the cost-benefit calculations. This is followed by a discussion of the sensitivity of the cost-benefit

findings to variations in the key assumptions, and the key assumptions for which more data are needed.

 This chapter concludes with an overview of the findings.

SCOPE AND BASIC ASSUMPTIONS

The cost-effectiveness calculations assume the use of a database architecture based on the

‘eligibility database’ option proposed by DHHS. The rationale for this assumption is that it is the only

one of the five architectures proposed by DHHS that meets, but does not exceed, the functional

requirements stated in Chapter III.

Consistent with the functional requirements for the national client database, costs and benefits are

estimated for the food stamps and TANF programs, excluding other federal means-tested programs

such as Medicaid and subsidized housing programs.
28

The centralized portion of the system is assumed to be developed and operated by a single

organization. There is no assumption about how costs or benefits are allocated among federal or State

agencies. More specifically, there is no assumption on whether the centralized component of the

database is funded and operated by a federal agency or a consortium of State agencies.

The database is assumed to be developed in one year, FY 2000. This involves developing the

centralized portion of the system, as well as each State developing its interface system, within one year.

 Further, we assume a system life cycle of five years, that is, the system would operate for five years,

FY 2001 through FY 2005, and then is replaced with a new system.

Costs include the direct budgetary costs to the federal government and State governments. Costs

to recipients and costs to other entities are not considered. The FNS review of DHHS’s estimates of

development and operational costs of the centralized component of the system concluded that the

estimates are sound. These estimates are used in this analysis after adjusting them for inflation between

1997 and the relevant fiscal year.

Estimated benefits are limited to identifying interstate duplicate benefits. Benefits from enforcing

ABAWD and TANF time limits across States are excluded. There are two reasons for this exclusion.

 First, given data limitations, estimates of such benefits would be more speculative than those presented

here. Second, we find that the benefits accruing from interstate duplicate benefits alone are sufficient

to demonstrate that the system is cost-effective. Adding the benefits from enforcing PRWORA time

limits would only demonstrate that the system is even more cost effective than is shown here. 

A second important concept underlying the estimates of benefits is that benefits are assumed to

include recovered program benefits that have already been disbursed, avoided future program benefits, and

avoided future administrative costs.

Since the national client database is assumed to use SSN for identifying duplicate cases, the costeffectiveness analysis assumes that the entity whose interstate duplicate participation is detected is the

individual member of the FSP and TANF filing unit, as opposed to the entire filing unit. Once

detected, the duplicate benefit for the individual is assumed to be terminated, leaving the filing unit with

a reduced benefit.

As shown in Chapter III and in Appendix A, a number of State FSP and TANF agencies currently

participate in systems, such as PARIS, designed to detect interstate duplicate cases. The new national

client database is assumed to replace those existing systems. 

Ideally, the cost-effectiveness analysis would estimate the costs and benefits of existing systems,

and subtract those figures from estimates of a new national client database, yielding net costs and

benefits from replacing the existing systems with a new national client database. Unfortunately,

available data do not support estimates of the costs and benefits of existing systems. Thus, the cost and

benefits presented in this chapter are computed without subtracting any costs and benefits of existing

systems. This omission is unlikely to alter the conclusions of the cost-effectiveness evaluation. Taking

existing systems into account would reduce both the numerator and the denominator of the benefitcost ratio of the new national client database. If existing systems are assumed to have a benefit-cost

ratio of 1, then the same number would be subtracted from both the numerator and the denominator

of the benefit-cost ratio of the national client database. If the gross benefits of a national client

database exceed gross costs, then such an adjustment cannot reverse the conclusion that the national
29

client database is cost-effective. The sensitivity of the gross benefit-cost ratio to this omission is

discussed later in the chapter.

ANALYSIS

Table IV.2 presents the detailed assumptions and data supporting the figures in Table IV.1. Table

IV.2 also lists the source of each figure. Each section of Table IV.2 presents the derivation of one line

of Table IV.1. The line numbers in Table IV.2 refer to line numbers in Table V.1.

Each type of cost and benefit is presented in Table IV.1. It is divided into three panels (from top

to bottom): costs, benefits, and the difference between benefits and costs, labeled net benefits. The

cost panel presents development and operating costs. The bottom of the cost panel presents the cost

over the system life cycle. Costs in FY 2000 include only development costs; costs in subsequent years

include only operational costs. System maintenance costs are included in operational costs. 

Operational costs are inflated by 4.5 percent each year. The result is a total life-cycle cost of $39

million. A detailed explanation of the cost assumptions is presented in Appendix E.

The benefits panel of Table IV.1 includes recovered benefits and avoided benefits. The bottom

of the benefit panel presents a projection of the benefits over the system life cycle. No benefits are

assumed during the year of system development. All the recovered benefits are assumed to accrue in

the first year of the system lifecycle. Recovered benefits result from detecting cases that remained

undetected in the past. We assume that when the national client database begins operation it will

review each State agency’s entire caseload, looking for previously undetected duplicate benefits. Each

State agency then processes these retrospective duplicate cases, recovering some of the past

overpayments.
30

Table IV.1. Projected Costs and Benefits of a Tracking System

Costs

Development (millions of FY 2000 dollars)

 1. Central facility $8.7

 2. Federal management, monitoring, and oversight $0.8

 3. State system development1$6.7

 4. Total development $16.2

Operations (millions of FY 2001 dollars)

 5. Central facility $2.0

 6. Federal management, monitoring, and oversight $0.4

 7. State operations1$1.7

 8. Total operations $4.2

5-Year Life Cycle Cost FY 2000 FY 2001 FY 2002 FY 2003 FY 2004 FY 2005 TOTAL

 7. Development cost $16.2 $0.0 $0.0 $0.0 $0.0 $0.0 $16.2

 8. Annual operating cost $0.0 $4.2 $4.4 $4.5 $4.8 $5.0 $22.8

 9. Total $16.2 $4.2 $4.4 $4.5 $4.8 $5.0 $39.0

Benefits

Recovered Benefits (millions of FY 2001 dollars)

 10. Food Stamps $4.4

 11. TANF $28.8

 12. Total recovered benefits $33.2

Avoided Benefits (millions of FY 2001 dollars)

 13. Food Stamps $1.9

 14. TANF $5.7

 15. Total avoided benefits $7.6

5-Year Life Cycle Benefits FY 2000 FY 2001 FY 2002 FY 2003 FY 2004 FY 2005 TOTAL

 16. Recovered benefits $0.0 $33.2 $0.0 $0.0 $0.0 $0.0 $33.2

 17. Avoided benefits $0.0 $7.6 $7.6 $7.7 $7.7 $7.8 $38.4

 18. Total $0.0 $40.8 $7.6 $7.7 $7.7 $7.8 $71.6

 Net Benefits

FY 2000 FY 2001 FY 2002 FY 2003 FY 2004 FY 2005 TOTAL

5-Year Life Cycle Net Benefits -$16.2 $36.6 $3.3 $3.1 $3.0 $2.8 $32.6

1

Includes all costs incurred by the State, and does not take into account the fact that 50 percent of the operations and

maintenance costs of FSP systems are reimbursed by FNS.

Table IV.2. Projected Costs and Benefits of a Tracking System
31

Source

Line 1

 1997 estimate $7.6 DHHS, p. 70

 Inflation rate - 4.5% per year 1.14 Assumption

Line 2

 Federal FTEs 6 Assumption

 Annual salary $70,000 Assumption

 Overhead rate 100% Assumption

 Total federal dev. cost $840,000 Calculation

Line 3

 Per State development cost $78,641 DHHS, p 74

 Per State management cost $50,000 Calculation

 State FTEs 0.5 Assumption

 Annual salary $50,000 Assumption

 Overhead rate 100% Assumption

 Total State development cost - all States $6,689,345 Calculation

Line 5

 1997 estimate $1.7 DHHS, p. 70

Inflation 1.19 Assumption

LINE 6

 Federal FTEs 3 Assumption

 Annual salary $70,000 Assumption

 Overhead rate 100% Assumption

 Total federal dev. cost $420,000 Calculation

Line 7

 State management cost $10,000 Calculation

 State FTEs 0.1 Assumption

 Annual salary $50,000 Assumption

 Overhead rate 100% Assumption

 State follow-up, claims, and data processing costs $23,052 Calculation

 Num. hits 12 States per month 554 FNS table of PARIS results

 Num. hits 12 States per year 6,648 Calculation

 Num. hits US per year 27,700 Calculation

 Cost per follow-up - verif., claims, and data proc. $42 MPR IEVS, p. 185

 Total op. cost per State $33,052 Calculation

 Total op. cost all States $1,718,720 Calculation

Line 10

 Duplicate benefits 4 States (FY96) $3,935,000 GAO/RCED-98-228, p. 5

 Projection to 50 States $11,070,990 Calculation
32

Source

 Total FSP bens. In 4 States (FY95) $8,091,836,77

7

GAO/RCED-97-54, p. 16

 Total FSP bens. US (FY95) $22,766,109,3

38

GAO/RCED-97-54, p. 16

 Percent recovered, cash plus recoupment 40% MPR IEVS, p.72

 Recovered duplicate benefits $4,428,396 Calculation

Line 11

 Duplicate benefits 4 States (96) $3,256,481 DHHS, p. 75

 Projected to 50 States $42,334,253 Calculation

 Percent recovered 68% MPR IEVS, p.72

 Recovered duplicate benefits $28,787,292 Calculation

Line 13

 Projected avoided benefits $1,472,658 Calculation

 FSP ind. den. or rem. 12 States per month 48 Unpublished table from DHHS

 FSP ind. denied or removed 12 States per year 576 Calculation

 FSP ind. denied or removed US per year 1,992 Cody and Castner, p.127

 Ave. monthly benefit per HH member (FY01) $82 GAO/RCED-98-53, p. 3

 Median length of completed FSP spell (months) 9 MPR caseload dynamics report

 Projected avoided State administrative costs $378,439 Calculation

 State admin costs per case month $21 MPR IEVS, p. 67

 Total avoided costs $1,851,097 Calculation

Line 14

 Projected avoided benefits $4,291,280 Calculation

 TANF ind. den. or rem. 12 States per month 32 Unpublshed table from DHHS

 TANF ind. denied or removed 12 States per year 384 Calculation

 TANF ind. denied or removed US per year 1,328 Calculation

 Ave. monthly benefit per HH member (FY97) $129 DHHS/ACF

 Median length of completed AFDC spell (months) 25 Bane and Ellwood, p. 32

 Projected avoided State administrative costs $1,422,630 Calculation

 State admin costs per case month $43 MPR IEVS, p.67

 Total avoided costs $5,713,910 Calculation
33

In subsequent years, however, the legacy of undetected duplicate cases will have been cleaned up,

and the national client database is assumed to detect only those cases that have newly become

duplicates. New duplicate cases are assumed to have no past overpayments to recover, that is, there

are no recovered benefits in FY 2002 through the end of the system life cycle. Avoided benefits are

assumed to accrue in each year of the system lifecycle. FSP benefits are inflated at three percent per

year, and TANF benefits remain at their current nominal levels throughout the system life cycle. The

detailed assumptions underlying the benefit assumptions are presented in Appendix E.

The bottom panel of Table IV.1 presents net benefits--that is, benefits minus costs--for each year

in the system life cycle. In FY 2000, the net benefit is negative because the system is being developed,

and there are no recovered or avoided benefits in that year. The net benefit in FY 2001 is

extraordinarily large because benefits in that year include both recovered and avoided benefits. The net

benefits in FY 2002 through 2005 contain only avoided program benefits. Over its life cycle, the costbenefit scenario yields a net benefit of $33 million, suggesting that the national data system is costeffective. Table IV.1 also indicates that a national client database would not be cost-effective if it were

developed for the FSP alone. The cost-effectiveness analysis presented here assumes the database is

developed for both programs, consistent with the functional requirements presented in Chapter III.

This analysis makes no assumption about how costs or benefits are allocated among Federal or

State agencies. An eligibility database developed by the Federal government within current funding

arrangements for FSP and TANF, however, is likely to increase Federal costs. This would occur

primarily because the savings from recovered and avoided TANF benefits would accrue only to States

under the existing block grant while the Federal government would bear most of the developmental

and operational costs.

As shown in Appendix E, the assumptions underlying these figures are numerous and complex.

The conclusion that a national client database is likely to be cost-effective may be seen more intuitively

by reviewing the key assumptions underlying the benefits side of the ledger. The benefit figures in

Table IV.1 are largely driven by the assumed number of interstate duplicate cases detected by the

national client database, the number of months those detected duplicate cases would have received

benefits had they not been detected, and the dollar amount of program benefits received by the

duplicate cases per month. The first figure is estimated from the number of duplicates found by the

PARIS system. The second and third figures are estimated based on FSP and TANF administrative

data. 

The product of the number of duplicated cases, the expected duration of those cases, and the

benefits avoided per case per month is the amount of avoided program benefits. To this figure we add

estimated administrative cost savings due to the detected individuals no longer being on the caseload,

based on monthly case maintenance costs. The calculation suggests that avoided program expenditures

per year would be on the order of $7.6 million. Since annual operating costs are estimated to be on

the order of $4.2 million, the national client database is seen to be cost-effective from the perspective

of its ongoing operation.
34

SYSTEM ARCHITECTURE

The cost-benefit analysis is based on the eligibility database architecture for a national client

database. Chapter III showed that this system architecture fulfilled, and did not exceed, the functional

requirements for the national client database. Another possible system architecture is the one-stop

database, whose only disadvantage is that it provides several program functions that are not required

for the national client database. 

The cost-effectiveness of the one-stop database architecture is tested by substituting the cost of

development and operations, estimated by DHHS, into the calculations described above for the

eligibility database. This approach assumes that the one-stop architecture is equally effective at

detecting duplicate cases as is the eligibility database architecture. It also assumes there is no benefit

to the performance of income and asset verification and eligibility-related functions performed by the

one-stop architecture, since these functions are not required for the national client database.6 This test

indicates that the one-stop database architecture yields life-cycle savings of $27 million, which is the

difference between benefits of $72 million and costs of $45 million. The one-stop database architecture

is shown to be cost-effective, but less cost-effective than the eligibility architecture.

Similar tests are not performed for the file match, broadcast, and eligibility index architectures for

two reasons. First, Chapter III shows that none of these architectures provides the minimum set of

functional requirements. This means that their cost-effectiveness is irrelevant to the decision of

whether or not to develop the national client database. Second, Chapter III also shows that the only

datum each of these architectures provides State agencies is the SSN of duplicate cases. This means

State agencies would have to prepare as many as fifty separate case record extract requests for other

State agencies, which in turn would have to respond to such requests from all State agencies by

preparing fifty separate case record extract files. The requesting State agency would then merge as

many as fifty separate case record extract files. This process would be repeated each month.

Although the costs to State agencies of such an arrangement are likely to be great, available data

do not support the estimation of such State agency costs. Without estimates of these costs, estimating

the cost-effectiveness of these three architectures is not possible. However, requiring each State agency

to produce, exchange, and interpret several data files with every other State agency every month is so

inefficient on its face that we can conclude they are substantially less cost-effective than either the

eligibility database or one-stop database architectures.

SENSITIVITY OF THE RESULTS TO KEY ASSUMPTIONS

 

6

If the national client database is expanded in the future to include IEVS and support for eligibility determination, the benefits

from these functions would be included in the cost-effectiveness assessment.
35

Since the above estimates depend on several unverified assumptions, it is important to estimate

how sensitive the estimates are to those assumptions. Specifically, this section presents the sensitivity

of the cost-benefit results to two key assumptions:

ß The duration of the duplicate spell of FSP and TANF participation avoided by being

detected by the national client database system

ß The monthly duplicate FSP and TANF benefit amount avoided by being detected by the

national client database system

DURATION OF DUPLICATE SPELL

The method of testing the sensitivity to the assumed length of the avoided duplicate spells of

participation is to reduce the assumed FSP and TANF spell lengths until the benefits are reduced to

equal costs. As shown in Table IV.2, the length of avoided FSP spells is assumed to be 9 months and

the length of avoided TANF spells is assumed to be 25 months. For the sensitivity test, these figures

are reduced by the same proportion, for example, by dividing each figure by 2, until life-cycle benefits

are reduced to equal costs.

The result of the test is that the length of avoided FSP spells must be reduced to 1.35 months, and

avoided TANF spells to 3.75 months, before life-cycle benefits are reduced to equal costs.

MONTHLY DUPLICATE BENEFIT AMOUNT

A similar approach is taken to testing the sensitivity of the cost-benefit results to the assumed

amount of the avoided monthly FSP and TANF benefits. Table IV.2 indicates that average per person

monthly food stamp payments of $82 and TANF payments of $129 are avoided when duplicate

benefits are detected. The sensitivity test consists of reducing these two figures by the same proportion

until life-cycle benefits are reduced to equal costs.

The sensitivity test shows that avoided monthly benefit amounts could be reduced to zero without

reducing benefits to equal costs. This is because the combination of recovered benefits and avoided

administrative costs exceeds the cost of the client database. In this test, administrative costs remain

constant, because the length of the avoided spell is assumed to be unaffected by reductions in the

avoided monthly benefit amount.

FINDINGS

ß If developed for both the FSP and TANF, it is likely that the use of an eligibility database

architecture would be cost-effective. However, it would not be cost-effective if it were

developed for the FSP alone. If a national client database for the FSP and TANF programs

is configured using the DHHS ‘eligibility database’ system architecture, the estimates suggest
36

that it would be cost-effective, yielding a net five-year life-cycle benefit of $33 million. This

net figure is the difference between gross benefits ($72 million) and costs ($39 million) for the

assumed five years (FY 2001 through FY 2005) of the system life cycle.

ß The ‘one-stop database’ is also cost-effective, with an estimated life-cycle net savings of $27

million. The cost-effectiveness of the other three architectures cannot be estimated due to

the paucity of appropriate data. 

ß The cost-effectiveness results were tested for their sensitivity to two key assumptions– the

length of avoided spells of participation and the avoided monthly benefit amount. The first

showed that the duration of avoided food stamp spells could be reduced to 1.35 months, and

that avoided TANF spells could be reduced to 3.75 months before the national client database

ceased to be cost-effective. The second assumption showed that the amount of the avoided

monthly benefit could be reduced to zero without making costs exceed benefits.

The following additional data is required in order to increase the reliability of estimating the costs

and benefits of a national client database.

ß A technical design of the national client database

ß Estimates of the number of interstate duplicate cases in the States for which no estimates

are currently available.

ß Data on the characteristics of interstate duplicate cases, including demographics, the

number of months receiving FSP and TANF benefits, and the size of their benefit

amount.
37

CHAPTER V

SAFEGUARDS TO PROTECT AGAINST UNAUTHORIZED

DISCLOSURE OR UNINTENDED USE OF A

NATIONAL DATABASE

A national client database must contain safeguards to the privacy of the data. A national client

database would include confidential information on FSP and TANF recipients. Three of the five

system architectures – file match, broadcast, and eligibility index – would include the SSN of recipients.

 The eligibility database architecture would include SSN, current and past program participation, and

current and past employment. The one-stop database architecture would include all the data in the

eligibility database plus income, assets, and other data items used in determining eligibility for program

benefits.

This chapter discusses available disclosure safeguards and the potential risk to privacy of a national

client database.

One threat to data security is the risk of the unauthorized disclosure of information. This could take

the form of a caseworker inadvertently releasing the data on one beneficiary to another beneficiary;

or data obtained by a hacker who accesses the database surreptitiously. It could also be more

systematic, such as a State agency making information available to marketing firms or collection

agencies.

A second threat to data security is unintended use of the data. Disclosure of confidential data can

also be indirect, such as using the data for a programmatic purpose other than that for which for it was

provided. For example, law enforcement agencies or the Internal Revenue Service (IRS) might want

to use the national client database for purposes outside of administering the FSP or TANF programs.

 Using the data in this way often involves matching the original database with another database owned

or sponsored by the other agency. 

Safeguards to protect against the risk of unauthorized disclosure or unintended uses must take into

account the ownership of the data. The owner of the data is legally responsible for safeguarding the

privacy of individuals represented in the data. State agencies administer the FSP and TANF programs,

and therefore own the data for a specific beneficiary. A national client database would involve sharing

confidential data with public agencies in other States and, under most scenarios, one or more federal

agencies. 
38

To secure the data strategies must be included when developing the database that can effectively

reduce privacy risk. Three types of safeguards (contractual, security and legal) are appropriate for a

national client database.

Contractual Safeguards. These safeguards can include agreements between and among State

and federal agencies using the national client database in which each agency agrees to maintain the

confidentiality of data it receives through the national client database from other State agencies. Such

contractual agreements require the receiving agencies to implement specific security safeguards to

protect those data from both unauthorized disclosure and unintended uses. Certification by the agency

receiving the data would fulfill the privacy law of the State providing the data. Implementing such

safeguards may require each State and federal agency to have such an agreement with every other State

agency.

A variety of other public programs involve disclosing confidential data owned by one State agency

to other federal and State agencies. The experience of these programs indicates that bilateral

contractual agreements among participating agencies are effective at extending the legal responsibility

for safeguarding the data to the receiving agency. FNS is not aware of any instances in which receiving

State agencies have released or disclosed data in violation of such agreements. The cumbersome

process of negotiating bilateral agreements among over fifty agencies may be facilitated by a federal

agency publishing a model agreement to all State FSP and TANF agencies.

Security Safeguards. Any national client database would have physical, electronic, and procedural

barriers to unauthorized access. Physical security includes guards at the doors to the facility and locks

on the rooms in which data are stored. Electronic safeguards might include the use of passwords to

log onto the information system, and using electronic firewalls to segregate the database from other

components of the local area network. Procedural safeguards include logging the chain of custody of

printouts and electronic media containing confidential data.

Security safeguards, such as the use of passwords, electronic firewalls, locked rooms and cabinets,

security procedures, and security training of personnel, can be effective in preventing unauthorized

physical or electronic access to the database. With respect to unauthorized disclosure, the national

client database can essentially be as secure as the sponsoring agency is willing to pay for. As indicated

by Circular A-130 of the Office of Management and Budget, a comprehensive risk assessment is an

essential step in the design and development of a national client database. Based on such an assessment

and the estimated cost of various level of security safeguards, the sponsoring agency would specify the

security requirements for the national client database. The database developer, as well as participating

State agencies, would be required to implement the required security safeguards.
39

Legal Safeguards. These are State and federal laws that impose penalties for the unauthorized

disclosure or use of confidential data, and that specify procedural safeguards against unintended uses

of the data. The main federal laws are the Privacy Act of 1974,7 and the Computer Matching and

Privacy Protection Amendments of 1988.8 Nearly all States also have some sort of privacy laws, but

their provisions vary widely. Legal safeguards address both the unauthorized disclosure and unintended

use problems. Through appropriate security safeguards, the risk of unauthorized disclosure can be

reduced to any desired level. (See Appendix F for an overview of the privacy laws).

If a national client database is configured as a federal system of records, federal privacy laws would

prevail, otherwise safeguarding the security of the data would be the responsibility of the agency

maintaining the system of records. Comparing federal privacy laws to State privacy laws suggests that

federal laws would safeguard the privacy of individuals represented in a national client database more

effectively than would State laws. The federal Privacy Act requires stronger protections than do the

privacy laws in many States, and the uniformity and consistency of a single federal standard would avoid

interstate disputes and unequal treatment of recipients. Thus, risks to privacy are minimized if the

national client database is a federal system of records.

The Privacy Act applies to federal agencies that maintain personal information in a system of

records. The national client database is a system of records because it contains personal information

retrieved by an individual identifier.9 The national client database would be a federal system of records

if it is developed and operated by a federal agency, or if it is sponsored and funded by a federal agency

through a contract to a private organization of a State agency. 

CONCLUSIONS

Privacy safeguards could be developed and put in place that would be adequate for the

development and operation of a national client database.

Contractual agreements between States can solve the problem of disclosing confidential data

owned by one State to an agency of another State. Physical, electronic, and procedural security

safeguards can protect the national client database from unauthorized physical and electronic access.

The unevenness of State privacy laws suggests that the privacy of the data in the national client

database should be protected by federal privacy laws. This implies that a national client database should

be construed as a federal system of records, and that the development and operation of the database

be funded by a federal agency.

The protection provided by the Privacy Act against the risk of unintended uses could be

maximized in the following ways:

ß The responsible federal agency could define the routine uses of the national client

database so they were tailored to the program’s needs.

 

7

5 U.S.C. 552a (1994).

8

Public Law 100-503, 102 Stat. 2507.

9

 Id. at (a)(5).
40

ß The data-use agreements and matching agreements between and among State agencies

could define acceptable uses of data derived from the national system for the specific

purposes intended.

ß The federal agency responsible could establish a data integrity board for the national client

database, the majority of whose membership should consist of independent outside

experts. The board should be charged with the responsibility of vigorously monitoring

the risk of unintended uses of the data.
41

CHAPTER VI

CONCLUSIONS

This report responds to the requirements of Section 2(a) of P.L. 105-379. In particular, it

investigates the functional requirements, feasibility, and cost-effectiveness of a national client database,

as well as the privacy issues associated with such a database. The report extends a previous

investigation of a national client database by DHHS by adding the requirements of the FSP to those

of TANF, and by offering a more comprehensive cost-effectiveness assessment. This chapter presents

the key findings from this investigation and potential future directions of this inquiry.

KEY FINDINGS

CURRENT STATE ACTIVITY IN DETECTING INTERSTATE DUPLICATE BENEFITS

A USDA survey in 1999 of State FSP agencies indicates that the large majority of States (38) have

participated at least once in the past several years in an interstate match designed to identify interstate

duplicate FSP cases. Twenty-five State FSP agencies routinely conduct such matches for interstate

duplicate FSP cases. The largest existing system for detecting interstate duplicate TANF cases is the

PARIS system. Twenty-two State TANF agencies at one time or another in the past several years

participated in PARIS, and 13 State agencies participate currently. 

STATE CAPABILITIES TO PARTICIPATE IN A NATIONAL CLIENT DATABASE

USDA conducted in-depth interviews with officials in the FSP agencies of seven States regarding their

capability to participate in a national client database. Each agency reported having the capability to

participate in such a database. The officials assumed the centralized portion of the database would be

developed and operated by a federal agency. They also realized they would need to develop and

operate the State agency portion of the system. However, they assumed the system would be designed

so that the State agency’s activity would be limited to preparing and sending an extract of its case

records to the central facility, receiving case record extracts from the central facility, and verifying and

following up on the matched cases. Under this assumption,
42

the officials felt that developing and operating their portion of the national client database would not

be difficult.

These conclusions are based on interviews with FSP administrators from seven States. The seven

States should not be viewed as a statistically representative sample of all States, and thus these

conclusions cannot be generalized to all State agencies. However, the data suggest States’ capabilities.

 USDA is currently conducting a comprehensive survey of all State FSP agencies on their computer

capabilities.

FUNCTIONAL REQUIREMENTS

The functional requirements of the national client database are to provide data to State FSP and

TANF agencies sufficient to detect interstate duplicate FSP and TANF benefits and to enforce the

ABAWD and TANF time limits. 

FEASIBILITY

A national client database is feasible if it is configured using an eligibility database or a one-stop

database architecture. Feasibility is defined as follows: the system is consistent with the functional

requirements; the centralized component of the database can be developed and operated with minimal

technical risk and at reasonable cost; and the State agency component of the database can be developed

and operated at a reasonable cost and without requiring large increases in staffing.

The DHHS report proposed five alternative system architectures for the national client database.

 Of these five, the file match, broadcast, and eligibility index architectures do not provide the minimum

functional requirements for the national client database. In particular, they do not provide State

agencies with the data necessary to enforce ABAWD or TANF time limits. In addition, they require

State agencies to exchange case record extracts bilaterally with every other State agency, potentially

requiring Stage agencies to increase their current staff size. The fourth alternative, the eligibility

database, meets all of the functional requirements. The one-stop database architecture exceeds the

functional requirements by verifying client-reported income and asset information and by performing

some eligibility functions. Thus, both the eligibility database and the one-stop database architectures

meet the feasibility criteria. 

COST-EFFECTIVENESS

Available data are inadequate to estimate the costs or benefits of a national client database reliably.

 However, calculations using the data that are available, supplemented by a number of assumptions,

suggest that a national client database is cost-effective if it is developed for both the FSP and TANF

program and configured using an eligibility database or one-stop database architecture. It would not

be cost effective if it were developed for the FSP alone. This conclusion holds even though in the

calculations the benefit portion of the benefit-cost ratio is limited to detecting interstate duplicate FSP
43

and TANF cases and excludes the benefit from enforcing ABAWD and TANF time limits across State

boundaries. 

This analysis makes no assumption about how costs or benefits are allocated among Federal or

State agencies. An eligibility database developed by the Federal government within current funding

arrangements for FSP and TANF, however, is likely to increase Federal costs. This would occur

primarily because the savings from recovered and avoided TANF benefits would accrue only to States

under the existing block grant while the Federal government would bear most of the developmental

and operational costs.

The cost-effectiveness of the file match, broadcast, and eligibility index architectures cannot be

estimated. However, they cause the State agency component of the system to be substantially less

efficient than under the eligibility database or one-stop database architectures. This loss of efficiency

means that these three architectures would be less cost-effective than the eligibility database or onestop database architectures. 

The one-stop architecture may be less cost-effective than the eligibility index because it is more

expensive to develop and operate. The extra expense of the one-stop architecture results from its

providing two major programmatic functions that are not required for the functional requirements for

a national client database. 

PRIVACY

A national client database raises concerns about protecting the privacy of FSP and TANF clients.

 Privacy concerns fall into three categories. The first is that FSP and TANF data are owned by the

State agencies providing benefits to the FSP or TANF case, and may not be disclosed to an agency of

another State or federal agency. The solution to this problem is to execute privacy agreements between

every pair of State agencies and the sponsoring federal agency.

The second category of privacy concerns is unauthorized physical or electronic access to the

national client database. This threat to security could be controlled by building physical, electronic, and

procedural safeguards into both the centralized component and the State agency component of the

database.

The third category of privacy concern is the threat of authorized but unintended uses of the data.

 This risk to client privacy is the most difficult to control. The wide variation among State privacy laws

suggests that this risk is minimized by construing the national client database as a federal system of

records and therefore subject to the Privacy Act and the Computer Matching and Privacy Act.

FUTURE DIRECTIONS

This investigation revealed potential concerns that should be further investigated If a decision to

develop a national client database is made, two considerations affect how rapidly development can

start. First, adequate time must be allowed to appropriate sufficient funds to the primary federal agency

managing the effort. Second, time must be allowed for the agency to either hire and organize qualified
44

staff with appropriate expertise and/or pursue the procurement processes involved in soliciting and

choosing a national database contractor.

PROGRAM GOVERNANCE ISSUES

Consistent with the fact that both the food stamps and TANF programs are administered by State

agencies, the federal government has never maintained a national client database of individual welfare

clients. With few exceptions, when a federal agency needs access to client data, it must request the

permission of the relevant State agency. Throughout the history of these programs, State agencies have

born the entire responsibility for maintaining databases of client records.

The development of a national client database may raise questions about whether the federal

government is becoming more directly involved in the administration of these two programs. 

Assuming that a national client database is not intended to alter the governance of the food stamps and

TANF programs, the sponsoring agency should consider developing regulations limiting the federal

government’s use of the centralized component of the database to the detection of duplicate cases and

the enforcement of PRWORA time limits.

A related concern is the public perception of the federal government having direct access to

personal data heretofore maintained by State agencies. With a federally sponsored national client

database, the federal government would for the first time maintain a national database of individuals

who received benefits from a means-tested program at any point in their lives. for administrative, as

opposed to research, purposes. This concern may be exacerbated by the need to store data for the

enforcement of TANF time limits. The TANF time limit is defined in terms of the lifetime of the

recipient. The national client database will have to accumulate data on TANF participation throughout

the recipient’s adult lifetime, perhaps over forty years. This means that the database may eventually

contain a record for each individual who ever had a spell of TANF receipt during their lives. The rates

of mobility into and out of poverty and welfare receipt that have been observed over the past few

decades imply that the national client database may eventually contain records on a substantial fraction

of the adult population of the U.S.

This concern suggests that the concept of a national client database be explored with State

governments, particularly FSP and TANF agencies, as well as public interest associations. The concern

may be at least partially addressed by drafting regulations that limit the ability of the federal government

to use the national client database for unintended purposes. It may also be addressed by adopting an

index and retrieval architecture such that case record data are never stored in the central component

of the database.
45

PAGE IS INTENTIONALLY LEFT BLANK TO ALLOW FOR DOUBLE-SIDED COPYING
46

REFERENCES

Bane, Mary Jo, and David T. Ellwood. Welfare Realities: From Rhetoric to Reform. Cambridge, MA:

Harvard University Press, 1994.

Cody, Scott, and Laura Castner. “Characteristics of Food Stamp Households, Fiscal Year 1997.”

Washington, DC: Mathematica Policy Research, Inc., February 1999.

Fasciano, Nancy, and Sheena McConnell. “The Cost Effectiveness of the Income and Eligibility

Verification System in Arizona and Michigan.” Washington, DC: Mathematica Policy Research,

Inc., April 1, 1995.

Gleason, Philip, Peter Schochet, and Robert Moffitt. “The Dynamics of Food Stamp Program

Participation Program Participation in the Early 1990s.” Washington, DC: Mathematica Policy

Research, Inc., April 1998.

U.S. Department of Health and Human Services. Temporary Assistance for Needy Families: Report on Data

Processing. Washington, DC, December 1997.

______________. Temporary Assistance for Needy Families (TANF) Program: First Annual Report to Congress.

Washington, DC, August 1998.

U.S. General Accounting Office. Food Stamp: Substantial Overpayments Result from Prisoners Counted as

Household Members. GAO/RCED-97-54. Washington, DC, March 1997.

______________. Food Stamp Overpayments: Thousands of Deceased Individuals Are Being Counted as Household

Members. GAO/RCED-98-53. Washington, DC, February 1998.

_____________. Food Stamp Overpayments: Households in Different States Collect Benefits for the Same

Individuals. GAO/RCED-98-228. Washington, DC, August 1998.
APPENDIX A

CURRENT INTERSTATE MATCHNG FOR

DUPLICATE PARTICIPATION
A-1

Table A.1. Current Interstate Matchng For Duplicate Participation

State

Conducts Routine Interstate

Matching of Food Stamp Records

Frequency

 

PARIS

Participant

Alabama No

Alaska No

Arizona California

Nevada

Quarterly

Annually

Yes1

Arkansas Informal match with Texas

Planned matches with

Oklahoma, Louisiana

Mississippi, Texas

California Border counties in Nevada (El

Dorado, Alpine, Nevada)

Unknown Yes

Colorado Unknown Unknown Yes

Connecticut Massachusetts Quarterly Yes

Delaware Pennsylvania

New Jersey

Maryland

Unknown

District of Columbia Maryland Unknown Yes

Florida New York

New Jersey

Georgia

Annually Yes

Georgia (Florida conducting the match) Unknown Yes

Guam No Yes

Hawaii No

Idaho No

Illinois Testing match with Wisconsin

Pennsylvania

Yes

 

1

 Has either participated in PARIS for at least one match or is a participant in the August 2, 1999

match.
A-2

State

Conducts Routine Interstate

Matching of Food Stamp Records

Frequency

 

PARIS

Participant

Indiana No?

Iowa Missouri Unknown Yes

Kansas Missouri Unknown Yes

Kentucky No Yes

Louisiana Texas Monthly Yes

Maine Massachusetts Quarterly

Maryland District of Columbia

Pennsylvania

Delaware

Virginia

West Virginia

Unknown

Quarterly

Unknown

Unknown

Unknown

Yes

Massachusetts Connecticut

Maine

New York

Rhode Island

New Jersey

Florida

Puerto Rico

New Hampshire

Quarterly

Monthly

Yes

Michigan No Yes

Minnesota No

Mississippi Planned match with Arkansas

Missouri Kansas

Iowa

Unknown Yes

Montana Unknown

Nebraska Unknown Yes

Nevada Arizona

Border counties with California

New Hampshire Massachusetts Monthly
A-3

State

Conducts Routine Interstate

Matching of Food Stamp Records

Frequency

 

PARIS

Participant

New Jersey 

 

Pennsylvania

Delaware

New York

Massachusetts

Maryland

Quarterly

Unknown

Yes

New Mexico 

 

Texas (border counties)

(has access to Texas automated

client database. Dona Ana and

Southern Dona Ana offices have

direct access to information on

active cases in Texas. Plans are

to add Curry, Eddy, Roosevelt and

Lea offices). Also matches active

FS clients with active expedited

service clients in Utah.

Quarterly Yes

New York 

 

Massachusetts

Pennsylvania

Virginia

Florida

Puerto Rico

New Jersey

Connecticut

Maryland

North Carolina

Vermont

Ohio (planned)

Quarterly

Semi-annually

Yes

North Carolina 

 

New York Yes

North Dakota 

 

Unknown

Ohio 

 

New York (planned) Yes

Oklahoma 

 

Texas

Arkansas

Yes

Oregon 

 

No

Pennsylvania 

 

Delaware

Maryland

New Jersey

New York

Florida

Illinois

Once in 1996

Quarterly

Semi-annually

Quarterly

Semi-annually

Monthly

Yes
A-4

State

Conducts Routine Interstate

Matching of Food Stamp Records

Frequency

 

PARIS

Participant

Puerto Rico Massachusetts

New York

Rhode Island 

 

Massachusetts

South Carolina. 

 

No Yes

South Dakota 

 

Unknown Yes

Tennessee 

 

No Yes

Texas 

 

Louisiana

Oklahoma

New Mexico

Yes

Utah Matches active FS clients with

active expedited service clients in

New Mexico

Yes

Vermont New York

Virgin Islands 

 

No

Virginia 

 

Maryland Unknown Yes

Washington 

 

No Yes

West Virginia 

 

Maryland Unknown

Wisconsin 

 

Testing match with Illinois and

Iowa

Wyoming Unknown
B-1

APPENDIX B

SELECTION OF STATES FOR INTERVIEWS

ABOUT STATE CAPABILITIES

The client database study required obtaining information on States’ capabilities to establish and

effectively use a national database system capable of tracking participants in means tested assistance

programs. Information was obtained from available sources and supplemented by telephone interviews

with knowledgeable staff in seven selected States: Arizona, Arkansas, Florida, New Jersey, New York,

Pennsylvania, and Utah.

FNS staff selected seven States to be interviewed. This appendix describes the methods used in

the selection process. The selection was a sequential process.

The first step was to identify basic capabilities that States should have in order to effectively access

and use a national client tracking database. Next, general characteristics of the States and their

operations that would form the basis for selection were defined. A Master list of States that met most

of the basic requirements for inclusion in the sample was then created. The master list was developed

by staff from the Office of Analysis, Nutrition and Evaluation; the Food Stamp Program, Program

Accountability Division (PAD); and Financial Management. The Food Stamp Regional offices were

asked to comment on the list, make additions, suggest deletions; and identify preferences if any. 

States were over-sampled to control for those on the list that were unable to participate in the

study. All States on the master list were good candidates for the study. 

STEP 1: BASIC STATE CAPABILITIES

The subsections below highlight the State capabilities used to consider which states to place on

the master list. Data used was from the 1991 State census of selected program operations (STOPS).

ß State Has an Automated Certification and Case Management System. Only three States,

Montana, Minnesota and California, did not have an automated certification and case

management (ACS) system at the time the STOPS data were collected. All three had plans to

implement at that time.
B-2

ß Maintain Historical Data. Based on the STOPS data, historical data were maintained as part

of the case management operation in all but 6 States. Of those six, four archived case data.

Three States - Montana, Minnesota and California--reported that historical data were not

maintained statewide.

ß Content of the Data Stored (1) Include at a Minimum the client’s SSN, Name and Date

of Birth; and (2) The Individual as the Unit of Analysis of Data Stored in Database.

In all the States the Social Security Number (SSN), name, address and birthdate of the head

of household is either stored in the database or used as an identifier. In all but one State,

individual information stored in the database included SSN, name and date of birth. 

Individuals identified in the database included the head of household, spouse, other adults and

children in all but six States. In Alabama and the Virgin Islands only the head of household

was identified. There was no information on the three States that did not have a State

automated systems at the time of the census. In Colorado, Oregon and Texas there was no

spouse identified.

ß Database Integrated With Other Assistance Programs Especially TANF. In 1991 only

11 States did not have an integrated database.

STEP 2: KEY FACTORS CONSIDERED IN DEVELOPING THE MASTER LIST FOR STATE SELECTION

The following operational issues were considered in developing the master list:

ß Administration of the Program. At a minimum, it was desired that one State be included

that was State administered and one State that was county-supervised. 

ß Error Rate Based on 1998 FNS Data. The average error rate for all States was 9.75. The

range was 3.04 to 14.55. States on the master list have error rates between 5 and 13. 

ß Caseload Size is a Factor in Case Management Effectiveness. States with larger caseloads

tend to include at least one large urban project area. States designated as large and small are

both included in the master list.

ß Whether a State is Currently Engaging in Some Form of Interstate Matching. It was

believed to be important to include states with interstate matching experience and whether a

State had participated in PARIS.

OTHER FACTORS THAT WERE CONSIDERED
B-3

The following other factors were considered:

ß Willingness to Participate. Because of time constraints of the study several States that have

participated in similar operations studies and appeared to meet most of the criteria for

selection were included in the master list.

ß Usefulness as a Model for Other States. The master list included States that appear to have

the capability to engage in interstate matching for duplicate participation. 

ß Representative Distribution of States Across Regions. To the extent possible the States

on the master list include at least one State from each of the Regions.

MASTER LIST
B-4

State2 FNS Regional Office

Georgia SERO, Southeast Regional Office

Pennsylvania MARO, Mid-Atlantic Regional Office

New York NERO, Northeast Regional Office

Florida SERO, Southeast Regional Office

Ohio MWRO, Midwest Regional Office

New Jersey MARO, Mid-Atlantic Regional Office

Massachusetts NERO, Northeast Regional Office

Utah MPRO, Mountain Plains Regional Office

Tennessee SERO, Southeast Regional Office

Arizona WRO, West Regional Office

Alabama SERO, Southeast Regional Office

Missouri MPRO, Mountain Plains Regional Office

Nebraska MPRO, Mountain Plains Regional Office

Arkansas SWRO, Southwest Regional Office

Rhode Island NERO, Northeast Regional Office

Arizona is in WRO; it was a participant in both the IEVS targeting study and the

Claims threshold study.

Arkansas is in SWRO, and was selected because it had a low error rate and the

database system was not integrated.

Utah is in MPRO, and was selected because it has a fairly low error rate, is a small

State, does not conduct interstate matching.

New York is in NERO, and was selected because it does extensive interstate

matching, is county administered, is a large State and its error rate is relatively

high. New York also participated in the Finger Imaging study.

New Jersey is in MARO; and was selected because it does extensive interstate

matching, is county administered; has a large urban project area and it participated

in the Claims study.

Florida is in SERO; and was selected because it does some interstate matching, is

planning on being part of PARIS.

Pennsylvania is in MARO; and was selected because it does interstate matching, is

a large State with urban project areas, is State administered and has participated

in several of FNS’ operations studies.

 

2 California and Minnesota were originally proposed but dropped from the list since they do not have a statewide

automated certification and case management system.
C-1

APPENDIX C

NATIONAL CLIENT DATABASE ARCHITECTURES

PROPOSED IN THE DHHS REPORT

FILE MATCH

Under this alternative, State agencies would send files with minimal information about each TANF

recipient to a central location on a quarterly basis. Each record in the file would be between 40 to 50

bytes in size and would contain a recipient’s social security number (SSN), the recipient’s name, and

a two character originating jurisdiction code. The system would combine all of the SSNs and names

from all States into a single file and sort them by SSN. In this way the system could easily detect

SSN/name matches that appeared in more than one State. The system would inform each affected

State agency that a match existed with one or more other States. The State agency would be

responsible for contacting every other affected agency to determine if duplicate participation, time

limits or other issues warranting investigation existed. Once the files were matched and the duplicate

SSNs were found and reported, the system would erase the data file and start over with new State files

in the next quarter. Thus, there would be no standing repository of information on program

participants.

It would require each State agency to create a file of all new applicants, as well as active and past

recipients. DHHS estimated that the total size of the file to be matched in the tenth year would be

about 1.5 gigabytes.

This alternative would also require State agencies to validate all SSN/name combinations through

the use of the Federal Social Security Administration’s (SSA) State Verification and Exchange System

(SVES) and other services. State files would be transmitted using Connect:Direct at a prescheduled

time once each quarter to a central location that would house the FACTS computer and data. The

matches would be identified and transmitted within a week of the receipt of all State welfare agency

TANF applicant/recipient records. The system itself would consist of a commercial relational database

management system (RDBMS) to merge the TANF applicant/recipient files from all jurisdictions.

States would be responsible for using whatever means they chose to exchange detailed case record

information among themselves, including electronic file transmission, magnetic tape shipment, FAX,

or U.S. Postal Service delivery.
C-2

BROADCAST

In this approach, there would be no centralized client database. The only function of the central

Federal agency or other entity would be to facilitate interstate communication through the

establishment of standard message formats and communication protocols. The central entity would

provide each State agency the instructions for how to transmit names and SSNs to every other State

agency. The information would be sent to other State agencies for each new applicant or recertified

recipient. Responses from other State agencies to the query could be routed back through the same

communications protocol or through contact by other means, such as telephone or fax. As with the

file match alternative, the broadcast alternative would require States to validate all SSN/name

combinations through SVES and other services. The information broadcast -- name, SSN and State

Code -- would also be identical to that used in the file match alternative.

State agencies could determine the frequency that they broadcast information to other agencies.

 This approach assumes that agencies receiving a file from another agency would be required to review

the lists and respond by the transmitting the relevant information back to the originating agency within

five days.

State agencies would be responsible for using whatever means they chose to exchange detailed case

record information among themselves, including electronic file transmission, magnetic tape shipment,

FAX, or U.S. Postal Service delivery.

ELIGIBILITY INDEX

Under this alternative, State agencies would transmit a minimum set of information on each

participant to a central database. The information would be identical to that shared under the file

match and broadcast alternatives -- SSN, name, and State code. Unlike the file match alternative,

however, the system would maintain a permanent data file of participants. After initially sending in the

identifying information on their entire historical caseload, agencies would submit only the identity of

a new applicant or recertified recipient. The system would match the SSN against the existing national

data file to determine if a match existed.

As with the file match and broadcast alternatives, the eligibility index alternative would require

State agencies to validate all SSN/name combinations through SVES and other services. Also as in the

file match and broadcast alternatives, the State welfare agencies would communicate among themselves

by other means and exchange required information to implement the TANF tracking requirements.

The only functional distinctions between this alternative and the file match alternative are that the

eligibility index alternative would:
C-3

ß Maintain a permanent file of the identification of benefits recipients.

ß Only require State agenceis to transmit identifying information on new applicants and

recertified cases, rather than the entire caseload after the initial loading of the index file.

ß Provide more timely information to State agencies because, rather than waiting for a quarterly

national match to take place, the system could respond to inquiries with matching information

within a few days.

ELIGIBILITY DATABASE

Under this alternative, State agencies would transmit detailed case information to a central data

base. In contrast to the index file which, would only contain SSN, name, and State code, the eligibility

database would also contain benefit begin and end dates whether benefits were paid and exemptions

granted. This alternative would also notify any State agency when an eligibility check is performed by

another State agency. This notification could avoid, as opposed to detect, duplicative payments. This

alternative would also add the ability to generate program management reports.

As with the three alternatives discussed previously, the eligibility index alternative would require

State agencies to validate all SSN/name combinations through the use of the SSA’s SVES and other

services.

As with the eligibility index alternative, State agencies would initially populate the database with

their historical caseload data, except that they would transfer more detailed records on each case in this

alternative. Agencies would then provide records on a daily or weekly basis for cases with newly granted

program benefits, terminated benefits, or other changes in benefit eligibility status. The system would

have the capability to transfer these update records to other State agencies where an SSN match occurs.

 The system would retain data for several decades from date of receipt.

State agency follow-up burden would be significantly reduced under this alternative, because

agencies would be able to determine if a high probability of an eligibility denial issue existed prior to

requesting information from other States. Agencies would still be required to confirm the validity of

any data used to deny benefits by contacting other States. States would exchange any additional

information needed to confirm duplicate payments or deny eligibility through such means as electronic

file transmission, magnetic tape shipment, FAX, or U.S. Postal Service delivery.

ONE-STOP DATABASE

Under this alternative, the system would not only enable State agencies to access detailed case

records from other States, but also eligibility verification data from other federal systems. The system
C-4

would store additional data elements such as alien, fugitive felon, drug felon, parole violation, and

probation violation status. The alternative would include the capability of:

ß Validating SSN/name, income, and assets

ß Providing a variety of data pertaining to determining eligibility for the food stamps and

TANF programs

ß Providing data available in the database to State agencies in real-time 

State agencies would provide the same information to create the central database initially as in the

eligibility database alternative. Agencies would also provide updated case records on a daily basis. The

system would then contact federal databases to append the missing eligibility data to the records

submitted by a State agency, and would inform the submitting agency of any disqualifying information

uncovered from the federally furnished information. Data would be retained for several decades.

The system would use a commercial RDBMS to search the multi-state data to identify entries with

matching SSN’s and names. It would then transmit data from matches to State agencies within a few

seconds of a request for a match. After responding to the State agency, the system would check for

salient data in other Federal computing systems containing additional eligibility data. The system would

transmit the Federal data to the State agency for transmission to the caseworker during the on-line

session or later via file transfer or e-mail upon receipt. 
D-1

APPENDIX D

OTHER NATIONAL DATABASES

PUBLIC ASSISTANCE REPORTING INFORMATION SYSTEM (PARIS)

The Public Assistance Reporting Information System (PARIS) is sponsored by the Office of State

Systems, Administration for Children and Families (ACF), DHHS. The functionality of the PARIS

system is almost identical to the proposed functionality of the national client database, in that it

compares caseload data from multiple States to detect duplicate interstate participation. The major

differences between PARIS and a national client database are that PARIS is voluntary for States.

PARIS began on a small scale as the VA match in 1993 when three States requested access to

Veterans Administration data, which ACF facilitated. In 1995, four additional States sent their

caseloads to be matched, and in 1996, 28 States participated in the match. The matching was

performed by HHS staff on the HHS mainframe.

Also in 1996, HHS tested the idea of matching the State files against each other to detect duplicate

participation. This match detected significant numbers of duplicate participants.

The Defense Manpower Data Center (DMDC) agreed to provide their facilities and staff to

conduct the match in 1997. DMDC also offered to match welfare records to their records on active

duty military personnel. DHHS sponsored two national meetings in the past year to plan the first

match to be conducted using DMDC data. The PARIS managers hope to evolve the system from data

transfer using magnetic tape to using a communications network operated by the Social Security

Administration. They expect between 18 and 21 States to participate.

PARIS detects interstate duplication by sorting all participant records by SSN. The States that

have duplicates receive data from the other State(s) for each duplicate recipients. The States then verify

and follow up on the duplicates. The PARIS interstate match looks not only at the SSN, but also

checks to see if the start and end of benefit dates overlap, although not all States include start and end

dates in their input records. States have different TANF time-length requirements, which complicates

the use of date matching.

CRIMINAL JUSTICE INFORMATION SYSTEM (CJIS)
D-2

The Criminal Justice Information Systems (CJIS) Division of the Federal Bureau of Investigation

(FBI) maintains two databases which are used to inform States of activities that occurred in other

States: The National Crime Information Center (NCIC) and the National Instant Criminal Background

Check System (NICS). The NCIC is a database of information on criminals collected from federal,

State, and local law enforcement entities. The NICS is a temporary database of people trying to

purchase guns. The FBI matches NICS data with the NCIC and other sources to determine if they

can be prohibited from purchasing a gun under the provisions of the Brady Act.

The NICS system is a hybrid where detailed data records are stored for about half the States by

the FBI in a central database, while detailed records are maintained by the State in the other half. 

When the State keeps the detail record, the FBI maintains a pointer to the State to enable it to retrieve

the record and provide it to other States. The hybrid system evolved because some States wanted to

keep the detailed records within the State, while others preferred that the FBI handle the record and

thus reduce their burden. The FBI staff feels that, from a technical standpoint, the pointer approach

was not optimal but that it does address State privacy concerns. Complex messaging systems are

required when the FBI central file points a requesting State to another State’s data file. This eliminates

the simplicity and efficiency of one-stop shopping.

The FBI is often asked to share its data with other agencies for purposes which the Privacy Act

refers to as non-routine uses. For example, the Department of Housing and Urban Development

requested information on sexual offenders in response to the issues involving Megan’s Law. Other

government agencies have sought data on daycare providers, teachers, and Boy Scout leaders. The FBI

maintains an advisory policy board (APB) to approve any new access to the data.

Another challenge for the FBI is that each State has different laws, regulations, data definitions,

system architectures and technical competencies. Some States invest heavily in quality information,

while others have poor data. Variations in State law have a direct impact on system functionality. For

example, domestic violence offenders are precluded from having weapons, but this charge is a only a

misdemeanor in some States; cases in these States will not appear in the NCIC. Attempts to

standardize State public assistance eligibility data would likely face similar problems.
D-3

THE FEDERAL PARENT LOCATOR SERVICE (FPLS)

The FPLS is administered by the Office of Child Support Enforcement (OCSE), within ACF,

DHHS. The FPLS provides a means for HHS to notify State Child Support Agencies that a noncustodial parent in arrears on child support payments is obtaining income from a source that is not

readily available to the State agency. This income includes earnings from employers in other States and

the federal government, as well as unearned income. 

PRWORA mandated an expansion of the establishment of a National Directory of New Hires

(NDNH). This database contains 140 million quarterly wage records, 60 million annual new hire

records, 22 million Unemployment Insurance Benefits Records and Federal Employees new hire and

wage data. The FPLS also accesses databases maintained outside the FPLS at the Social Security

Administration, the Department of Defense Office of Personnel Management, the Internal Revenue

Service, and the Veterans Administration. Also included is the Federal Case Registry (FCR) of child

support cases. This database contains the name, SSN, date of birth, sex, and several other identifiers

of noncustodial parents.

The development of the system was completed in one year. One reason the system was developed

so rapidly was that HHS was able to access an array of vendors directly through a contract vehicle

established by the Vice President’s procurement reform initiative. Under this arrangement, vendors

are prequalified to receive funding through a bidding process, and agencies may select from the list.

 Proposal-preparation time was a single week, and proposals were limited to five pages plus an oral

presentation. The rapid implementation of the enhanced FPLS may represent a model for using

innovative procurement methods to cut development time.

FPLS officials believe that an important key to the success of the project was to convince the

Social Security Administration to house the database in its National Computer Center in Baltimore.

 This facility is technically advanced and secure. SSA also provided the CONNECT: Direct network

that already links SSA to the States. The development of a national client database could similarly be

expedited if a major federal computer facility and communications network were used.

Using the SSA facility has enhanced security at the federal level, but the security of sensitive

information has also been a concern at the State level. HHS has engaged in significant outreach to

States to provide aggressive on-site technical assistance to facilitate data extracts and transfers and to

promote secure handling of sensitive data by State staff. HHS developed its own video to train State

staff on security procedures.
D-4

The FPLS receives requests for non-routine uses of the data of the type that may occur if a

national client database were established. The law establishing the NDNH stated that the data could

not be used for other purposes. Because this database contains such valuable and comprehensive data

(the income of almost all workers), it is attractive to many other federal agencies. There is currently

some controversy about requests for access to the FPLS data, which has led to the scheduling of

Congressional Hearings. The FPLS staff, with support from OMB, has been successful thus far in

resisting additional access to the NDNH. A national client database may face similar controversy

regarding access.

THE WAGE RECORD INTERCHANGE SYSTEM (WRIS)

The Wage Record Interchange System (WRIS) is being developed in response to the Workforce

Investment Act of 1998, which requires States to use wage records to assess the performance outcomes

of job training programs and training and educational institutions. Because graduates of such programs

and institutions may gain employment outside the State, where the programs are conducted, it is

necessary for the State to retrieve the wage records from other States to adequately assess performance.

A feature of the WRIS that may be advantageous to the national client database is that it has no

central database with sensitive details about program participation. Only an identification index is kept

centrally. This approach greatly reduces the volume of data transferred and stored, while increasing

the number of data transfers by adding cycles of retrieving and forwarding records.

US DOL has piloted the WRIS and is entering the implementation stage. The system is jointly

administered by the Department of Labor and the Interstate Committee of Employment Security

Agencies (ICESA). Founded to represent the States in the administration of the federalized

unemployment insurance service, ICESA will be responsible for obtaining and maintaining all legal

agreements with the States to allow for data sharing. 
E-1

APPENDIX E

DETAILED ASSUMPTIONS FOR THE COST AND BENEFIT

ESTIMATES OF A NATIONAL CLIENT DATABASE

DETAILED COST ASSUMPTIONS

ß The cost to develop and operate the centralized portion of the system are the DHHS

report estimates, inflated at a 4.5 percent annual rate to the relevant fiscal year (DHHS

1997).

ß Public agency management and oversight of the contractor is assumed to be six full-time

equivalent (FTE) staff during the year of development, and three FTEs during each year

of operation. These managers are assumed to be federal employees at an annual salary

of $70,000. The total overhead rate--including fringe, burden, general and administrative

activities--for both State and federal employees is assumed to be 100 percent of salaries.

ß The development costs of each State are taken to be the arithmetic average of the four

State agency development estimates reported by DHHS (1997).

ß State agency management and oversight are assumed to require one-half an FTE per State

during the year of system development, and 0.1 FTE in each year of operation, with an

annual salary of $50,000.

The projected number of duplicate cases is based on an unpublished tabulation by DHHS of the

number of duplicate TANF cases in one month in the States participating in the PARIS system. This

figure is projected to an annual number of duplicate cases in 52 States. This figure is multiplied by an

estimate of the average cost of verification and claim collection per followed-up case (Fasciano and

McConnell 1995). This product is the estimate of State agency costs of follow-up, verification, and

claims collection.
E-2

DETAILED BENEFIT ASSUMPTIONS

ß Recovered past FSP benefits, as opposed to avoided future benefits, are based on the estimate

of the number of interstate duplicate benefits in four States estimated by GAO (1998). We

project this figure to the nation, based on the ratio of FSP benefits in these four States, to

that of the nation as a whole (GAO 1997). We multiply the national amount of duplicate

benefits by the percentage of those benefits projected to be recovered. For this figure, we

use the percentage of FSP overpayments due to client error detected by the IEVS system

that are recovered in a two-year period, either in the form of cash or benefit recoupment

(Fasciano and McConnell 1995). This product is the amount of duplicate FSP benefits

recovered. This procedure implicitly assumes that all the duplicate cases detected by GAO

would prove to be actual duplicate cases upon follow-up investigation by the State agency.

 Sensitivity testing of this assumption indicates that the national client database would be

cost-effective even if none of the duplicate cases detected by GAO proved to be actual

duplicate cases.

ß We follow a similar procedure for the amount of recovered duplicate TANF benefits. The

figure is based on the DHHS estimate of the number of interstate duplicate AFDC benefits

(DHHS 1997). We project this figure to a national total, and multiply the national figure by

the proportion of TANF overpayments due to client error detected by the IEVS system that

are recovered in a two-year period (Fasciano and McConnell 1995).

ß Avoided future FSP benefits, as opposed to recovered past FSP benefits, are based on the

number of recipients denied or removed in a month in 12 States as a result of the PARIS

system, estimated by FNS in an unpublished table of PARIS results. Each PARIS hit

represents an individual in the case, rather than the entire case. We project this figure to an

annual figure for the entire nation.

ß We convert the number of recipients denied or removed into avoided benefits by

multiplying the number of cases by the average monthly benefit and by the number of

months each case would have received benefits had it not been detected by the system. The

number of months until the case would have closed in the absence of detection is a key

parameter of the cost-benefit model. We assume that such FSP cases close in nine months,

the median length of spell of food stamps receipt. 

ß We use a similar procedure to project TANF benefits avoided. We assume the recipients

denied or removed resulting from the PARIS system in 12 States involve the avoidance of

both FSP and TANF benefits. We use an estimate of the average monthly benefit published

by DHHS (1998). As with the FSP, we assume that such TANF cases would close in the

absence of detection in 25 months, the median length of AFDC spells (Bane and Ellwood

1994). We use an AFDC figure because TANF has not operated long enough to support an

estimate of the length of a completed spell of participation in that program.
F-1

APPENDIX F

STATE AND FEDERAL PRIVACY LAWS

The salient features of the Privacy Act of 1974 are:

ß Openness. The Privacy Act requires adequate public notice of record systems and recordkeeping practices. Each system of records must be fully described in a notice published

in the Federal Register,

1

 and individuals must receive information about an agency's

information practices when they are asked to supply personal information.2

ß Individual Participation. The Privacy Act gives individuals the right to see their own

records3and to propose corrections.4

ß Collection Limitation. The Privacy Act directs agencies to collect information directly

from the individual when practicable,5and to maintain only information that is relevant

and necessary to accomplish an agency’s purpose.6

ß Data Quality. The Privacy Act directs agencies to maintain all records used to make

individual determinations with such accuracy, relevance, timeliness, and completeness as

is reasonably necessary to ensure fairness to the individual.7

ß Finality. The fair information principle of finality states that there should be limits to

how personal information is to be used and disclosed. Information should be used only

for purposes disclosed at the time of collection, and not used otherwise without consent

or other legal authority. The Act requires a set of procedures that agencies must follow

to use a system of confidential data.

ß Security. The Privacy Act requires agencies to establish rules of conduct for employees,8

as well as appropriate administrative, technical, and physical safeguards to ensure security

and confidentiality.9

 

1

5 U.S.C. 552a(e)(4) (1994).

2

Id. at (e)(3).

3

Id. at (d)(1).

4

Id. at (d)(2).

5

Id. at (e)(2).

6

 Id. at (e)(1).

7

Id. at (e)(5).

8

Id. at (e)(9).

9

Id. at (e)(10).
F-2

ß Accountability. The Privacy Act includes several enforcement mechanisms, including

civil remedies10 and criminal penalties.11

The greatest concern about the adequacy of Privacy Act protections is that of finality--that is,

protections against unintended uses. This concern bears directly on whether legal safeguards are

sufficient to support the development of the national client database. The Act gives agencies

considerable discretion in defining permissible disclosures through the regulatory process. Each agency

can define disclosures, called routine uses, for each system of records. The statute requires that a routine

use be compatible with the purpose for which the record was collected.12 Agencies establish routine

uses when they define a system of records. They can change the routine uses anytime by publishing a

notice in the Federal Register and accepting public comment.

The routine use provision and its implementation by agencies have been criticized for failing to

serve as a barrier to new uses and disclosures.13 There are two main problems. First, some agencies

have defined routine uses broadly. Second, subsequent laws sometimes impose new disclosure

requirements on existing systems. For example, when Congress enhanced child support enforcement,

it directed all agencies to disclose information about newly hired employees to the Office of Child

Support Enforcement. This law required a new routine use for many federal systems of records.

THE COMPUTER MATCHING AND PRIVACY ACT OF 1988

The Computer Matching and Privacy Protection Act imposed a series of new, mostly procedural,

requirements on federal agencies involved in matching activities. The 1988 amendments require federal

agencies (1) to execute written matching agreements between the source and recipient agencies before

matching with another database; (2) to provide notice of matching activities to Congress, OMB, and

the public; and (3) to establish data integrity boards to oversee and approve matching agreements. 

Importantly, the Act also requires that any party to a matching program verify the findings of a match

and provide any individual affected the opportunity for a due process hearing before taking action

based on the results of a match, especially if the matched information leads to an adverse action against

an individual.14 If a national client database were a federal system, over fifty matching agreements would

be required, and would have to be renewed every 18 months.

 

10 Id. at (g).

11 Id. at (1).

12 Id. at (a)(7).

13 See, e.g., Paul Schwartz and Joel Reidenberg, Data Privacy Law 5-2 (a)(1996).

14 Id. at (p).
F-3

State Privacy Laws

State privacy laws vary substantially. About a quarter of the States have generally fair information

practice laws roughly comparable to the federal Privacy Act of 1974.15 In California, for example, a

general privacy law applicable to all State records16 is accompanied by a more specific law governing the

confidentiality and disclosure of food stamp and other social service records.17

A few States have laws that specifically address computer matching. In Wisconsin, the Personal

Information Practices Act prohibits a State authority from using personally identifiable information for

computer matching unless the authority specifies in writing the purpose and legal authority for the

matching, the justification for the program and anticipated results, and a description of the information

that will be matched.18

Several types of State laws might complicate the operation of a national client database. Some

State laws require that individuals receive notice of how their information will be disclosed and used.19

In those States, the forms used to collect information from food stamp applicants would have to be

changed to reflect the flow of information into a national client database. Informing existing recipients

of new disclosure practices might require a separate notice.

Some State laws give individuals the right to see and correct records about themselves maintained

by the State. State laws may also give individuals the right to enforce their privacy rights through the

courts. When records about residents of one State are shared with an agency in another State that has

a general-purpose privacy law, the transfer may result in the creation of privacy rights in the recipient

State that do not exist in the disclosing State.

In theory, an individual could ask one State agency to correct a record that originated in another

State agency. This might result in complex disputes and even litigation involving two or more States.

 One possible result is that a record about an individual maintained in one State could reflect a different

set of facts than the same record in another State. Any system architecture that involves the sharing

or maintenance of information by different States may need a mechanism to address the possibility of

discrepancies and disputes among State record keepers. Differences might have to be resolved at the

national level or between two or more States.

 

15 Paul Schwartz and Joel Reidenberg, Data Privacy Law 6-2, at note 4(1996), found laws in these 13 States: Alaska, California,

Connecticut, Hawaii, Indiana, Massachusetts, Minnesota, New Hampshire, New York, Ohio, Utah, Virginia, and Wisconsin.

16 Information Practices Act of 1977, Cal. Civ. Code 1798 (West 1998).

17Cal. Welf. & Inst. Code 10850 (West 1991).

18 Wis. Stat. Ann. 19.69 (1996).

19Cal. Civ. Code 1798.17 (West 1998); Minn.Stat.Ann. 13.04(2) (West 1997).