Crossing Boundaries:
Coordinating and Exchanging Data
Across States
Click here to download the MS Word (456.0 KB)
PDF (692.0 KB)
Technology Prototype
Problem Description and Technical Approach
January 2004John Blyskal, Al Sica
Prepared for:
U.S. Department of Health and Human Services
Administration for Children and Families
Contract: GS35F5365H 03Y00345601DState Information Technology Consortium
2214 Rock Hill Road
Herndon, Virginia 20170-4227IBM® is a registered trademark of IBM Corporation.
Sun® is a registered trademark of Sun Microsystems, Inc.
Windows® is a registered trademark of Microsoft Corporation in the United States and other countries.
Other product names, company names, or names of platforms referenced herein may be trademarks or registered trademarks of their respective companies, and they are used for identification purposes only.
The Project Team would like to recognize the many individuals in local and State Human Services (HS) organizations, information technology (IT) Divisions, and other government organizations that provided information for this report. The team is grateful to focus group participants representing local governments in the Washington, D.C., metropolitan area: Alexandria City, Arlington County, the District of Columbia, Montgomery County, and Prince George’s County. The team also is grateful for focus group participants representing State governments from Arizona, the District of Columbia, Iowa, Kansas, Maryland, Massachusetts, New Hampshire, New Mexico, New York, North Dakota, Oregon, and Virginia. These participants provided many insights into local and State Temporary Assistance for Needy Families (TANF) program and IT organizations. This report was made possible through their active participation and generous sharing of knowledge and experiences.
In addition to the participants, other individuals also provided assistance:
Sponsors within the U.S. Department of Health and Human Services (HHS), Administration for Children and Families (ACF), for providing aid to establish and conduct the focus group meetings
Extended Project Team members who helped organize and conduct the many focus group sessions and made many contributions to this report
Members of the TANF Technical Advisory Group who provided initial direction and assistance to identify and provide insight on issues investigated in the focus group meetings
The Project Team also is grateful for the readers and users of this report. You are encouraged to contact statesystems@acf.hhs.gov with any comments or suggestions.
Low-income families and individuals face multiple challenges that are not addressed easily within the context of a single Human Services (HS) Program. The eligibility workers and case mangers must coordinate with one another and others to deliver a comprehensive set of services, assistance, and support mechanisms that cut across physical as well as artificial boundaries, whether they are geographic, program, political, technological, contractual, cultural, or other.
To enable comprehensive service delivery, HS Program Managers and information technology (IT) Directors at all levels of government are integrating and streamlining their service delivery processes as they realign technology within their Agencies. This introduces new opportunities for cooperation and collaboration, thereby increasing the number and scope of interactions. These interactions can take place not only between programs internal to the HS Agency, but with entities outside its boundaries and direct control, including local, State, or Federal government entities, as well as public, nonprofit, or private organizations.
Web technologies now enable remote access and sharing of information across disparate State HS agencies. Over the past 13 years, Web technologies have evolved from a human, user-centric, client/server (browser) model to become a common platform for interoperability among application programs. Technologies such as XML Web Services allow autonomous organizations to participate in electronic data exchange without a large investment in proprietary infrastructure. Service-Oriented Architectures and the underlying supportive technologies enable loosely coupled, highly cohesive, and location-independent approaches to be used for application integration. These technologies allow entities to interoperate regardless of whether the exchange takes place within the HS Agency perimeter or across boundaries with external government or nongovernment organizations at the local, State, or Federal level.
These technologies hold great promise to reduce the barriers to interoperability, allowing system developers to employ standards-based approaches to exchanging and coordinating data across autonomous systems. However, as with any new technology, there are business and technology risks in applying it in a beneficial manner.
Purpose and Scope of the Report
This document summarizes the need for exchanging essential case information across State and local boundaries and discusses factors affecting that sharing. The Administration for Children and Families (ACF), an agency of the U.S. Department of Health and Human Services (HHS), is sponsoring this project.
This report will guide the production of a technology prototype demonstrating the application of XML Web Services technologies to enable sharing information across State boundaries. The prototype will be produced in the first half of 2004. A top-level design for the prototype is provided. The prototype will provide an executable example of how XML Web Services can be used to share information across States. It is not intended to imply a specific solution to be used by the States, but serves as an example that States can evaluate and build upon to develop their own approach appropriate to their specific circumstances. The federal Temporary Assistance to Needy Families (TANF) program is the primary focus.
Data Collection Approach
Focus group sessions were held in the fall 2003 timeframe. Participants discussed the ways HS organizations currently exchange HS case information and identified opportunities for improvement. The participants explored the eligibility and ongoing case management processes from different perspectives in separate sessions:
Eligibility Supervisor Focus Group
Local Bureau Chief and IT Staff Focus Group
State TANF Program and IT Directors Focus Group
Because HS Agencies within the D.C. metropolitan area frequently need to coordinate and exchange case information; representatives from the City of Alexandria, Arlington County, the District of Columbia, Montgomery County, and Prince George’s County participated in the first two focus groups. Representatives for the State focus group provided additional scope and included individuals representing Arizona, the District of Columbia, Iowa, Kansas, Maryland, Massachusetts, New Hampshire, New Mexico, New York, North Dakota, Oregon, and Virginia.
Current Practice
The report discusses the factors and influences of sharing information between autonomous local and State entities, organized into the following categories:
- Environmental Factors. A summary of factors that influence the wider environment in which the sharing of information takes place.
- Information Sharing Needs. The types of information those participants and others access or would like to access across HS Agency boundaries.
- General Information-Sharing Approaches. Two general approaches to sharing information outside the HS Agency:
Formal approaches have defined procedures, roles, and other elements, for example, supporting data matches against a new hires database.
Informal approaches tend to be used when a unique information need arises that cannot be handled easily by the formal approaches. These tend to occur in real time and be event-driven.
- Common Considerations. Some systemic factors that affect the sharing of information, regardless of the approach chosen.
Reauthorization Considerations. Possible impact to sharing information because of pending TANF reauthorization.
Prototype Technical Approach
This section of the report discusses the technical approach to building the prototype and its top-level design, including the following:
- Goals. The overarching goals of the prototyping effort are to investigate and demonstrate the application of XML Web Services technology to address the factors affecting the sharing of information between States. Within that broad scope, the prototype’s specific goal is to provide a functional demonstration of an automated lookup and case information service to address 5-year assistance time limit queries between autonomous entities (e.g., a lookup service between States). The prototype is intended to provide a means for States to evaluate how Web technologies can be leveraged within their own specific business and technology context to enable sharing essential information between States.
- Stakeholders and Benefits. Senior Management (State TANF Program Directors, HS Chief Information Officers, and enterprise architects) concerned with the strategic application of technology can use the prototype as a basis for evaluating the opportunities and risks of a Web Service based approach to sharing data. Individuals with a tactical perspective (lead architects and designers) can use the prototype as a basis for considering how to design and implement a data sharing capability that is compatible with their environment. Programmers can use the prototype and its modules as a model for their application design and programming (e.g., application layers, XML Schema, service interface).
- Design Principles. These design principles are the fundamental characteristics of the design and implementation that establish the overarching technical approach for the prototype.
- Prototype Environment and Top-Level Design. The infrastructure to build the prototype application, as well as its top level design is discussed.
- Use Cases. A Use Case diagram abstracts part of the intake and ongoing case management processes to show typical interactions and highlighted cases within the scope of the prototyping effort.
- Prototype Products. The executable code and documentation from the prototype will be available from the National Human Services Information Technology Resource Center website at: http://www.acf.hhs.gov/nhsitrc/.
2.3 General Information-Sharing Approaches
3 Prototype Technical Approach
3.4 Prototyping Environment and Top-Level Design
List of Abbreviations and Acronyms
Table of Figures
Figure 1. Prototyping Technical Environment
Figure 2. Top-Level Design for Prototype
Introduction
Background
Low-income families and individuals face multiple challenges that are not addressed easily within the context of a single Human Services (HS) Program. For example, placing a Temporary Assistance to Needy Families (TANF) recipient into work may require: alcohol or substance abuse supports and services; arranging living, housing, or child care for children; obtaining support from a non-custodial parent; providing food and medical aid; or helping with living skills, education, job search, or transportation. To provide families the opportunity to be self-sufficient, the eligibility workers and case mangers must consider each family’s unique situation. They must coordinate with others to deliver a comprehensive set of services, assistance, and supports that cut across physical and artificial boundaries, whether they are geographic, program, political, technological, contractual, cultural, or other.
The automated systems and office technology upon which each program depends are integral parts of that program. These automated systems and aids have evolved separately over several decades to handle each program’s unique information storage, processing, and management needs. Today’s need to integrate and collaborate across programs has put pressure on these systems. They need to keep customer and service data synchronized with one another to allow for a comprehensive set of services to be planned, provided, and managed.
To enable comprehensive service delivery, HS Program Managers and Information Technology (IT) Directors at all levels of government are pursuing many creative and innovative strategies. They are integrating and streamlining their service delivery processes and realigning technology to support those changes. Techniques such as co-locating and cross-training of key individuals and streamlining procedures via centralized service centers can remove logistical and administrative barriers. Data and business rules integration has led to consolidation and harmonization of common data elements and policies (rules), removing redundancy and enabling cross-program data access and correlation. Web technologies are being leveraged to make the data and program information and procedures more accessible to recipients and workers wherever they may be ¾ in regional State and local agency offices, homes, schools, hospitals, libraries, and other locations.
Streamlining and integrating the service delivery processes introduces new opportunities for cooperation and collaboration at both the program and technology levels, thereby increasing the number and scope of interactions. These interactions take place not only between programs internal to the HS Agency but with entities outside the HS Agency’s direct control. These external entities can reside within or outside the State’s boundaries and can include local, State, or Federal government entities, as well as public, nonprofit, or private organizations.
Overarching program requirements can span multiple autonomous entities. For example, federal law prohibits States from using federal TANF funds to assist a family with an adult who has received federal assistance for 5 years (60 months), with some exceptions based on caseload, need, or waivers. Because this requirement pertains to an individual and spans a lifetime, enforcement can span jurisdictions as individuals and families move across city, county, and State boundaries. (This requirement is referred to as the 5-year assistance requirement in this report).
Each State’s TANF Program is autonomous, guided by the State and federal policy and regulatory frameworks. Local jurisdictions also have flexibility to define and deliver services that address the needs of their communities, within the overarching policy, procedural, and technical framework of the State HS Agency. A key benefit of this approach is the ability of local offices to tailor services and their delivery mechanisms to meet community needs (e.g., drugs, crime, education, jobs, and housing). In times of emergencies, as was recently experienced with hurricane Isabel in the Washington, D.C., metropolitan area, HS Agencies need to be flexible and to react quickly and decisively, delivering help to those that need it, when they need it. This heterogeneous program and technical environment allows programs to be responsive to their customer’s needs but introduces variability when automating the enforcement of requirements that span jurisdictions.
The basic principles behind a decentralized strategy to delivering comprehensive Human Services are becoming a best practice for delivering enterprise-wide information systems. The object-oriented paradigm has matured into a service-oriented model for designing and constructing systems. Over the past 13 years, Web technologies have evolved from a human, user-centric, client/server (browser) model to become a common platform for interoperability among application programs. Technologies such as XML Web Services allow autonomous organizations to participate in electronic data exchange without a large investment in proprietary infrastructure. Service-oriented architectures and the underlying supportive technologies enable loosely coupled, highly cohesive, and location-independent approaches to be used for application integration. These technologies allow entities to interoperate regardless of whether the exchange takes place within the HS Agency perimeter or across boundaries with external government or nongovernment organizations, at the local, State, or Federal level.
These technologies hold great promise to reduce the barriers to interoperability, allowing system developers to employ standard-based approaches to exchanging and coordinating data across autonomous systems. However, as with any new technology, there are business and technology risks in applying it in a beneficial manner.
Purpose and Scope
Many local and State HS Program and IT Directors have undertaken significant efforts to integrate automated systems within their HS Agency. This project researched the common needs for HS organizations to coordinate and share critical customer information across State boundaries. The Administration for Children and Families (ACF), an agency of the U.S. Department of Health and Human Services (HHS), is sponsoring this project. The project is investigating the application of XML Web Services technology to enable sharing information across disparate and autonomous organizations, that is, across State boundaries. The federal TANF program is the primary focus.
This document summarizes the factors for exchanging essential case information across State and local boundaries and discusses how they affect that sharing. This report will guide the production of a technology prototype demonstrating the application of XML Web Services technologies to enable sharing information across State boundaries. A top-level design for the prototype is provided. The prototype will provide an executable example of how XML Web Services can be used to share information across States. It is not intended to imply a specific solution to be used by the States, but serves as an example that States can evaluate and build upon to develop their own approach appropriate to their specific circumstances
Data Collection Approach
Focus group sessions were held in the fall 2003 timeframe. Participants discussed the ways HS organizations currently exchange HS case information and identified opportunities for improvement. The participants explored the intake and ongoing case management processes from different perspectives in separate sessions:
Eligibility Supervisor Focus Group. Participants in this session represented the front-line worker perspective. Senior individuals with supervisory and eligibility worker experience attended. Participants provided an operational perspective ¾ an understanding of current practices and challenges and any information that is (or could be) exchanged to improve the delivery and management of services provided to their customers.
Local Bureau Chief and IT Staff Focus Group. Participants in this session represented the local administrative perspective and consisted of local TANF Bureau Chiefs and IT Management and senior staff. These individuals provided a broad operational and tactical perspective ¾ an understanding of the local program, policy, and technology context as it pertains to coordinating and sharing information across programs, counties, or cities and with other State or interstate entities.
State TANF Program and IT Directors Focus Group. Participants in this session represented theState perspective and consisted of State TANF Program and IT Directors and senior staff. These individuals provided an understanding of the State programs, policy, and technology as they pertain to sharing information between HS and other Agencies and departments within and between States and federal agencies or databases.
Because HS Agencies within the D.C., metropolitan area frequently need to coordinate and exchange case information, representatives from the City of Alexandria, Arlington County, the District of Columbia, Montgomery County, and Prince George’s County participated in the first two focus groups. Representatives for the State focus group provided additional scope and included individuals representing Arizona, the District of Columbia, Iowa, Kansas, Maryland, Massachusetts, New Hampshire, New Mexico, New York, North Dakota, Oregon, and Virginia. This sampling is not intended to be exhaustive and comprehensive but to provide general insight into typical local and State HS and IT organizations.
Participants discussed the needs to coordinate and exchange information in the context of two major processes:
Intake Processes. Typical intake processes include customer screening, interviewing, completing and verifying applications, determining appropriate services and benefits (or diversions and emergency benefits), and providing orientation to employment services.
Ongoing Case Management Processes. Typical management processes include providing and monitoring customer participation in work activities (e.g., job search or readiness, employment, volunteer placement, and training), collecting and publishing metrics, and performing recertification (redetermination) of TANF cases.
Focus group attendees participated in free-format discussions and described their service processes and use of technology. The central focus was on ways that their HS organizations currently exchange critical case information across programs, systems, or jurisdictions, noting challenges, best practices, and lessons learned. The 5-year assistance requirement was one example for sharing information because this addresses a common need for coordinating and sharing case information across autonomous organizations (i.e., crossing State boundaries). The participants also discussed other experiences and needs for sharing data and the impact that TANF reauthorization might have on HS programs and technology.
One important benefit of these meetings was the ability of the participants to converse freely with one another and share their experiences and lessons learned.
Current Practice
This section consolidates and characterizes some of the factors and influences of sharing information between autonomous local and State entities.
There is great diversity and range of capabilities between the States represented in the focus groups. The information presented here is not intended to be exhaustive but rather indicative of what others are doing and experiencing. These statements reflect a composite of the insight gained from the focus group discussions and the experiences of the Project Team. This section does not attempt to enumerate every possible item but rather to point out representative factors and influences to consider within a business and technology context. Some items may apply, but other items may not. Items are presented in no particular order of importance.
The topics are grouped into the following categories:
- Environmental factors
- Information-sharing needs
- General information-sharing approaches
- Common considerations
- Reauthorization considerations
Environmental Factors
Any approach to employing new technology must consider the forces at play, that is, the various factors that shape the wider environment of interest, whether business, technological, social, political, or other considerations. The following is a summary of the most important factors that surfaced during the focus group discussions. These factors represent business and technology drivers that influence any general approach to sharing information across boundaries. Some key items are:
Benefits. States have implemented and are pursuing many approaches to sharing information across programs, systems, and jurisdictions. For those that have direct experience in sharing information across State boundaries, it has proven to be beneficial in reducing fraud, recovering overpayments, and providing better insight into the background and needs of the individuals and families that are being helped.
Limited Budgets. Many States are in the midst of a financial crisis with budget shortfalls and rising deficits. Many HS Programs are facing budget crunches ¾ enduring hiring freezes and staff reductions and generally making do with existing equipment and infrastructure ¾ while maintaining their obligation to help people in need. This suggests that any approach to enabling the electronic sharing of information between States should consider these tight fiscal conditions and not be cost prohibitive or put undue burden on the organization’s program and IT staff and resources. In this financial climate, evolutionary, continuous improvement approaches that make a few well-placed changes may be more suitable than major redevelopment efforts.
Consolidation. Many States have undertaken initiatives to consolidate and centralize program and IT resources to use staff more efficiently and cut costs. Service centers are emerging where staff can help customers across many programs (e.g., call centers). Equipment (servers) and IT staff also are being centralized and consolidated to enable IT Departments to bolster network security, reduce the number of servers, improve utilization, and deploy and use IT staff more effectively.
IT Worker Shortage. As core mainframe applications and computer systems continue to age, individuals with experience on those systems also are reaching retirement. Finding and keeping highly skilled and knowledgeable IT workers to maintain these systems is difficult. Talented individuals with a deep understanding of contemporary and emerging technologies also are difficult to attract and keep within government organizations, although the current economic slowdown has provided more access to these individuals. When IT initiatives take a long time to go from concept to implementation, the flexibility of the IT organization is limited and it cannot react quickly to changes when a formal, contractual process must be used. Overall, there is a general dependency on vendors and contracted staff.
Application Integration. Within the HS Agency, the ability of automated systems to seamlessly share and exchange data varies widely. Some States have integrated their systems directly or have implemented common customer databases and data stores (e.g., using data warehouses or marts). Others may still rely on manual and paper-intensive processes to move information across system boundaries. Typical issues include: access of information across systems (having to log into multiple systems as opposed to a single sign-on); restrictions on information levied by the provider (restrictions to Child Support related data); multiple entry of data across automated systems (address updates between childcare and TANF); and contractors having limited access to State systems and therefore replicating data in contractor and State databases. Any general solution to sharing and exchanging data across States cannot make any assumptions about the level of integration and sharing within the HS Agency.
Different Program Rules. Each State has responsibility to determine how they will implement the TANF Block Grant within federal guidelines. In the case of the 5-year assistance requirement, this leads to diversity such as how these time limits are calculated (e.g., countable activities; when the count starts, is updated, or stops; effects of waivers; how long someone can consecutively accumulate assistance (partial months, 24-month segments or continuous 60-month); two-parent households, and other aspects. Generally, when someone in one State needs to check time limits with another State, they generally accept the provider’s calculation and incorporate it into their own records as appropriate.
Explicit Information-Sharing Policies. While State’s have guidelines and procedures in place to manage the general exchange of information within their State, explicit policies that provide direction for sharing information between States may not always be formalized. Several factors can inhibit interstate sharing: uncertainties in what information can or cannot be shared, when a worker must or need not contact another State, whom to contact, who can receive information, and other uncertainties. When specific, formal sharing agreements between States are implemented, States have taken to documenting these understandings using Memorandums of Understanding (MOUs) or other formal documents. These documents establish the sharing and oversight process and procedures (e.g., State-to-State sharing of Medicaid records).
Information Sharing Needs
During the course of the discussions, many participants identified the types of information that they or others access or would like to access across HS Agency boundaries. In some instances, some of these items may be available within the HS Agency (e.g., when integration has occurred across the program’s automated systems or using a data warehouse). Reasons for sharing this information vary, such as verifying applicant information and making decisions on eligibility, detecting and preventing fraud, correcting overpayments or underpayments, measuring program process and outcome performance, and finding and correcting errors and improving the quality of data and the services delivered.
The following list describes some items to share; the list is not prioritized.
Wage and income data for individuals in other programs such as Food Stamps (FS) and Child Support Enforcement (CSE) within and between States and federal agencies (e.g., Veteran Affairs). This can include unemployment insurance, child support payments (and frequency), and other payments.
Contact information for out-of-State noncustodial parents (e.g., from CSE).
For those who have received assistance for some time and move into a new area, information about basic demographic data such as previous addresses; caseworker contacts; the number of TANF months/payment history (months on federal assistance); case status (history/open/close/sanctioned); work/job activity participation; compliance history; service or training history; and a breakout of waiver information, if applicable.
Credit reports.
School attendance records (especially if the individuals meet mandatory work requirement age limits).
Management information about a previous or existing case (e.g., case worker contact).
Data to help manage local programs (e.g., caseload data, job retention, and participation metrics).
Status of individuals leaving the program (e.g., job data).
Asset data (e.g., vehicle, accounts).
State and federal new-hire data.
Prisoner lists and records.
Low Income Home Energy Assistance Program data.
General Information-Sharing Approaches
Participants discussed both formal and informal approaches when sharing information outside the HS Agency.
Formal Information-Sharing Approaches
Formal approaches explicitly define roles, data elements, and interchange formats (screens, messages, reports, or data records). These approaches have documented processes that are supported with automated or manual procedures to manage the exchange protocol (e.g., communications protocols, MOUs between participants).
Formal approaches consist of two general methods. The first method allows a user in one organization to access another organization’s system interactively. A worker in one jurisdiction uses their desktop or a separate dedicated terminal to log into and access another jurisdiction’s eligibility, Child Care, Child Support, Motor Vehicle, or other system. Workers also may access third-party credit reporting services on the Web through their browser.
The second method is to export, transfer, and import data from one system into another using physical or networked file transports such as tape, File Transfer Protocol (FTP), or other proprietary communications protocols. These exchanges generally support matching records across systems, where data is processed on a remote system and a result returned and used by either the originator and/or the receiving State (e.g., a report). Some external systems used for exchanging information were the State and federal New Hire Databases, the federal Public Assistance Reporting Information System (PARIS), and State-specific reciprocal data matches (e.g., Food Stamps, Medicaid, Electronic Bank Transfer).
The following list describes some observations on this type of sharing:
Data Clean-Up. When sharing or swapping files across autonomous entities for use in matching (e.g., State or federal), the originating entity needs to clean up the records before sending them. Senders should resolve any redundant, missing, incomplete, or erroneous data and other quality issues before any matching takes place. Returned matches (or nonmatches) often need to be reviewed and processed manually. The data that may come back from matches may not be formatted in reports that can be used directly by those who need them. Effort to clean up the original data, and to interpret, format, and forward the results, adds time and effort to the exchange process.
Periodicity. Exchanges done with entities outside the HS Agency or State boundary often are performed periodically rather than on demand, such as monthly or quarterly. Depending on the mechanics of the exchange, this periodicity could introduce a delay between the need for a data match (when an application is reviewed and approved) and the occurrence of the data match (possibly months later).
Multiple System Access. When allowing users to access multiple systems directly, users typically establish individual sessions and must remember multiple accounts and passwords for each system (e.g., limited single sign-on capabilities). If a user is working on several systems at the same time, then session (inactivity) timeouts may automatically log the person out. User interfaces (screens) may restrict the user to only the data and transactions that they are allowed. If the system did not have appropriate controls in place as part of the original design, it is difficult to retrofit and ensure secure access (protecting against accidental or deliberate change). This is of particular concern if contractor personnel access the system. If a dedicated terminal is used (logging in remotely across jurisdictions), it may be in a protected area, thus complicating access.
Users may have limited ways to get information into or out of a shared system and into theirs, for example, generating reports and manually reentering data into their system.
Training is also an issue because individuals must learn how the shared system operates and navigate the user interface to create, query, or update their data.
New Hires Data. Focus group participants frequently cited (State) new hires data as a source of useful information. One jurisdiction has a pilot in progress to access the National Directory of New Hires (federal level). Using this directory has generally worked out well. As those participating in the pilot gain more experience, they are learning to clean up the data files and reduce the number of potential matches. A file with TANF information is transferred by the piloting jurisdiction once a month, and matches are returned quickly. This capability can help determine employment outcomes for those that leave the TANF Program and move out of their State.
Access Costs. Sometimes there may be costs to accessing data (e.g., credit reports, Medicaid, prison matches). These costs may restrict use of certain matches to only when the requester has tried other methods first.
Informal Information-Sharing Approaches
Informal approaches tend to be used when a unique information need arises that cannot be handled easily by the formal approaches. These needs tend to occur in real time and be event-driven. For example, something in a customer application or interview process can trigger a need for more information, such as the applicant indicating they recently moved to the area and were previously unemployed, with no apparent means of support. Channels such as telephone, fax, email, or postal mail are often used to inquire and exchange information between workers. If workers are collocated, this may even be as informal as talking with someone down the hall.
The following list describes some characteristics of this type of sharing:
- Contacts. The knowledge of whom to contact for the needed information is often based on the requestor’s experience. A worker may know someone in another State’s HS organization and contact him or her. The worker may also rely on phone book or other listings to identify initial contacts. Typical methods of inquiry include telephone calls or emails. Sometimes a connection is never made for simple but not obvious reasons (person returning a voice message may not have long distance calling ability).
Once an individual with the needed information is identified, a request for information can be made. Some organizations have appointed lead individuals to handle external inquires for case information.
- Authorization. Many techniques are used to ensure that only those that should have access to the information receive it, depending on the nature of the request. For example, when a telephone is used by the requestor to initiate contact, the individual releasing the information may call the requestor back, verifying the phone number. Requests may require using Agency letterhead and must identify requesting individuals that can be verified. Answers may be faxed or mailed (email is generally not used). The specific procedure for releasing information is driven often by the person providing the information.
- Effort. Satisfying an information inquiry can be time-consuming for the Agency staff researching and providing the information. There may not be an easy way to query the automated systems and obtain the needed data, or a staff member may have to check the data before releasing it. Data may only exist in paper form, or may have been archived. Manual effort to find and process the needed data could add a delay of several days and additional staff expense to satisfying inquires.
Common Considerations
Sections 2.4.1 through 2.4.5 describe some systemic factors that affect the sharing of information, regardless of the approach taken.
Dissemination of Information
A paramount issue is getting the right information to the right person at the right time for someone to take appropriate action. Individuals at different levels of government (local, State, Federal) have different information needs. Information should flow down to appropriate individuals in a timely manner (e.g., fraud investigator, eligibility worker, or case manger). Formal approaches may introduce a delay or barrier to the flow of information to the workers. Generally, formal processes that govern the exchange of information take place at a higher level in the organization and the worker needing the information may not a direct participant in the exchange process. Sometimes individuals may be left out of the information dissemination path (e.g., State-wide matches being filtered or not flowing down to county workers).
Information Usability
Information needs vary with the individual and the part of the business process that the individual is performing. Staff with an operational focus (e.g., eligibility workers and case managers) may need more specific data than those in supervisory and oversight roles (e.g., program analysis). General solutions to sharing information should include tailoring the type and amount of information provided to the requestor to meet their individual information needs. For example, depending on the circumstances, staff may need to dig a little deeper to verify a situation adequately or understand someone’s background if a red flag is raised.
Verifying facts in context of a specific case may require an investigative approach. Eligibility workers can suffer from information overload and do not need more information than what they deem necessary. Formal data sharing methods that are geared toward matches can help raise red flags but may not provide all the needed data elements; these methods also could provide too much of the wrong data for the worker’s need.
Quality of Shared Data
Several factors affect the usability of the shared data:
Timeliness. The application process must complete within a prescribed timeframe (e.g., 30 to 45 days). In general, the customer is best served by minimizing the time between the start of the process and a decision on the application. To shorten this cycle time, for example, workers encourage applicants to bring backup to verify information at the initial interview (e.g., Social Security identification card, license, birth certificate, or bank statements). Some application information is verified through automated searches of other Program, State, or federal systems and data stores (e.g., Department of Motor Vehicles, Licensing, State and federal New Hires Databases, PARIS, etc).
Having access to quality information early in the intake process reduces the logistics of getting this information later, shortens process cycle times, and reduces the possibility of making application decisions based on incorrect assumptions ¾ generally improving decision making and case management. Sometimes there may be a time lag between when data is entered into a system and when it is available to be searched. Searches may be performed periodically (e.g., daily, weekly, monthly, or quarterly) rather than on demand. As the time increases between when verification is needed and when it is performed and the results are made available, then the chance for errors and manual reconciliation can increase.
Inconsistencies. When multiple, independent data stores on autonomous automated systems are referenced, the data may not be synchronized (e.g., across HS Programs). This also is true of paper versus electronic records. Searches done at the same time across different systems can return different results. Time and effort are needed to resolve inconsistencies and reconcile data between sources.
Periodically extracting and transferring data from one system to another may introduce inconsistency and the need to reconcile data. The data on the original system may be updated after the snapshot is taken. This complicates use of extracted data for matches or case record updates (job status) because it may be out of synch with the data in the originating system. This could affect the quality of any decisions made using extracted data, as that extracted data may not accurately reflect the current situation.
Data matches may need to be redone periodically (e.g., when a customer recertifies). For example, a State may allow someone to repay their TANF funds through child support checks, in essence retroactively reducing the number of months of assistance they received. Depending on when information is shared across systems, a complete and accurate accounting may not be possible if only checked once.
Interpretation and implementation of program rules across States can vary. When determining how many months of federal assistance were provided, States may have implemented TANF at different times, used different criteria for determining countable activities, had waivers, increment counters at different times, and have other process differences (for additional factors, see Section 2.1, Different Program Rules).
Archiving. TANF records can span a long period because of breaks in service over a customer’s lifetime. States have guidelines on the length of time to archive data to reduce online storage costs (e.g., payment data may be purged after 3 years, or case data can be archived when it closes). In practice, data generally is kept online as long as possible. If archived, data records are not available immediately, or even saved in electronic form; then, retrieving whole case records when only a few facts may be needed could add to the cost, effort, and time to satisfy information needs. Staff who request information from one State to another cannot assume that the information is available online.
Ownership of Data
In general, each HS Program has the responsibility to protect and monitor the disclosure and use of its data. Within the HS Agency, risks to the sharing of data across Programs can be addressed through common Agency-level (or higher) management and administrative channels. The Program that owns the data has a central role in defining and overseeing the sharing of its data.
When data is shared with autonomous entities outside the HS Agency boundaries, either in a formal or informal way, the provider had limited ability to exert direct control over the data once it is released. To reduce risk in releasing information, the Program providing the data will set conditions on its release. For example, conditions can include the specific data that can or cannot be released, to whom it may be released, the protocol for releasing it, requirements for maintaining records of released information, and other considerations. For formal sharing arrangements (e.g., State reciprocal sharing agreements), if the mechanics of each exchange are different, then setting up and agreeing to the exchange processes could add to the setup and administrative overhead and cost of sharing information.
Not everyone needing access to the data may have the ability to access it, either because of technical reasons (user platform does not support it), or they have not been given explicit access (e.g., fraud workers may only be allowed access to credit reports). If the person needing the information is not authorized to take part in the exchange, they may have to go through a trusted party. For example, someone at the State level may be responsible for submitting and receiving match data with another State and will filter and forward it to others. Handoffs add time and costs to satisfying an information need.
Security and Privacy
Protecting confidentiality and controlling dissemination of private information are primary concerns to all the focus group participants. Generally, the right to request and provide information from one jurisdiction to another is derived from the consent given by the applicant for the use of application information (i.e., information that will be matched against local, State, and federal records).
In formal data sharing approaches, the security roles and responsibilities are defined in formal documents such as MOUs, contracts (with vendors), or documented policies and procedures. When direct access to another system is provided across organizations, access often is controlled by modifying the user interface (e.g., profile) so that only certain screens (subsystems or data) are available to outside users. System or security administrators generally set up access controls. Setting up these controls may be difficult if the shared system was not designed with inherent security capabilities originally.
In informal arrangements, the entities rely on overarching State and local guidelines and implement safeguards that address their specific concerns. These safeguards may include having specific individuals responsible for the release, using written release of information requests, verifying the identity of the requestor via a caller’s telephone or fax number, and avoiding using email. Sometimes there are privacy rules that cannot be bridged, such as access to nonpublic child support information.
Reauthorization Considerations
At this point in the TANF reauthorization process, the specific impact that reauthorization will have to the State programs and supporting IT is unclear. Generally, changes that address the tracking and reporting of program performance may affect how information is shared across systems (additional performance measures and new activity categories). A need to engage the customer fully and coordinate regularly with others on all cases also may impact when and how information is shared across programs and systems.
One area of concern is States that use vendors who are already under contract to provide employment services. If performance measures (e.g., participation rates) or reporting requirements change significantly, then the parties may have to renegotiate the contracts.
Prototype Technical Approach
This section discusses the technical approach to building a prototype in the first half of 2004 and its top-level design.
Prototype Goals
The overarching goals of the prototyping effort are to investigate and demonstrate the application of XML Web Services technology to address the factors affecting the sharing of information between States (see Section 2). The prototype, when implemented, will provide an executable example of how XML Web Services can be used to share information across States. It is not intended to imply a specific solution that can be used by the States directly, but serves as an example that States can evaluate and build upon to develop their own approach appropriate to their specific circumstances.
Within that broad scope, the prototype’s specific goal is to provide a functional demonstration of an automated lookup and case information service to address 5-year assistance time limit queries between autonomous entities (e.g., States). Within this section of the report, the automated service is referred to as the lookup service.
The prototype will be based on XML Web Service technology, focusing on the core XML Web Service components needed to implement the lookup service (protocol for the exchange of the XML documents, document schemas, Web Service description and publication). Other capabilities, such as a user interface component, match algorithms, and core (mainframe) host integration, will be provided as needed to support a functional demonstration.
Information regarding the 5-year assistance requirement has a lot in common with other information-sharing needs. The lookup service solution will therefore provide a pattern for implementing similar solutions (see possible Use Cases in Section 3.4.3). The 5-year assistance requirement need is unique in that it assumes the parties participating in the exchange are autonomous with diverse program requirements.
The core components resulting from the prototype will be available on the National Human Services Information Technology Resource Center website (NHSITRC at http://www.acf.hhs.gov/nhsitrc/). These components can be used by States to implement the lookup service or modified to implement similar services.
Stakeholders and Benefits
Many diverse groups of individuals have a stake in the prototyping results. That interest may be strategic, tactical, or operational in nature. The following list discusses the individuals and their interests using the adopt–adapt–tailor paradigm for technology transfer:
Adopt. Adoption is the first step in preparing an organization to transition to a new technology. Stakeholders need to understand the overarching principles and practices associated with the technology to evaluate its strengths and weaknesses. The primary stakeholders are the individuals that set the strategic direction for their IT organizations. They must assess and manage the risk of using new technology given their business and technology environment. Stakeholders include local or State TANF Program directors or senior IT executives or staff (e.g., Chief Information Officers [CIOs] and enterprise architects). The prototyping process and products will provide these individuals with insight into the use of XML Web Services to support interstate sharing of information. The prototype will provide a context to discuss their policy and technology framework as it relates to using XML Web Services with their partner States (e.g., adopting common XML document schema and service descriptions or changes to their development and operational support processes).
Adapt. Each State has a unique HS Program design and uses different automation technology (e.g., computer platforms, commercial products, programming languages, and development processes). Each State therefore will have to adapt the prototype products to their overall business and technology context (e.g., infrastructure built on IBM, Sun, Windows or other platforms). Senior technical staff (enterprise and system architects or designers) will be able to reuse the prototype artifacts and adapt them to suit their needs, rather than starting from scratch. State-wide development conventions, design guidelines, or interface specifications can incorporate lessons learned from the prototype (e.g., XML Web Service descriptions, XML document schemas and namespace declarations, and registry entries).
Tailor. To support a specific data sharing opportunity, each State’s IT project can tailor or extend the prototype components. The nature of the platforms in use and the requirements of the HS application under development are primary drivers (e.g., programming conventions and languages, XML vocabularies in use). Lead application and interface designers and programmers can use the prototype components directly or tailor them to implement similar services.
Design Principles
The following are some of the essential characteristics, or design principles, that will be incorporated into the prototype. These principles, as a set, define the design approach and promote the adaptation and tailoring of the prototype for use in different State contexts.
Decentralized. Since each State is autonomous, and information exchange needs vary with organizations and individuals, a decentralized approach that does not require extracting or transporting fixed data to a central registry will be investigated. A loosely coupled approach will allow the flexibility to tailor the approach to define the data elements exchanged, match criteria, security, performance, and other attributes. A decentralized approach allows each information provider (lookup service) to tightly control and monitor information it releases to others (information requestor).
If needed, it should be possible to host the services in a central site without significant redesign (e.g., look up records across several States with a single request).
Location-Independent. The prototype should not require that the lookup service be at any fixed location. Discovery and location services (e.g., a registry) should be used to find the lookup service provider(s). This principle helps if the services were moved from a decentralized to a centralized implementation with minimal impact on the application invoking the service. The lookup service could be generalized and implemented within a local, State, regional, or national context, while hiding this from the client part of the application. This gives States flexibility in deploying the service.
Response Time. The lookup service is assumed to be accessed from an interactive session. The response time must be appropriate for human interaction. Long-running responses (service down) should be indicated. The lookup service is not expected to operate in batch mode, with many requests made over a short period of time (i.e., searching thousands of individuals for a match one at a time). However, the design should allow for consolidating requests into a single transfer to reduce communication overhead, if needed.
Security. The lookup service should be designed to authenticate the requestor and to protect the confidentiality of the information returned. The lookup service should make no assumptions about the correctness of the request and should validate each request (e.g., that it is well-formed and semantically valid). Only those data elements requested or needed should be returned. The ability to log or audit requests and returned data should be provided.
Standards-Based. Any highly reusable products, such as the document schemas, service descriptions, registry entries, or business protocol used, should be as vendor-neutral as possible to promote reuse across multiple platforms. As XML Web Services technology is undergoing rapid evolution, vendor-specific features essential to implementing the core components should be noted. For demonstration purposes, noncore components may rely on vendor products as necessary to meet prototyping demonstration goals.
Usage Context. The usage context for the States varies considerably. Because the prototype is a technology demonstration, limited assumptions should be made about the business, legal, and technology context in which it will be used. This improves the ability to adapt and tailor the technology components to many circumstances.
When implemented by the States, the lookup service will require data elements from one or more core HS mainframe systems. Because each State’s technology infrastructure varies, the data access portion of the prototype will abstract the data source interface. An intermediate cache will represent the extraction of data from the core systems or its online integration. A State would have to implement the data access interface based on its technology platforms.
Prototyping Environment and Top-Level Design
This section describes the technical environment in which the prototype will operate as well as its top-level design.
Prototyping Environment
The prototyping environment allows for the complete development and demonstration of the prototype within controlled circumstances. Optionally, the server and directory lookup parts of the prototype may be hosted on the Internet. This allows for demonstrating the prototype in a realistic Internet environment and provides a way for States to access it for experimentation and testing. Figure 1 shows the platforms to support the prototype development and demonstration, as described in the following list:
Development Servers. Microsoft Windows 2003 platforms support the server portion of the prototype. The servers can be reconfigured and roles assigned to support demonstrating multiple State interactions. One server can act as the requestor (State A), another act as the provider (State B), and another act as the directory service. The servers can also be used to demonstrate distributing the prototype application across multiple tiers (e.g., Web server, application server, data access).
Development Workstations. Microsoft XP Pro workstations are used to develop the prototype application and support demonstrations by emulating the client parts of the application.
Firewall, Internet Gateway. The development environment has high-speed access to the Internet through the State Information Technology Consortium (SITC) gateway. The firewall provides filtering and Virtual Private Network access, isolating the development laboratory from other parts of the network.
Third-Party Hosting Site. As the prototyping effort progresses, the server portion may be hosted on an Internet site to allow for demonstration in a realistic Internet environment. This approach also allows others outside the development environment to exercise the prototype lookup service.
Third-Party Directory Site. As the prototyping effort progresses, the Web Services directory portion may be implemented in a third-party directory. This approach allows others outside the development laboratory to exercise the prototype lookup service.
Figure 1 . Prototyping Technical Environment
Top-Level Design
Figure 2 shows the top-level design of the prototype. The items within the shaded part of the diagram are of primary concern to the prototyping effort. Other items are provided for context and will be used to support operational demonstrations. State A is the service requestor; State B provides the lookup service, as described in the following list:
State A (service requestor) components are:
User Client (Web Browser-Based Application). For demonstration purposes, the lookup request originates from a user platform using a web browser-based application. Results of the request are displayed here.
Web Server (Application Front End). The server portion of the application manages the user’s access to the lookup service on the client side. Results from the lookup service are formatted and returned for presentation to the User Client.
Application Server (Lookup Service Client). This is the Web Services client. It locates the lookup service provider in a Web Services Repository and handles the logic to invoke the service. It returns results to the Web Server for presentation to the User Client.
State B (service provider) components are:
Web Server (Lookup Service Provider). This part of the application acts as a facade for the service; it receives, authorizes, and validates the service request. It also orchestrates the execution of the components necessary to fulfill the service request and formats and returns the lookup service result.
Application Server (Lookup Business Logic) . This part of the application implements the business logic for the lookup service.
Middle-Tier Database (Case Information). This part of the service implementation accesses the relevant case information to fulfill the request. For the prototype, this is emulated with a database that can be populated with information extracted from the core HS systems. A result set satisfying the request is returned.
Core System Interfaces. These represent the existing core HS automated systems within the State (e.g., Eligibility, Child Support, and State Automated Child Welfare Information System) or State data warehouses. For demonstration purposes, this interface is emulated by the Middle-Tier Database. A State implementing the service provider part of the application could implement the interface to meet its technology and policy practices (using data extracts or enterprise application integration strategies).
Web Services Repository (UDDI). The repository implements a directory service that allows State B to publish organizational and service-specific information and State A to look up and invoke the State B service.
Figure 2 . Top-Level Design for Prototype
Use Cases
The intake or ongoing case management processes involve many roles and interactions. The Use Case diagram of Figure 3 abstracts this process and shows typical interactions (each State varies in the roles and specifics of the interaction). The highlighted Use Cases are within the scope of the prototype. The part of each case that applies to the sharing of interstate time limit information is addressed. Other Use Cases are shown to provide context.
The Customer role represents the individual needing aid (sometimes referred to as the client or applicant depending on the part of the process in which the individual is participating). Application Screener, Eligibility Worker, and Case Manger roles are those that are central to the intake (initial contact and application process) and ongoing case management processes. The Job Counselor role is central to the work support and oversight services provided the customer.
The Use Cases are:
Initial Application. This serves as the initial point of contact for a Customer. The Customer and Application Screener interact to direct the Customer to the appropriate service. The Application Screener determines whether the Customer meets categorical requirements, schedules appointments, and refers the Customer to other services.
Eligibility Determination. The Eligibility Worker interviews the Customer and obtains the information necessary to determine eligibility and benefits and opens (or reopens) a case. This may enable 5-year assistance time-limit counting.
Enable 60-Month Counter. The System enables the counting (start or continue) of the federal (or State) assistance counters.
Eligibility Investigation. The Eligibility Worker investigates the application to determine whether the Customer is eligible for TANF and determines the benefit amount. This investigation can include verifications such as school attendance, number of months of federal assistance previously provided within or outside the State, vehicle or other property, Social Security income, credit, or other checks as necessary. The out-of-State month check is the primary Use Case to be prototyped.
Check Credit. The Eligibility worker (or a Fraud Investigator or other authorized person) performs credit checks when necessary (credit cards, debt, and loans).
Check Motor Vehicle Records. The Eligibility Worker checks with organizations such as the Department of Motor Vehicles or others to verify the ownership and value of any property, such as motor vehicles.
Verify SSN. The Eligibility Worker verifies the SSN for the Customer.
Verify Employment Status. The Eligibility Worker checks to determine whether the Customer is employed, and if so, the time frame(s) employed. Items to check include manual (pay stubs) or automated records, such as the new hires database.
Verify Unearned Income. The Eligibility Worker checks to determine whether the Customer is receiving any unearned income, such as Social Security, Supplemental Security Income, Veterans Administration benefits, or other aid.
Check Out-of-State Month Count. The Eligibility Worker checks with another State(s) to determine whether a customer has received federal TANF assistance, as appropriate (e.g., Customer previously lived in that State).
Check In-State Month Count. An Eligibility Worker or Case Manager checks how many months a customer has received TANF assistance from within their State (federal or other assistance).
CheckSchool Attendance. An Eligibility Worker verifies that school age children are attending school, as appropriate.
Add Customer. This denotes the interaction between the Eligibility Worker and the automated system. It allows the worker to enter information collected during the interview into the automated system.
View Customer. The Eligibility Worker or Case Manager retrieving case data based on Social Security Number (SSN), name, or other fields.
Case Management. The Case manager interacts with the system throughout the Customer enrollment period.
Find Employment. The Job Counselor helps the Customer prepare for, find, and remain employed.
Prototyping Products
The prototype and the process used to generate it produce several products, as described in the following list. These will be available on the NHSITRC website
- Software code to implement the XML Web Service such as XML schemas, XML style sheets, Service Descriptions, and other artifacts of the client and server parts of the core application.
- Documentation describing the prototype artifacts to assist in their technical support and use.
- Documentation on the infrastructure (platforms) such as key setup parameters to enable a programmer to implement the core parts of the prototype.
List of Abbreviatio ns and Acronyms
ACF
Administration for Children and Families
CIO
Chief Information Officer
CSE
Child Support Enforcement
FS
Food Stamps
FTP
File Transfer Protocol
HHS
Health and Human Services
HS
Human Services
HTML
HyperText Markup Language
HTTP
HyperText Transport Protocol
IT
Information Technology
LAN
local area network
MOU
Memorandum of Understanding
NHSITRC
National Human Services Information Technology Resource Center
PARIS
Public Assistance Reporting Information System
SITC
State Information Technology Consortium
SOAP
Simple Object Access Protocol
SSN
Social Security Number
TANF
Temporary Assistance for Needy Families
UDDI
Universal Description, Discovery, and Integration
XML
Extensible Markup Language
