TRIBAL CHILD SUPPORT ENFORCEMENT SYSTEMS WORKGROUP

Session III

Joint Application Development

Final Report

October 2005

![](media/image1.wmf){width="1.775in" height="1.8930555555555555in"}

U. S. DEPARTMENT OF HEALTH & HUMAN SERVICES

Administration for Children and Families

Office of Child Support Enforcement

Division of State and Tribal Systems

This page intentionally left blank.

TABLE OF CONTENTS

[1. Introduction 1](#introduction)

[1.1 Background 1](#background)

[1.2 Scope 2](#scope)

[1.3 participants 2](#participants)

[1.3.1 Tribal Representatives 3](#__RefHeading___Toc118537936)

[1.3.2 Federal 3](#federal)

[1.3.3 Session II Support Staff 4](#session-ii-support-staff)

[1.4 process 4](#process)

[2. JAD SESSION summarY 7](#jad-session-summary)

[2.1 JAD Session Overview 7](#jad-session-overview)

[2.2 Key Issues for JOINT APPLICATION DEVELOPMENT
7](#key-issues-for-joint-application-development)

[2.3 meeting #1 8](#meeting-1)

[2.4 meeting #2 9](#meeting-2)

[2.5 meeting #3 11](#meeting-3)

[2.6 meeting #4 12](#meeting-4)

[2.7 Concept of Operations 13](#concept-of-operations)

[2.7.1 Overview 13](#overview)

[2.7.2 Case Initiation 14](#case-initiation)

[2.7.3 Locate 14](#locate)

[2.7.4 Paternity Establishment 15](#paternity-establishment)

[2.7.5 Establishment of Support Orders
15](#establishment-of-support-orders)

[2.7.6 Case Management 16](#case-management)

[2.7.7 Enforcement 17](#enforcement)

[2.7.8 Financial Management 17](#financial-management)

[2.7.9 Reports 18](#reports)

[2.7.10 Security and Privacy 18](#security-and-privacy)

[2.7.11 System Architecture 19](#system-architecture)

[2.8 Business Rules and Processes 20](#business-rules-and-processes)

[2.8.1 Case Intake Processes 20](#case-intake-processes)

[2.8.2 Locate Processes 21](#locate-processes)

[2.8.3 Paternity Establishment Processes
21](#paternity-establishment-processes)

[2.8.4 Order Establishment Processes 21](#order-establishment-processes)

[2.8.5 Case Management Processes 22](#case-management-processes)

[2.8.6 Enforcement Processes 23](#enforcement-processes)

[2.8.7 Financial Processes 23](#financial-processes)

[2.8.8 Security and Administration Processes
24](#security-and-administration-processes)

[2.8.9 Data Elements and Data Dictionary
25](#data-elements-and-data-dictionary)

[2.9 Next Steps 25](#next-steps)

This page intentionally left blank.

# Introduction

## Background

The Tribal Child Support Enforcement Systems workgroup (hereinafter
called the workgroup) met for the first time in August 2002. The
workgroup was chartered to recommend guidelines to maximize the benefits
of automating Tribal Child Support Enforcement (TCSE) programs while
limiting the fiscal impact associated with design, development, and
implementation of automated systems.

During the first series of four meetings, the workgroup discussed issues
with potential impact on the successful implementation of automation in
TCSE programs.

The primary outcomes of the 2002 Session I meetings included:

Identification of the considerations involved in developing automated
systems for TCSE programs, including acquiring and managing automated
systems and services, and the related Federal funding processes.

1.  Identification of high-level TCSE program automation needs,
    requirements, and constraints.

2.  Definitions of the high-level operational capabilities required for
    TCSE systems.

During the second series of four meetings, the workgroup focused on
functional requirements for automated TCSE systems and methods for
procuring, implementing and operating these systems, in order to
optimize tribal and Federal resources.

The primary outcomes of the 2004 Session II meetings included:

1.  Assessment of functional software requirements for statewide child
    support enforcement systems as they apply to tribal child support
    enforcement.

2.  Identification of the essential functional software requirements for
    a basic TCSE system, with additional software functionality
    determined to be conditional or optional to the operation of a basic
    TCSE system.

3.  Detailed considerations involved in developing automated systems for
    TCSE programs, including acquiring and managing automated systems
    and services.

4.  Consideration of the Advance Planning Document (APD) process applied
    to state systems.

5.  Identification of high-level TCSE program automation needs,
    requirements, and constraints.

6.  Definition of the high-level operational capabilities required for
    TCSE systems.

The final reports for 2002 and 2004 Sessions are available at:

[www.acf.hhs.gov/programs/cse/stsys/tab9.htm](http://www.acf.hhs.gov/programs/cse/stsys/tab9.htm)

## Scope

This report summarizes the activities and results of the third series of
meetings of the TCSE Systems workgroup. In this series of meetings,
tribal and Federal team members focused on joint application development
(JAD) of the defining hardware, software, and architecture
characteristics for a Model Tribal Child Support Enforcement System,
hereinafter called the Model TCSES.

The 2005 TCSE Systems workgroup met four times:

-   February 7-10, 2005 in Phoenix, Arizona

-   April 4-7 in Clearwater, Florida

-   May 23-26, in Chicago, Illinois and

-   July 18-21 in New York City, New York.

## participants

All JAD sessions were attended by key Federal and tribal workgroup
members. Additional Federal representatives were invited to attend
specific meetings.

A majority of the individual workgroup members have participated in both
series of workgroup meetings. Not all tribal representatives attended
every meeting, but most participating tribes sent at least one
representative to each meeting.

Federal participants represented organizational components of the Office
of Child Support Enforcement (OCSE), including the Division of State and
Tribal Systems (DSTS), the Division of Special Staffs (DOSS), the
Division of Policy (DP), and Administration for Children and Families
(ACF) regional staff. Tribal participants represented the tribes
operating Tribal Child Support Enforcement programs that received
Federal financial participation (FFP) under the Interim Final Rule, 45
CFR 310, and one additional tribal organization.

The Federal support team was augmented by contract technical assistance
support staff from BAE Systems and Maximus, Inc., who provided technical
assistance in defining and documenting technical and system
requirements. As in the first series of meetings, State Information
Technology Consortium (SITC) staff arranged travel and meeting
accommodations for participants.

### Tribal Representatives 

Tribal participants are listed in alphabetical order by tribe:

-   Tami Lorbecke, Chickasaw Nation

-   Jacqueline Pische, Forest County Potowatomi Community

-   Terry Hoyt, Lac du Flambeau Band of Lake Superior Chippewa Indians

-   Karen Burke, Lummi Nation

-   Tina Gouty-Yellow, Menominee Indian Tribe of Wisconsin

-   Rosemund Hoffman, Menominee Indian Tribe of Wisconsin

-   Kurt Nelezen, Menominee Indian Tribe of Wisconsin

-   Pierette Baldwin-Gumbrecht, Navajo Nation

-   Alex Largie, Navajo Nation

-   Lawrence Oliver, Navajo Nation

-   Harold Skow, Navajo Nation

-   Sandra Starnes, Port Gamble S\'Klallam Tribe

-   Linda Tresaugue, Puyallup Tribe of Indians

-   Emma GreyBull, Sisseton-Wahpeton Oyate

-   Winona Warren, Sisseton-Wahpeton Oyate

-   Rhonda Kampeska, Sisseton-Wahpeton Oyate

-   Keith Bowman, Tanana Chiefs Conference

### Federal

The following individuals provided a Federal perspective in one or all
of the meetings:

-   Jay Adams, HHS/ACF, OCSE

-   Karen Anthony, HHS/ACF, OCSE

-   Joseph Bodmer, HHS/ACF, OCSE

-   John Cheng, HHS/ACF, OCSE

-   Sheck Chin, HHS/ACF, OCSE

-   Levi Fisher, HHS/ACF Region X

-   James Hicks, HHS/ACF, OCSE

-   Ron Logan, HHS/ACF OCSE

-   Joseph Lonergan, HHS/ACF, Division of Mandatory Grants

-   Angela Richardson, HHS/ACF, OCSE

-   Mike Rifkin, HHS/ACF, OCSE

-   Ellamae Williams, HHS/ACF, OCSE

### Session II Support Staff

The following individuals provided technical assistance or meeting
support during JAD meetings:

-   Jean Cost, BAE Systems

-   Sheila Drake, SITC

-   Ruth Hara, Maximus, Inc.

-   Tom Mahony, BAE Systems

-   Chris Meike, Maximus, Inc.

## process

As in the prior two series of meetings, tribal participants represented
a range of perspectives and experience on automation issues. Some
participants represented tribes that use extensive automation in TCSE
programs, while others spoke for tribes operating TCSE programs using
manual processes. In addition, workgroup members contributed opinions
and viewpoints that considered the larger tribal community.

At each meeting, workgroup members addressed specific sets of issues.
The group then strove for consensus from all tribal representatives on
each issue and its associated sub-issues. Although several tribes, or
tribal consortia, sent more than one representative, if a vote were
necessary to determine a majority view, only one vote per tribe was
permitted.

Meeting highlights were produced following each JAD meeting to document
the proceedings, the points of consensus and the outstanding issues.
Meeting highlights were distributed to all workgroup members prior to
the next meeting, and reviewed by the meeting attendees.

A listserv maintained by OCSE promoted ongoing dialogue among workgroup
participants.

This page intentionally left blank.

# JAD SESSION summarY

## JAD Session Overview

The purpose of the JAD sessions and the current focus of the workgroup
is to participate with the Federal Office of Child Support Enforcement
in creating a workable design for a model automated system for Tribal
Child Support Enforcement (Model TCSES). The JAD sessions provide a
forum for the current grantee tribes and tribal nations to come together
to identify the business requirements and needs of their IV-D programs.

The identified needs and business requirements will then be incorporated
into a general system design, which will form the framework for the
design and development of a Model TCSES. After the general system design
has been developed and reviewed by the workgroup, the next phase will
entail the development of a detailed system design, which will identify
specific system requirements for the Model TCSES.

When the general (business) design requirements and the system design
requirements are complete, the next step will be to develop a prototype
Model TCSES. Initially, one tribe's requirements will be used as a test
of the concept and the functionality. When the pilot version is
successful and working, the Model TCSES will then be given to the nine
tribal grantees for more extensive testing.

All four JAD sessions followed a single agenda and process, as noted
below. Each topic was discussed in detail in one meeting, then reviewed
and refined in succeeding meetings until agreement was reached on the
process or the product. The JAD session discussions contributed to the
ongoing development of:

-   Concept of operations.

-   Business rules and processes, including process flow diagrams
    identifying the data elements and documents associated with each
    process.

-   Definition of the data elements, documents and reports for the Model
    TCSES.

Information in these work products will be incorporated into the final
general system design for the Model TCSES.

## Key Issues for JOINT APPLICATION DEVELOPMENT

Key issues on the workgroup's agenda included progressive discussions of
the following:

1.  Develop a draft concept of operations for a Model TCSES.

2.  Define high level software requirements for Model TCSES.

3.  Define the business processes in each key TCSE process area,
    including case initiation, locate, establishment, case management,
    enforcement, financial, reporting, security, administration.

4.  Achieve group consensus on process flow diagrams, data elements and
    definitions, required documents and reports related to each key TCSE
    process area.

5.  Define system architecture considerations, including tribal IT
    considerations, software requirements, hardware requirements,
    network administration and configuration, estimate preliminary level
    of effort, Federal Feasibility Study and impact analysis.

6.  Market survey of potential resources for tribal systems.

7.  Develop sample screen design requirements and develop prototype
    screens, forms, notices, documents, and reports.

The workgroup agreed to conduct an iterative process, discussing,
reviewing and refining agreements and work products in successive
meeting sessions. The meeting summaries that follow briefly touch on the
results of these discussions. Detailed meeting minutes were also
distributed to members during the session.

## meeting #1

The workgroup scheduled three and one-half days of effort for JAD
session #1. The session began with a review of the progress and
accomplishments of the prior workgroups. The workgroup agreed to use the
product of the 2004 workgroup, the draft Guide for Tribal Systems, as a
reference for high level software requirements. The workgroup referred
to the Guide frequently in its efforts to develop a concept of
operations and the business processes for a Model TCSES.

The workgroup began with an introduction to Joint Application
Development and an overview of the requirements development process to
familiarize all members with the roles, tools, and techniques for the
four JAD sessions.

The workgroup agreed to undertake detailed discussions of the key
process areas of Tribal Child Support Enforcement, including case
initiation, locate, establishment, case management, enforcement,
financial, security, and reports. In addition, the workgroup agreed to
discuss system administration and system architecture considerations.

The workgroup agreed to conduct a two-part examination of each TCSE
process area. First, the workgroup would explore and reach consensus on
the specific business processes and rules. The Federal support team
would capture the agreed-upon business rules and processes as flow
charts and process diagrams.

Second, the workgroup would address the data elements related to each
process, reviewing and reaching consensus on the elements and data
definitions.

The workgroup began its JAD tasks with an active review and discussion
of a concept of operations document drafted by the Federal support team.
The draft was based on discussions and findings of the first two
workgroups. The JAD workgroup successively refined and modified the
concept of operations over the four meetings of the current session. The
key agreements and discussion points are outlined in a separate section
of this report, without attributing particular points to specific JAD
meetings.

Following an initial review of the concept of operations, the workgroup
began discussing common business rules and processes. Of the nine
business process areas, this first JAD session included detailed
discussions of the first four target discussion areas (case initiation,
locate, establishment, and case management), and an initial discussion
of enforcement processes.

The workgroup deferred completion of the enforcement process area until
the second JAD meeting in Clearwater, Florida.

Workgroup members were asked to provide examples of key documents,
reports, and forms discussed during the JAD session as input to the
efforts of the Federal support team.

## meeting #2

The workgroup opened this four-day JAD session with a second review of
the draft concept of operations, modified to include the agreements
reached during the first JAD session. The workgroup approved
modifications, and discussed additional refinements in the areas of
system architecture, scalability, and access. The concept of operations
was to be refined further in the third JAD session.

As part of the agreed-on iterative process, the workgroup first reviewed
the work products of the prior JAD session, including process flow
diagrams, and related data elements and data definitions.

Process flow diagrams were produced as visual representations of the
detailed workflows and key decision points identified in the areas of
case initiation, locate, establishment, case management, and initial
enforcement processes. Each process flow diagram included the names of
documents and forms associated with the process, and in some cases, key
forms and reports. Data elements and definitions had been updated for
each process area.

The workgroup reviewed each flow diagram in detail, discussing and in
some cases modifying a process to reach a common understanding and
agreement. The workgroup agreed to review the modifications once more at
the next JAD session.

The workgroup then resumed initial discussions of the business processes
and rules, beginning with the remaining enforcement processes. During
the remainder of the JAD session, the workgroup completed detailed
discussion and initial flowcharting of enforcement, financial,
reporting, and security processes.

Workgroup discussions included several topics of additional interest to
members. Since six of the nine workgroup members currently operate a
tribal Temporary Assistance to Needy Families (TANF) program, the
workgroup explored system capabilities to support IV-A notices, IV-A
data, and IV-A/IV-D interfaces. The workgroup also discussed
requirements for worklists and alerts to caseworkers, including action
alerts, information alerts, and caseworker-generated alerts. The
workgroup also discussed requirements for case history notations in some
detail, exploring the kinds of data that should be placed into case
history automatically by the system, and data that should be entered at
will by caseworkers. This discussion included options for viewing or
retrieving case history data.

The workgroup continued the agenda with a review of the TCSE
configuration data document and discussed those items that should be
configurable by each tribe as part of setting up and customizing the
system for use. The workgroup determined that each tribe should be able
to set or select specific data values in the areas of tribal
information, CSE contact information, participant information,
enforcement, timeframes, job searches, system-generated documents,
automatic income withholding, financial, and security. Discussion points
included:

-   The workgroup agreed to defer discussion of court contact
    information, since some of the workgroup members belong to tribes
    that have multiple courts, and further discussion is required on how
    to handle multiple court situations.

-   The workgroup agreed that job search criteria should be handled as
    part of case narrative information and not treated as configurable
    fields on the model system.

-   After discussing judicial/administrative considerations, workgroup
    members agreed that that system should include the capability to
    print a signature block on form letters. The system should contain a
    default signature file, to be configured by each tribe during system
    set-up.

The workgroup conducted preliminary exchanges with the Federal support
team on a range of system characteristics. Discussions served both to
inform workgroup members of industry standard terms, vocabulary, and
available technology, and to gather input and direction from the
workgroup. Topics included system configuration and administration,
compatibility issues, program constraints and assumptions, hardware
requirements, software requirements, and estimated schedules and
resources.

The Federal support team outlined the steps ahead on the path to secure
funding to develop a Model TCSES. A Feasibility Study and Impact
Analysis is necessary, including analysis of alternatives, cost benefit
analysis, investigation of information technology resources, and
gathering essential data. Information gathered from the workgroup
members will serve as key input for the feasibility study.

As preparation for the next JAD session, workgroup members were asked to
submit representative pages from the top ten or "hottest" reports in use
or needed in the TCSE program, and any remaining forms or documents
requested during the prior JAD session in Phoenix. Workgroup members
were also asked to submit any additional changes needed to the data
element definitions discussed earlier in the current JAD session.

## meeting #3

JAD session #3 agenda included three and a half days of effort. The
context for the JAD session was set with an overview of the requirements
development process and the function it provides in the general design
for a Model TCSES. The workgroup members discussed the progress to date
and the tasks remaining in the final JAD sessions and as follow-on
efforts.

The workgroup continued work on agenda items with a third of four
scheduled reviews of the draft concept of operations. The workgroup
approved modifications in the areas of system architecture, scalability,
and access. Workgroup members discussed additional refinements in the
areas of billing and administration.

The workgroup continued its iterative process in reviewing the work
products of the prior JAD session, including process flow diagrams, and
related data elements and data definitions.

The workgroup reviewed modifications to case initiation, locate,
establishment, and case management flow diagrams, documents, reports,
and data elements.

The workgroup also reviewed the points in each process where decisions
needed to be made by caseworkers, system users, or the system itself,
and validated the decision options.

The workgroup discussed each specific instance that the system should
monitor actions or elapsed time, then take an action. Workgroup members
reached agreement on the process monitors, or criteria the system should
use to monitor the process or trigger an action.

The workgroup continued with a first look at the process flow diagrams
created in the prior JAD session, in enforcement, financial, reporting,
and security processes. The workgroup reviewed each flow diagram in
detail, discussing and in some cases modifying a process to reach a
common understanding and agreement.

The workgroup discussed preliminary results of a market survey conducted
by the Federal support team. This effort surveyed the information
technology resources available in geographic areas in which the Model
TCSES might be used. Part of the system design process, market survey
results should help ensure that the system is developed using technology
that the tribes can support with local resources and labor at a
reasonable cost over time.

As preparation for the final JAD session, workgroup members were asked
to provide representative pages from the top ten or "hottest" reports
that are in use or needed in the TCSE program, forms or documents not
already submitted , caseload and cost information, distribution policy
and procedures, and to review the list of system alerts. Workgroup
members were also asked to review the forms and documents listed in the
process flows, in order to identify any that are not really necessary,
or any that should be added.

## meeting #4

The workgroup opened the four-day JAD session with a final review of the
updated draft concept of operations document, and concurred that the
concept of operations document reflects group agreements and
understandings to date.

The workgroup reviewed the latest updates to process flows, and the
lists of documents, notices, and data elements for all processes,
including case initiation, locate, establishment, case management,
enforcement, financial, reporting, and security. In this final review,
the workgroup reached consensus on the structure and content of each
process flow before proceeding, including process decision points, and
the process monitors to be used by the system. The workgroup ensured
that agreement was reached on any additional changes recommended to the
Federal support team.

The Federal support team produced a large number of documents and
reports based on process flow discussions and on documents submitted by
workgroup members during the prior three JAD sessions. The workgroup
reviewed the sample documents in detail, clarifying their intended use,
identifying common points of style and structure, and developing common
understandings for the guidance of the ongoing system design process.

In regard to system-generated documents, the workgroup weighed whether
the system should produce a larger number of specific, easily generated
documents, or a few general purpose documents requiring many choices to
be made at the time of generation. The workgroup strongly favored easing
the impact on the daily use by workers, rather than for ease of
maintenance of the forms. Therefore, the workgroup recommended that the
system include a larger number of specific documents. For the same
reasons, the workgroup also recommended that documents be designed to be
generated separately, rather than as multi-part packages.

The workgroup discussed and recommended creation of one or more
auxiliary datasets for reference by system users, including:

-   "Agency" data such as addresses of state and Federal agencies.

-   "Third Party" data on employers, courts, frequently-needed
    addresses, service of process providers, the list of federally
    recognized tribes, FIPS codes, addresses for tribal programs, police
    agencies, and so forth.

The workgroup recommended development of the dataset(s) with an initial
set of data that could then be maintained by the tribe.

The workgroup reviewed the data dictionary, making recommendations on
specific elements and definitions, and their usage in TCSE processes.

The workgroup discussed and recommended reports that should be developed
with the Model TCSES, including specific financial reports and
management reports.

The workgroup reviewed a number of prototype screens developed by the
Federal support team, and discussed how users would complete processes
and navigate from one portion of the system to another.

The workgroup discussed the need to reconvene for two additional
meetings to finalize general design recommendations, and expressed
strong support for a continuing role as a steering committee during
future phases of system development.

## Concept of Operations 

### Overview

The Tribal Systems workgroup reviewed a draft concept of operations,
describing the "big picture view" of the proposed Model TCSES. The
concept of operations provided a high-level look at how system functions
support the business processes and procedures of system users. The group
discussed and agreed to a general content for the concept of operations.
The concept of operations was refined in each succeeding JAD session as
input to the larger system design process.

Discussion points included:

-   Goals for the Model TCSES. There was consensus on four goal areas:

```{=html}
<!-- -->
```
-   Reduce costs,

-   Be user friendly,

-   Provide flexibility, and

-   Increase caseworker efficiency.

```{=html}
<!-- -->
```
-   Architecture. Open architecture would afford maximum flexibility.

-   System scalability. Scalability must be considered in balance with
    the increased costs of support.

-   Access. Providing internet/remote access to users may not be cost
    effective for 'version 1' of the system.

-   Payment processing mechanisms. Members agreed that the Model TCSES
    should support the collections and disbursement of child support
    payments.

-   Reports. Members expressed interest in having the Model TCSES
    support the production of reports, but not having to actually
    produce all of the reports automatically.

-   Interfaces. Members recommended that the Model TCSES support
    exchanges of files with other automated systems (FPLS, new hire,
    state systems).

-   Performance measurements and scalability. Members agreed that the
    Model TCSES should be modifiable to accommodate rapid growth, but
    also retain ability to accommodate interface to smaller systems.

### Case Initiation 

Discussion points on the concept of operations for case initiation
included the following:

-   Agreement on the importance of a capability to identify tribal
    affiliation.

-   Referrals include state or tribal TANF, kinship care, Title XIX
    Medicaid, and foster care.

-   Locate-only case sources and reasons.

-   Agreement on the ability to track changes in case types, including
    IV-D and non-IV-D cases such as kinship care, foster care (state and
    tribal), TANF (state and tribal), medical only, locate only, and
    judgment only.

-   Application processes vary among members. All members have a
    specific intake process in place. Members discussed and identified
    similarities in processes and application forms.

-   Members expressed interest in future capability for the system to
    handle electronic signatures.

-   Agreement on preventing creation of duplicate cases.

-   Agreement on reasons for case closure.

### Locate

General discussion by the group disclosed a broad range of locate
documents used by tribal IV-D programs, and an equally diverse range of
locate sources that members contacted by phone, Fax, or email. However,
both the length of time and number of locate attempts varies by tribe
and situation.

Discussion points on case closure due to failure to locate:

-   Model TCSES should allow closing cases for failure to locate, but
    without specific timeframes.

-   Model TCSES should not automatically close cases for failure to
    locate.

-   It would be helpful to have the Model TCSES generate inactivity
    alerts on cases in the locate process.

-   The system should document all locate attempts in case history,
    tracking how often as well as how many attempts have been made.

### Paternity Establishment

Members establish paternity through a variety of methods, include
voluntary acknowledgement, in tribal court, in district court, through
administrative process, by default, by stipulation, and through tribal
ceremony for adoptions.

Workgroup member policies vary on the handling of paternity challenges,
including differences in the length of time allowed to challenge default
orders or findings.

Workgroup members commonly use genetic blood testing for enrollment
purposes as well as for paternity establishment.

### Establishment of Support Orders

Tribal child support orders are established through use of tribal court,
CFR Court, state court. administrative process, mediators prior to going
to court, and agreement orders. All workgroup members use petitions to
establish child support orders.

Means of serving process include tribal process servers, tribal police,
tribal security officers, private process servers, sheriff, voluntary
service via sending a letter to the individual, court bailiff, and
subpoena or summons.

Jurisdictional issues affect how cases are established. Some workgroup
members exert jurisdiction over tribal members, no matter where they are
in the country, based on enrollment factors. Some workgroup members
consider they have concurrent jurisdiction in paternity cases when the
child was born off the reservation but to an enrolled tribal member.
However, once either the state or tribe begins working the case, the
other entity gives up jurisdiction. In other instances, when it is
decided that a state has a valid order and the tribe discovers a
previous order exists, the invalid order is dismissed.

There is need for a means to indicate that processing of a case should
be suspended while a determination of jurisdiction is being made.

workgroup members discussed options for court workers to access the
Model TCSES, including access through system interface with the court
system, and limited or read-only access to the child support system.

There was consensus that the Model TCSES should support sending a letter
to the individual first, prior to personal service, and also support
personal service of process.

No consensus was reached on the need for special fonts and language when
printing an order, i.e., Navajo fonts for names as well as Spanish for
the southern tribes bordering Mexico.

### Case Management

Workgroup members have different timeframes for case management actions
and recommended that the Model TCSES be flexible enough to accommodate
these differences. There was consensus on having the Model TCSES move
the case to the next functional area automatically.

System ticklers or alerts that the workgroup members need include new
address information, missed payments, review and adjustment activities
related to the 3-year review, case closure actions related to case
review, emancipation of the minor child, and anticipated order
termination date.

Members track activities and actions taken on cases through use of
Microsoft Excel spreadsheets, Microsoft Outlook "search" capabilities,
index file cards, and service agreements with states to create download
files at a cost.

Workgroup members all ascribe to Full Faith and Credit standards in
processing of foreign cases

The workgroup acknowledged an ongoing enforcement issue with orders
referred to states for enforcement. States often use enforcement
remedies that the workgroup member are not authorized to take.

Case closure processes in place include having the case signed off by
more than one person or level of authority, and sending two separate
letters to the custodial parent (CP) prior to closure. workgroup members
do not close a case when the CP goes off TANF until all the arrears have
been satisfied.

Case closure points of consensus:

-   The Model TCSES should include some kind of sign-off process by the
    supervisor before the case is actually closed in the Model TCSES.

-   The Model TCSES should alert the caseworker 60 days after the first
    case closure notice is sent.

### Enforcement

Workgroup members expressed a need to identify remedial contempt orders
and track compliance with job searches and other activities associated
with remedial contempt. Remedial contempt process items that might be
tracked include whether the non-custodial parent (NCP) takes required
action(s), follows the rules for job searches, and applies for tribal
general assistance.

The workgroup agreed that generating enforcement notices and letters
should remain primarily a manual process. However, the group also
recommended that whenever a document is generated, the system should
have the capability to create a tickler or alert.

The Model TCSES should notify the caseworker when a payment has not been
received.

Enforcement remedies in use include income withholding, federal tax
intercept, bank levies, liens, hunting and fishing license suspension,
fishing tax, gaming license suspension, passport denial, and per capita
intercept.

For per capita intercepts, information has to be tracked on the tribe,
the frequency of payout, and steps that are necessary to intercept the
payment.

### Financial Management

Workgroup members use simple interest, and do not charge interest on
fees.

Desired Model TCSES capabilities in payment processing:

-   Capability to track, distribute and disburse child support payments.

-   Capability to print checks.

-   Ability to support interest calculations.

-   Capability to make adjustments to the account balances and allow
    workers to record case notes associated with the adjustments.

-   Capability to set up multiple "buckets" or debts.

Some tribal child support programs accept payments directly from NCPs;
others require payments to be accepted through tribal financial systems.

In-kind payments are handled differently from one program to another.
However, it is generally presumed that the in-kind payments are being
made unless the CP says that they aren't. Care has to be taken to ensure
that a check is not generated to a CP based on an in-kind payment. A
system alert or tickler would allow a caseworker to check and see if the
in-kind payment was made.

Workgroup members expressed interest in adding electronic funds transfer
capabilities to their programs in the future.

### Reports 

Workgroup members expressed interest in system worklists or ticklers
that:

-   Inform the caseworker of automatic actions taken by the Model TCSES.

-   Allow the caseworker to delete the alert after viewing it.

-   Alert the caseworker whenever new locate information is received.

-   Allow the worker to create alerts or ticklers.

-   Alert when documents are generated.

-   Alert for timeframe-related actions (e.g. timeframes associated with
    documents).

General discussions included three kinds of alerts, including action
alerts (worker can delete, but if the action isn't taken, the system
recreates the alert overnight), information alert (worker can delete the
alert and not see it again), and self alert (tickler set by the worker
as a future reminder).

Workgroup members expressed interest in having the Model TCSES access
court calendaring functions

### Security and Privacy

Workgroup members discussed security and privacy requirements including.

-   Assignment of a system administrator to manage system security and
    access.

-   Development of worker profiles. As part of system set-up, each tribe
    must develop worker profiles for system use and access. Each tribal
    user must be assigned a user ID as a means for the system to record
    and track actions.

-   Passwords. Passwords must be required to access the Model TCSES.
    Workgroup members must determine how often passwords need to be
    changed.

-   System access. Workgroup members must determine at what level the
    Model TCSES may be accessed by auditors, accounting, technical
    staff.

Workgroup members expressed interest in having the Model TCSES maintain
audit trails, including:

-   Automatic tracking of actions related to data designated as a "key
    element." When someone changes a key element, the Model TCSES could
    store the identity of the person who logged in and made the change.

-   Automatic creation of audit trails in the case history.

For application security, the data base should reside with the tribe,
and tribes should do periodic back-ups in case of natural or malicious
damage.

Data security and system back-ups. Discussion points included the
following:

-   As part of the system design process, OCSE should consider creating
    a set of generic back-up procedures to detail how the Model TCSES
    should be backed up, recovery procedures and how to apply "patches"
    and updates to the Model TCSES.

-   Each tribe should have a plan to acquire a replacement server on an
    immediate basis, or should maintain a back-up server.

-   Each tribe must also plan for disaster recovery, including whether
    to provide a hot site or a cold site for system recovery.

Workgroup members must determine the need for remote access to the Model
TCSES by caseworkers and staff , and by clients or customers.

### System Architecture 

Workgroup members discussed a variety of demographic data, including
number of staff, number of locations, approximate IV-D caseload, level
of connectivity, access to tribal finance functions, and electronic
interfaces.

Desired agency interfaces include tribal enrollment office, tribal
court, tribal police, tribal TANF, tribal payroll office, tribal
accounting office, and tribal hearing offices.

Workgroup members recognized that it is not possible for the Model TCSES
to include built-in capability to interface with state systems, because
state systems are too varied in nature. However, workgroup members
should be able to develop their own interfaces independently through
agreements with their state counterparts. Where a tribe elects to work
with a state in developing an interface or some type of data exchange,
they should ensure the interface includes a means of getting case
updates.

Tribes should retain backup data for at least three years, but may
retain data for longer if required by tribal procedure. If the system is
the official record keeper of the financial data, payment histories may
need to be retained indefinitely.

Once a tribe implements the Model TCSES, OCSE expects the tribe to
commit to using the system for a specific period of time in order to
make the system development effort cost effective.

When the Model TCSES is ready to be implemented, the tribe's current
tribal IV-D cases need to be converted to a format usable by the system.
After discussion, workgroup members agreed on an approach to data
conversion in which the Model TCSES would have the capability to read a
standard tribal case record which OCSE would define as part of the
development effort. The workgroup agreed that it would be each tribe's
responsibility to put their data into the standard record format, which
could then be loaded onto the Model TCSES.

## Business Rules and Processes

During this portion of each JAD session, the workgroup participated in
documenting the process flows and specific business rules related to the
CSE functions of intake, locate, paternity, establishment, and
enforcement. Each process flow and rules were refined in succeeding JAD
sessions as input to the ongoing system design process.

Key points of discussion are summarized below.

### Case Intake Processes

Workgroup members noted a distinction between capture versus
verification of information: information captured during Intake process
would need to be verified at a later time, not during Intake. It should
be a management issue for each tribe to determine the demographic data
that must be entered, beyond the minimum data needed by the system to
establish a case.

The workgroup discussed common and unique processes for case types of
Non-IV-D, IV-D, TANF IV-D, kinship care, foster care, medical support
only, foreign only, and arrears only. The workgroup recommended that any
change made to case type be recorded in case history.

Workgroup members agreed on the mandatory minimum data needed to
complete an application for service, including applicant, participant,
and dependent data. Workgroup members agreed on the basic processes that
the Model TCSES should support for each case type.

Recommendations included a case notes capability to capture information
to pass along to other staff members, and creation of an employer
dataset so that workers would not have to enter the same employer
address multiple times.

For TANF referrals, workgroup members agreed that the same screens and
information should be used as for non-TANF cases, with the addition of
TANF case identifiers and Medicaid data.

Workgroup members were in agreement that the Model TCSES should look at
all the data and assess where the case should go next for further
processing.

### Locate Processes

Workgroup members were in agreement that locate processes differ from
tribe to tribe. In order to identify the processes mutual to the
majority of tribes, the workgroup undertook detailed discussions of the
types of locate sources used, generation and content of postmaster
letters, and the overlap between locate and income withholding
activities. The workgroup agreed that the initial system may produce and
monitor locate letters, but that other locate efforts would be done
manually.

### Paternity Establishment Processes

There are significant differences in how tribes process paternity cases.
In order to identify the processes mutual to the majority of tribes, the
workgroup discussed in detail their current processes for paternity
questionnaires and affidavits, service of process, and genetic testing
data and processes. To accommodate their key points of difference,
workgroup members recommended that the Model TCSES:

-   provide a means to record actions taken rather than to take actions
    automatically, and

-   not enforce a set workflow through the paternity process, but offer
    a menu of available actions and options.

In court documents, the workgroup agreed that the system may consider
case number and docket number to be the same.

### Order Establishment Processes

The number and type of documents for establishment of a child support
order varies by tribe. Workgroup members agreed that when an account is
set up in the Model TCSES, the system would require that a second person
approve the account, affording a separation of duties.

The workgroup agreed that components of a payment may be treated by the
system as separate obligations for tracking purposes. Examples include
current support, arrears (to agency), custodial arrears, state-ordered
arrears, child care, medical support, fees set in judgment as paternity,
interest, vital record fees, court costs, genetic testing, publication
fees, tribal TANF, and attorney fees.

Workgroup members agreed that the system does not need to generate a
certification and verification document. If needed, the document would
be treated as a standard office form.

The workgroup recommended the capability to save orders generated by the
system through a mechanism such as Portable Document Format (PDF).
Discussion of imaging documents not created on the system was deferred.

Guidelines calculation should be completed through use of a stand-alone
module, at least for the initial iteration of the system, due to the
variability of current guideline calculations. The Model TCSES should
include a stand-alone module for guidelines calculations. Workers would
perform guideline calculations according to tribal procedure in the
stand-alone module, then enter the results into the TCSE system.

### Case Management Processes

Workgroup members agreed that case history should track key data such as
the change that was made, the change date, and the logged-in user who
made the change. Case history should capture data automatically created
by the system. Case history should also include case notes entered by
workers.

In discussing tickler or worker "to do" lists, there was consensus on
three types of alerts, including action alerts (system-generated notice
to workers or supervisors that action is necessary), information alerts
(system-generated notice that action has been taken in or by the
system), and worker-generated alerts (worker-generated reminder or note
to be displayed on a chosen future date).

The workgroup discussed consolidation of cases versus consolidation of
orders. Workgroup members concurred with the following general
definitions. Consolidation of cases is separate from consolidation of
orders. To consolidate a case involves closing one case and adding
persons to the other case. Court involvement is not needed to
consolidate a case. Consolidation of orders requires court involvement.

In discussing review and modification of orders, Workgroup members
determined that all perform at least one review every three years, and
also provide reviews upon request. However, tribes vary on the specific
timeframes for conducting a review, and also vary on what is considered
a substantial change. There was no consensus on a common review process,
but all agreed that if the person requesting the review does not return
requested information within 30 days, the review action may be closed.

When an order is modified, workgroup members agreed that the order
serves as the notice to both parties.

Workgroup members agreed that the first iteration of the system should
include a restricted set of criteria for suggesting when case closure
might be appropriate. Closing a case should place it in a "turned off"
status but not delete it from the system.

### Enforcement Processes

Workgroup members recommended that the system include a mechanism to
suppress enforcement remedies (and associated documents) that may not be
available to tribes in general or to a particular tribe.

There was consensus that the system include capability to pursue per
capita intercept or to generate documents for per capita intercept.

Workgroup members agreed that tribal licenses can be suspended without
suspending state licenses and should be handled separately by the
system.

Members recommended the system include a process for voluntary
assignment and associated documents.

There was consensus that the system should provide for an order to
appear before the elders, similar to a court order to appear, like an
order to show cause.

There was consensus that the system does not need to generate an order
to seize; that action may be taken outside the system or as part of a
court order.

### Financial Processes

The workgroup discussed specific processes in place to receive, post,
and distribute payments including direct payments. Discussion topics
included fees, payment types, offset types, payment frequencies,
financial notices, financial audit trail, and the timeframes associated
with financial processes.

The workgroup concurred on the accounting practice of separation of
duties in which the worker who creates a particular payment batch must
not be the same one to post those particular payments to case accounts.

Members had ongoing and detailed discussions of distribution processes,
including whether or when the system should place a priority on tribal
arrears in the distribution schema. The workgroup agreed on a general
distribution hierarchy, placing emphasis on current support first,
arrears second, and judgments last. However, the workgroup acknowledged
that distribution processes varied between tribes at the detail level,
i.e., how money is distributed for foster care or kinship care cases.
The workgroup also assessed the complexities presented by distribution
of excess payment for arrears, where state arrears exist alone or in
addition to tribal arrears.

The workgroup identified differences in how child support arrears
judgments are handled differently from judgments for other costs or
state fees.

Workgroup members recommended a system capability for transaction
adjustments to adjust the balance where payments have been made
directly, allowing the NCP to receive credit but at the same time
prevent a check from being created for the CP.

The workgroup concurred in recommending that the system allow tribes to
change the order of the fees hierarchy for payment.

The workgroup also agreed on processes to address seasonal work
payments, i.e., the capability to post to futures when there is money
left after all distribution is done.

After extended discussion of the existing variances in practice on
judgments and debt collection, the workgroup agreed that the system
processes should not address statutes of limitation on debt.

Workgroup members discussed the content and frequency of a variety of
financial reports. It was agreed that the system would be structured to
support a significant range of financial reports. It was understood,
however, that the initial iteration of the system might not include
development of all of the reports discussed.

Reports (and discussion highlights) included: suspended payments aging
report (weekly or on demand), checks returned for non-sufficient funds
(weekly), adjustments (daily and on demand within date range), stale
dated warrants. state write offs, collections report, distributed
collections (by debt type, etc.), undistributed collections (must
include reason), disbursement summary, review and adjustment,
delinquency (monthly and quarterly), arrears (quarterly), account
history, income withholding, in-kind, kinship care (quarterly and on
demand), foster care (quarterly and on demand), TANF case report
(quarterly and on demand), bank reconciliation, collection receipt (not
needed). receipt batch log and payment balance reconciliation (on demand
and on line), payments within a deposit.

Members recommended that the system support (i.e., provide the data
needed for) selected management reports, including the top two sections
of the OCSE 34A (quarterly), tribal portions of the SF 269, program
income (quarterly and on demand), annual statistical report, tribal
affiliation (quarterly and on demand), new hire report (daily, weekly),
as well as reports on workload statistics, case aging, case type, case
actions, emancipation, cases closed, cases open with no order,
paternity, intercept, and order establishment.

### Security and Administration Processes

Workgroup members concurred on processes to incorporate several layers
of security related to system access, including initial logon and
password for access to the TCSE application, with limits set for
password changing and access attempts, the creation of user profiles to
restrict user view and create/update capabilities throughout the TCSE
system., and field-level security for critical data fields.

Workgroup members agreed that the period of time in which passwords need
to be reset can be determined by the tribe during system configuration.
However, lockout after three attempts is not configurable.

The workgroup reviewed and discussed the items that should be
configurable by each tribe as part of setting up and customizing the
system for use. The workgroup developed agreements on the configurable
data values for tribal information, CSE contact information, court
contact information, participant information on race and clanship,
enforcement options and thresholds, timeframes for action, document
format and automatic generation options, automatic income withholding,
financial functions and interest handling.

### Data Elements and Data Dictionary

Throughout the four JAD sessions, workgroup members reviewed each of the
data elements utilized in the process flows, discussing and achieving
consensus on definitions and usage. Examples include: it was agreed that
at this time, the only data elements needed in the system for family
violence and for good cause would be "Yes" and "No;" other information
should be maintained outside the system in written files. By the end of
the four JAD sessions, workgroup members had developed a mutually
acceptable list of data elements recommended for inclusion in the
initial iteration of the system.

## Next Steps 

Some discussion items may need additional clarification by workgroup
members, either in a future workgroup setting or through ongoing
conversations with Federal support staff. These include:

-   Not printing CP addresses on documents at CP request as a courtesy
    even if there is not enough evidence for a Family Violence
    Indicator.

-   Primary and secondary case status as indicators to the system to
    push the case to the next worker appropriately. Members agreed on
    the concept of primary case status (paying or not) but agreed to
    table discussion of criteria for secondary case status. For example,
    an unverified address for CP or NCP might not necessarily advance a
    case to locate functions.

-   The need for a batch process for per capita intercept.
    Considerations include the need to produce separate notices for
    individuals and a consolidated report for the court.

The next activities toward the development of a Model TCSES include
completion of a Feasibility Study and Impact Analysis by the Federal
support team, and developing an approach to secure funding for further
phases of system design and development.