Feasibility Study for a Data and Document Exchange Capability Between
CSE Agencies and Courts

Table of Contents

[1. EXECUTIVE SUMMARY 1](#executive-summary)

[1.1 Requirements Definition 1](#requirements-definition)

[1.2 Alternatives and Cost/Benefit Analysis
1](#alternatives-and-costbenefit-analysis)

[1.3 findings 2](#findings)

[2. Introduction 3](#introduction)

[2.1 BACKGROUND 3](#background)

[2.2 Approach 3](#approach)

[2.3 assumptions 5](#assumptions)

[3. requirements definition 6](#requirements-definition-1)

[3.1 overview of the business process
6](#overview-of-the-business-process)

[3.1.1 Establishment 6](#establishment)

[3.1.2 Order Enforcement 6](#order-enforcement)

[3.1.3 Review and Adjustment 7](#review-and-adjustment)

[3.1.4 Interstate Information Exchange
7](#interstate-information-exchange)

[3.2 Exchange/Interface Requirements 7](#exchangeinterface-requirements)

[3.2.1 Alternative Specification Requirements
8](#alternative-specification-requirements)

[3.2.2 Alternative Feasibility Requirements
14](#alternative-feasibility-requirements)

[3.3 Supporting Documents 15](#supporting-documents)

[3.3.1 National Task Force on Court Automation and Integration, Court
Technology Survey Report
15](#national-task-force-on-court-automation-and-integration-court-technology-survey-report)

[3.3.2 General Overview and Background Child Support XML Standards
16](#general-overview-and-background-child-support-xml-standards)

[3.3.3 Draft Child Support XML Specification for IV-D Agency Review
17](#draft-child-support-xml-specification-for-iv-d-agency-review)

[3.3.4 Court and CSE Data Cross Reference and Data Dictionary
18](#court-and-cse-data-cross-reference-and-data-dictionary)

[3.3.5 Child Support XML Standards Requirements Document
18](#child-support-xml-standards-requirements-document)

[4. Alternatives Analysis 19](#alternatives-analysis)

[4.1 Introduction 19](#introduction-1)

[4.2 Alternative Descriptions 19](#alternative-descriptions)

[4.2.1 Alternative 1 -- XML-based Interface
19](#alternative-1-xml-based-interface)

[4.2.2 Alternative 2 -- Traditional System-to-System Interface
(Colorado)
20](#alternative-2-traditional-system-to-system-interface-colorado)

[4.2.3 Alternative 3 -- Imaging (Washington)
21](#alternative-3-imaging-washington)

[4.3 Common Requirements 22](#common-requirements)

[4.3.1 Organizational Requirements 22](#organizational-requirements-1)

[4.3.2 Operational Requirements 22](#operational-requirements-1)

[4.3.3 Legacy System Modification Requirements
22](#legacy-system-modification-requirements-1)

[4.4 Alternative Evaluations 22](#alternative-evaluations)

[4.4.1 Alternative Specification Requirements Evaluation
23](#alternative-specification-requirements-evaluation)

[4.4.2 Alternative/Requirement Detailed Evaluation
24](#alternativerequirement-detailed-evaluation)

[4.4.3 Interstate 26](#interstate)

[5. Cost/Benefit Analysis 28](#costbenefit-analysis)

[5.1 Costs 28](#costs)

[5.2 Benefits 29](#benefits)

[6. Recommendations 31](#recommendations)

[6.1 Recommended State Activities 31](#recommended-state-activities)

[6.2 Next Steps 32](#next-steps)

[6.2.1 Expand LegalXML DTD 32](#expand-legalxml-dtd)

[6.2.2 Complete Detailed Cost/Benefit Analyses
32](#complete-detailed-costbenefit-analyses)

[Appendices 34](#__RefHeading___Toc37493058)

[A. interview guide 34](#__RefHeading___Toc37493059)

[B. interview summary 36](#__RefHeading___Toc37493060)

[C. Interview Notes 38](#__RefHeading___Toc37493061)

[D. National Survey of Court Information Technology Status
72](#__RefHeading___Toc37493062)

[E. General overview and background child support XML standards
73](#__RefHeading___Toc37493063)

[F. Draft child support XML specification for iv-d agency review
74](#__RefHeading___Toc37493064)

# EXECUTIVE SUMMARY

This feasibility study examines the viability of an electronic data and
document exchange capability between state Child Support Enforcement
(CSE) agencies and their respective courts. The intent of an electronic
exchange capability is to benefit states by saving time and improving
the accuracy of data and documents exchanged.

## Requirements Definition

This feasibility study was conducted in two phases. During the first
phase, requirements for a data and document exchange capability were
defined. Numerous documents and background materials influenced the
requirements specified in this study, particularly the proposed child
support document type definition (DTD) created by the child support XML
workgroup. In addition, a representative sample of states and courts
were surveyed to determine the level of automation that exists, how data
and documents are currently exchanged, how states and courts would like
to exchange information, and the possible benefits of an electronic
exchange capability. The many state and court individuals who
participated in this study are commended and sincerely thanked for their
time and effort.

This study documents basic requirements that must be met for the
achievement of a successful interface/exchange. Requirements are
identified for the following categories:

-   Data -- includes case, person (obligor, obligee, and child\[ren\]),
    financial, and event

-   Processing

-   Technical

-   Organizational

-   Operational

-   Legacy System Modification

These requirements are not detailed systems development requirements,
but were used as factors for evaluating various alternatives for
accomplishing the objective of a specific exchange of information
between states and courts.

## Alternatives and Cost/Benefit Analysis

Alternatives were derived from further analysis of the current best
practices from states and courts. Alternatives were assessed against the
requirements to determine their feasibility. Each alternative was also
assessed for its suitability to support interstate exchange. The
alternatives described and evaluated in this study are:

-   XML-based interface

-   Traditional system-to-system interface (Colorado based)

-   Imaging (Washington based)

While developing a detailed cost/benefit analysis for the identified
alternatives is not possible due to the many variables that are unique
to each state and court, a general comparison of costs is presented. In
addition, alternatives were assessed against a standard list of possible
benefits.

## findings

A solution employing XML is deemed the preferred solution for exchanging
data and documents between CSE agencies and their courts. An XML
solution best meets the requirements specified in this study, is less
expensive relative to the other alternatives evaluated, and provides the
best possibility for extension to interstate data exchange. Several
activities are recommended for states to complete if they wish to pursue
any data and document exchange solution. First and foremost is
completing a detailed cost/benefit analysis that considers all the
variables unique to a state and court, including staffing, technical
environment, training, and operational commitment. Due to the sluggish
economy and state budgets stretched to the maximum, a comprehensive
assessment is needed to justify the pursuit of any solution.

To pursue an XML solution, recommended next steps include the following:

-   Pursue continuation of the work completed to date by the child
    support XML workgroup to expand the draft DTD. Use the XML DTD as a
    guide and build a "palette" based on the data available in this
    study, data elements from CSENet, information identified and defined
    by the Interstate Workgroup, and more.

-   Select three states and complete detailed cost/benefit analyses to
    further validate the XML endorsement reflected in this study.

OCSE may also consider pursuing opportunities to provide XML exposure to
states via training courses, conference presentations and workshops, and
materials available on the OCSE website.

# Introduction

The Office of Child Support Enforcement (OCSE) contracted with the State
Information Technology Consortium (SITC) to complete a feasibility study
for a data and document exchange capability between state Child Support
Enforcement (CSE) agencies and their respective courts. The primary
objective of this task is to determine the viability of an electronic
data and document exchange capability, given the current level of
automation that exists within the courts. The intent is to benefit
states by saving time and improving the accuracy of data and documents
exchanged between state CSE programs and the courts. For example, if all
parties could agree that specific transmitted information serves as a
court order, staff would not have to wait for a paper copy of the court
order prior to case prosecution.

## BACKGROUND

The SITC Statement of Work mentions the effort of a workgroup --
composed of state, court, and Federal staff -- focused on exchanging
information with and between state CSE agencies and their respective
courts using XML (e**X**tensible **M**arkup **L**anguage). This
workgroup analyzed the current electronic court filing standard to
determine if the standard could support the data needed for court filing
by child support agencies, as well as the data that courts send back to
child support agencies. A draft document type definition (DTD)
specification was prepared under a Special Improvement Project (SIP)
grant awarded to the National Center for State Courts (NCSC) by OCSE.
The intent of this working group was to produce a draft standard within
the Court Filing Work Group of LegalXML for formal adoption through the
Conference of State Court Administrators and the National Association
for Court Management. At this time, the costs of an electronic data and
document exchange capability have not been weighed against the benefits.
It may or may not be beneficial to wait until the court systems become
more automated.

## Approach

This study of the feasibility of a data and document exchange capability
between state CSE agencies and their respective courts was conducted in
two phases. The initial phase focused on conducting research and
analysis of current file transfer technologies, business needs met by
such a transfer, best practices from selected states, and previous work
completed by court, state, and Federal workgroups. The principle output
from the initial phase was basic requirements that must be met for the
achievement of a successful interface/exchange of information between
the states and their courts. The requirements provided in this report
are not to be considered as detailed systems development requirements.
They are to be used as factors for evaluating various alternatives for
accomplishing the objective of a specific exchange of information
between states and courts. The requirements are grouped into two basic
categories. The first category, Alternative Specification Requirements,
includes data, processing and technical requirements of each
alternative. The second category, Alternative Feasibility Requirements,
includes organizational, operational and legacy system modification
requirements that are considered to be overarching requirements and
apply to the feasibility assessment of each alternative. The
requirements are provided in Section 3 of this document.

The second phase of the effort focused on identifying and describing
alternatives for achieving information exchange in a standard manner
that would facilitate evaluation. The alternatives were derived from
further analysis of the current best practices from states and industry
best practices in the use of new technology to accomplish information
exchange. The alternatives were assessed against a set of criteria
(derived from the requirements) and their level of feasibility is
documented in this study. Each alternative was assessed for cost and
benefit. The cost/benefit analysis is documented at a general level
since specific costs for each state and court are dependent on their
current situation relative to automation.

As part of completing this study, research was conducted and a
representative sample of states and courts were surveyed to determine
the level of automation that exists, how data and documents are
currently exchanged, and how states and courts would like to exchange
information. A facet of this research was also to identify the benefits
to states of an electronic data and document exchange capability. The
survey information was used to derive requirements as well as evaluate
best practices to support alternative development. To effectively
conduct these interviews, a structured interview guide was developed
(presented in Appendix A). The interview guide contains questions that
directly contributed to this deliverable, as well as assisting in the
alternatives analysis and cost/benefit analysis. Appendix B contains a
summary table as a quick reference for each of the interviews and
corresponding analysis and Appendix C contains the interview notes. The
many state and court individuals who participated in this study are
commended for their time and effort.

Additionally, during the information gathering process, documentation
and background material was reviewed. Information contained in this
deliverable reflects data collected from documentation provided by OCSE
and the National Center for State Courts.

The following is a list of documentation used for the study:

-   Volume 3 -- Domestic Relations Case Processing System Functional
    Standards, November 26, 2001

-   OASIS LegalXML Member Section Electronic Court Filing Technical
    Committee DRAFT Electronic Court Filing 1.1 Proposed Standard, July
    12, 2002

-   Draft for Consideration by National Consortium for State Court
    Automation Standards and COSCA/NACM Joint Technology Committee,
    Standards for Electronic Filing Processes, July 12, 2002

-   Georgia Courts Automation Commission Court Filing Interoperability
    Pilot Lessons Learned Document, December 4, 2001

-   Georgia Courts Automation Commission Court Filing Interoperability
    Pilot Lessons Learned Document II, May 20, 2002

-   Electronic Filing of Court Documents, by Judge (Ret.) Arthur M.
    Monty Ahalt, April 1999

-   Colorado documentation on automation of limited case registry and
    payment processing

-   National Task Force on Court Automation and Integration, Court
    Technology Survey Report, October 18, 2001 (this is the National
    Survey of Court Information Technology Status document specified in
    the SITC Statement of Work)

-   General Overview and Background Child Support XML Standards,
    February 22, 2002

-   Draft Child Support XML Specification for IV-D Agency Review,
    February 22, 2002

## assumptions

The following assumptions were made in the development of the
requirements analysis and feasibility study:

-   No preconceived opinion on the best alternative for the information
    exchange

-   Multiple technologies that can satisfy the requirements are
    evaluated

-   Not all alternatives meet all requirements

-   Each state has a unique relationship with their respective courts
    and each alternative will not necessarily be applicable for all
    states and their courts

-   Documentation for this study was analyzed for the purpose of
    defining requirements and alternatives

# requirements definition

## overview of the business process

A basic understanding of the business requirements between the states
and their courts is a critical baseline for the requirements definition.
It is important to have a basic understanding of the interaction between
state CSE agencies and courts. Knowing that technology can provide the
ability to pass almost any information back and forth is not the
objective of the exchange/interface. To clarify the basic business
process framework applicable to the exchange requirements, a brief
generic description of the state and court business processes relevant
to this study is provided below. The exchange must be able to support
the basic business flow between CSE agencies and the courts.

CSE case processing begins with intake or case initiation, which
includes receipt and processing of applications received from non-TANF
clients and receipt and processing of TANF referrals. The CSE agency
caseworker makes a determination of services required at the time of
application or referral.

Basic areas where the CSE agency interacts with the courts include:

-   Establishment -- Paternity and Orders

-   Order Enforcement

-   Review and Adjustment

Another area to consider is interstate information exchange. The
capability to electronically share information state to state to
expedite interstate case processing is another facet of consideration
for this study.

### Establishment

Establishment is the function by which paternity, child support orders
and/or medical support orders are established. Paternity can be
established via voluntary acknowledgement or via court-ordered paternity
testing. Paternity can also be adjudicated. Child support and medical
support orders are established by the courts or, in
administrative-process states, by an executive agency rather than by
courts and judges. The child support order can dictate frequency,
amount, type of support, duration, and whether wage withholding is
mandated. Medical support orders specify how children are provided with
health insurance coverage. Child support order amounts are based on
child support guidelines, which are income-based formulas that vary by
state.

### Order Enforcement

Enforcement of support orders is the application of remedies to obtain
payment of an obligation contained in a support order. Examples of
remedies include wage withholding, asset seizure, liens, license
revocation, and U.S. passport denial.

### Review and Adjustment

Review and adjustment is the process in which current financial
information is obtained from both parties in a child support case and
evaluated to determine if a support order needs to be adjusted. Reviews
occur according to a recommended review cycle but can also occur upon
the request of either party. For TANF cases, reviews can occur upon the
request of either party or the CSE agency.

### Interstate Information Exchange

Interstate cases, where the dependent child(ren) and non-custodial
parent live in different states (or where two or more states are
involved with some case activity), require states to exchange case data,
such as financial, court order, and case status information. Because of
our mobile society, approximately one third of all child support cases
involve parents living in different states. Interstate cases represent
approximately 20-30% of the total child support caseload but only 10% of
collections. By providing CSE agencies nationwide with a way to exchange
information efficiently, states would have the tools necessary to
expedite the enforcement of orders in interstate cases and improve the
current collection ratio.

## Exchange/Interface Requirements

The scope of what is being exchanged between the states and courts has
as its foundation the process flow within the state CSE agencies and the
courts. There are and always will be unique aspects to the CSE business
within both the state and court environments. The diagram below depicts
in a simple manner the scope of the exchange. Some of the work already
completed by various committees and workgroups indicates that not all of
the common data could be exchanged. However, other sources within the
states have indicated that a broader set of data should be the scope of
the exchange.

The requirements for the CSE agency/court exchange/interface are
described below. The requirements are documented using the following
categories:

-   Alternative Specification Requirements

```{=html}
<!-- -->
```
-   Data Requirements

-   Processing Requirements

-   Technical Requirements

```{=html}
<!-- -->
```
-   Alternative Feasibility Requirements

```{=html}
<!-- -->
```
-   Organizational Requirements

-   Operational Requirements

-   Legacy System Modification Requirements

It is important to recognize that the requirements are documented to
support the assessment of the feasibility of alternatives for the
exchange/interface and not for the development of the
exchange/interface. The requirements presented here are not intended to
be used by a given state or court to implement a state/court interface.
Studies have already been conducted that indicate the technology to
exchange documents and data is available. The requirements identified as
part of this effort focus not so much on **can** we exchange data in an
automated manner, but **should** we exchange the data in an automated
manner **at this time**. Therefore, the feasibility assessment of a
given alternative that meets the requirements is based on more than just
technology.

### Alternative Specification Requirements

#### Data Requirements

Requirements for the exchange/interface between the CSE agency and the
courts pertaining to data are provided in this section. The data
elements were extracted from the interviews conducted and from materials
obtained from OCSE and the National Center for State Courts.
Specifically, the data elements incorporate those specified by the XML
workgroup and documented in the Draft Child Support XML Specification.
These inputs have been analyzed; the resulting list of data requirements
reflects the summation of this analysis.

Requirement 1: The exchange/interface must be able to handle data that
is structured both by case and person. The source and destination
systems are either case oriented or person oriented, which means that
the basic processing unit is either the case or the persons involved in
the case. The basic data groups provided below are generic so as to
represent both case and person oriented situations.

Case Data

  -----------------------------------------------------------------------
  **DATA ELEMENT**               **DESCRIPTION**
  ------------------------------ ----------------------------------------
  Docket Number (Court Case      The number assigned to the case filed in
  Number)                        a particular court. Also called a case
                                 number.

  Order Commencement Date        The date that obligations start to
                                 accrue.

  Date of Order                  The date on which the order was
                                 established.

  Order Action                   Indicates if an order is a request from
                                 a CSE agency for an order of the court
                                 or a Court Action, indicating an
                                 executed order from the court.

  Order Category                 Category of order, including Establish,
                                 Modify, Enforce, Modify and Enforce,
                                 Vacate.

  Order Type                     Type of order, child support or
                                 paternity.

  Non Monetary Order             Details of the order in which payments
                                 are not required.

  Monetary Order                 Details of the order requiring payments
                                 (including maintenance, alimony, medical
                                 payments, health insurance, etc).

  Order Payor                    Name of person required to make the
                                 payment(s).

  Order Payee                    Trustee(s) for the payment; may include
                                 Child Support Agency, custodial parents,
                                 or direct payments to schools or doctors
                                 or other.

  Obligation Type                Type of obligation can be monetary or
                                 non-monetary, including attending
                                 counseling with a child, submission to
                                 blood test, one-time payment, arrearage
                                 payment, or regular monthly payment.

  Amount of Child Support Due    The final decision of the court,
                                 resolving the dispute; an opinion; an
                                 award.

  Frequency of Child Support     The frequency of child support payment
  Payment                        (e.g. Weekly, Bi-weekly, Semi-monthly,
                                 Monthly, Quarterly, Semi-annually,
                                 Annually).

  End Date/Duration              End date or duration of obligation (e.g.
                                 high school graduation).
  -----------------------------------------------------------------------

##### Person Data -- Obligor {#person-data-obligor .unnumbered}

+------------------------------+---------------------------------------+
| **DATA ELEMENT**             | **DESCRIPTION**                       |
+==============================+=======================================+
| Obligor Name                 | Name (as of time order was issued) of |
|                              | the person owing the duty of support. |
| -   First Name               | Also referred to as the non-custodial |
|                              | parent.                               |
| -   Middle Name              |                                       |
|                              |                                       |
| -   Last Name                |                                       |
+------------------------------+---------------------------------------+
| Obligor Suffix (Title)       | The name suffix (as of time order was |
|                              | issued), e.g., Jr., of the obligor.   |
+------------------------------+---------------------------------------+
| Obligor Now Known As Name    | Current name of the person owing the  |
|                              | duty of support. Also referred to as  |
| -   First Name               | the non-custodial parent.             |
|                              |                                       |
| -   Middle Name              |                                       |
|                              |                                       |
| -   Last Name                |                                       |
+------------------------------+---------------------------------------+
| Obligor Now Known As Suffix  | The current name suffix, e.g., Jr.,   |
| (Title)                      | of the obligor.                       |
+------------------------------+---------------------------------------+
| Obligor Home Address         | Home address of the obligor.          |
+------------------------------+---------------------------------------+
| > Street Address (line 1)    | Line 1 of the street address for the  |
|                              | obligor.                              |
+------------------------------+---------------------------------------+
| > Street Address (line 2)    | Line 2 of the street address for the  |
|                              | obligor.                              |
+------------------------------+---------------------------------------+
| > City                       | City for the obligor.                 |
+------------------------------+---------------------------------------+
| > State                      | State code for the obligor.           |
+------------------------------+---------------------------------------+
| > Zip Code 1                 | The first five digits of the Zip Code |
|                              | for the obligor.                      |
+------------------------------+---------------------------------------+
| > Zip Code 2                 | The last four digits of the Zip Code  |
|                              | for the obligor.                      |
+------------------------------+---------------------------------------+
| Obligor Office Address       | Office address of the obligor.        |
+------------------------------+---------------------------------------+
| > Street Address (line 1)    | Line 1 of the street address for the  |
|                              | office of the obligor.                |
+------------------------------+---------------------------------------+
| > Street Address (line 2)    | Line 2 of the street address for the  |
|                              | office of the obligor.                |
+------------------------------+---------------------------------------+
| > City                       | City for the office of the obligor.   |
+------------------------------+---------------------------------------+
| > State                      | State code for the office of the      |
|                              | obligor.                              |
+------------------------------+---------------------------------------+
| > Zip Code 1                 | The first five digits of the Zip Code |
|                              | for the office of the obligor.        |
+------------------------------+---------------------------------------+
| > Zip Code 2                 | The last four digits of the Zip Code  |
|                              | for the office of the obligor.        |
+------------------------------+---------------------------------------+
| Obligor Social Security      | Social Security Number for the        |
| Number                       | obligor.                              |
+------------------------------+---------------------------------------+
| Obligor Date of Birth        | Date of Birth (e.g., MMDDYYYY) of the |
|                              | obligor.                              |
+------------------------------+---------------------------------------+
| Obligor Home Phone Number    | Home contact phone number for the     |
|                              | obligor.                              |
+------------------------------+---------------------------------------+
| Obligor Office Phone Number  | Office contact phone number for the   |
|                              | obligor.                              |
+------------------------------+---------------------------------------+
| Obligor Email                | Email address of the obligor.         |
+------------------------------+---------------------------------------+
| Obligor Gender               | Gender code for the obligor (e.g., M, |
|                              | F).                                   |
+------------------------------+---------------------------------------+
| Obligor Attorney Name        | Name (as of time order was issued) of |
|                              | the attorney of the obligor.          |
| -   First Name               |                                       |
|                              |                                       |
| -   Middle Name              |                                       |
|                              |                                       |
| -   Last Name                |                                       |
+------------------------------+---------------------------------------+
| Obligor Attorney Bar Number  | Obligor attorney's bar number.        |
+------------------------------+---------------------------------------+
| Obligor Attorney License     | Obligor attorney's License Authority. |
| Authority                    |                                       |
+------------------------------+---------------------------------------+
| Obligor Attorney Year        | Obligor attorney's year admitted to   |
| Admitted to Bar              | the bar.                              |
+------------------------------+---------------------------------------+
| Obligor Attorney Bar Status  | Obligor attorney's bar status (e.g.   |
|                              | active, inactive).                    |
+------------------------------+---------------------------------------+

##### Person Data -- Obligee {#person-data-obligee .unnumbered}

+------------------------------+---------------------------------------+
| **DATA ELEMENT**             | **DESCRIPTION**                       |
+==============================+=======================================+
| Obligee Name                 | Name (as of time order was issued) of |
|                              | the person to whom a duty of support  |
| -   First Name               | is owed. Also referred to as the      |
|                              | custodial parent when money is owed   |
| -   Middle Name              | to the parent who resides with the    |
|                              | child.                                |
| -   Last Name                |                                       |
+------------------------------+---------------------------------------+
| Obligee Suffix (Title)       | The name suffix (as of time order was |
|                              | issued), e.g., Jr., of the obligee.   |
+------------------------------+---------------------------------------+
| Obligee Now Know As Name     | Current name of the person to whom a  |
|                              | duty of support is owed. Also         |
| -   First Name               | referred to as the custodial parent   |
|                              | when money is owed to the parent who  |
| -   Middle Name              | resides with the child.               |
|                              |                                       |
| -   Last Name                |                                       |
+------------------------------+---------------------------------------+
| Obligee Now Known As Suffix  | The current name suffix, e.g., Jr.,   |
| (Title)                      | of the obligee.                       |
+------------------------------+---------------------------------------+
| Obligee Home Address         | Home address of the obligee.          |
+------------------------------+---------------------------------------+
| > Obligee Street Address     | Line 1 of the street address for the  |
| > (line 1)                   | obligee.                              |
+------------------------------+---------------------------------------+
| > Obligee Street Address     | Line 2 of the street address for the  |
| > (line 2)                   | obligee.                              |
+------------------------------+---------------------------------------+
| > Obligee City               | City for the obligee.                 |
+------------------------------+---------------------------------------+
| > Obligee State              | State code for the obligee.           |
+------------------------------+---------------------------------------+
| > Obligee Zip Code 1         | The first five digits of the Zip Code |
|                              | for the obligee.                      |
+------------------------------+---------------------------------------+
| > Obligee Zip Code 2         | The last four digits of the Zip Code  |
|                              | for the obligee.                      |
+------------------------------+---------------------------------------+
| Obligee Office Address       | Office address of the obligee.        |
+------------------------------+---------------------------------------+
| > Obligee Street Address     | Line 1 of the street address for the  |
| > (line 1)                   | office of the obligee.                |
+------------------------------+---------------------------------------+
| > Obligee Street Address     | Line 2 of the street address for the  |
| > (line 2)                   | office of the obligee.                |
+------------------------------+---------------------------------------+
| > Obligee City               | City for the office of the obligee.   |
+------------------------------+---------------------------------------+
| > Obligee State              | State code for the office of the      |
|                              | obligee.                              |
+------------------------------+---------------------------------------+
| > Obligee Zip Code 1         | The first five digits of the Zip Code |
|                              | for the office of the obligee.        |
+------------------------------+---------------------------------------+
| > Obligee Zip Code 2         | The last four digits of the Zip Code  |
|                              | for the office of the obligee.        |
+------------------------------+---------------------------------------+
| Obligee Social Security      | Social Security Number for the        |
| Number                       | obligee.                              |
+------------------------------+---------------------------------------+
| Obligee Date of Birth        | Date of Birth (e.g., MMDDYYYY) of the |
|                              | obligee.                              |
+------------------------------+---------------------------------------+
| Obligee Home Phone Number    | Home contact phone number for the     |
|                              | obligee.                              |
+------------------------------+---------------------------------------+
| Obligee Office Phone Number  | Office contact phone number for the   |
|                              | obligee.                              |
+------------------------------+---------------------------------------+
| Obligee Email                | Email address of the obligee.         |
+------------------------------+---------------------------------------+
| Obligee Gender               | Gender code for the obligee (e.g., M, |
|                              | F).                                   |
+------------------------------+---------------------------------------+
| Obligee Attorney Name        | Name (as of time order was issued) of |
|                              | the attorney of the obligee.          |
| -   First Name               |                                       |
|                              |                                       |
| -   Middle Name              |                                       |
|                              |                                       |
| -   Last Name                |                                       |
+------------------------------+---------------------------------------+
| Obligee Attorney Bar Number  | Obligee attorney's bar number.        |
+------------------------------+---------------------------------------+
| Obligee Attorney License     | Obligee attorney's License Authority. |
| Authority                    |                                       |
+------------------------------+---------------------------------------+
| Obligee Attorney Year        | Obligee attorney's year admitted to   |
| Admitted to Bar              | the bar.                              |
+------------------------------+---------------------------------------+
| Obligee Attorney Bar Status  | Obligee attorney's bar status (e.g.   |
|                              | active, inactive).                    |
+------------------------------+---------------------------------------+

#####  {#section .unnumbered}

##### Person Data -- Child (repeated for each child) {#person-data-child-repeated-for-each-child .unnumbered}

+------------------------------+---------------------------------------+
| **DATA ELEMENT**             | **DESCRIPTION**                       |
+==============================+=======================================+
| Children Names               | All children who have not reached the |
|                              | age of emancipation or been legally   |
| -   First Name               | declared emancipated.                 |
|                              |                                       |
| -   Middle Name              |                                       |
|                              |                                       |
| -   Last Name                |                                       |
+------------------------------+---------------------------------------+
| Children Street Addresses    | Line 1 of the street address for each |
| (line 1)                     | child.                                |
+------------------------------+---------------------------------------+
| Children Street Addresses    | Line 2 of the street address for each |
| (line 2)                     | child.                                |
+------------------------------+---------------------------------------+
| Children Cities              | City for each child.                  |
+------------------------------+---------------------------------------+
| Children State's             | State code for each child.            |
+------------------------------+---------------------------------------+
| Children Zip Code 1          | The first five digits of the Zip Code |
|                              | for each child.                       |
+------------------------------+---------------------------------------+
| Children Zip Code 2          | The last four digits of the Zip Code  |
|                              | for each child.                       |
+------------------------------+---------------------------------------+
| Children Social Security     | Social Security Number for each       |
| Numbers                      | child.                                |
+------------------------------+---------------------------------------+
| Children's Gender            | Gender for each child.                |
+------------------------------+---------------------------------------+
| Children Dates of Birth      | Date of Birth (e.g., MMDDYYYY) for    |
|                              | each child.                           |
+------------------------------+---------------------------------------+

##### Financial Data {#financial-data .unnumbered}

  -----------------------------------------------------------------------
  **DATA ELEMENT**               **DESCRIPTION**
  ------------------------------ ----------------------------------------
  Remitter Name                  Name of Person/Organization (e.g.
                                 employer) remitting payments to the
                                 person entitled to receive the payments.

  Remitter Contact Name          Name of person responsible for remitting
                                 the payments.

  Remitter Street Address (line  Line 1 of the street address for the
  1)                             remitter.

  Remitter Street Address (line  Line 2 of the street address for the
  2)                             remitter.

  Remitter City                  City for the remitter.

  Remitter State                 State code for the remitter.

  Remitter Zip Code 1            The first five digits of the Zip Code
                                 for the remitter.

  Remitter Zip Code 2            The last four digits of the Zip Code for
                                 the remitter.

  Remitter Phone Number          Contact phone number for the remitter.
  -----------------------------------------------------------------------

##### Event Data {#event-data .unnumbered}

  -----------------------------------------------------------------------
  **DATA ELEMENT**               **DESCRIPTION**
  ------------------------------ ----------------------------------------
  Court Calendar (scheduled      Scheduled events such as court
  events)                        appearance dates.

  -----------------------------------------------------------------------

Requirement 2: The exchange/interface must employ cross-references (i.e.
the capability to connect cases to participants).

Requirement 3: The source system fields must be mapped to the
destination system fields with respect to format, data type, etc.

Requirement 4: Algorithms must be established to address variances in
source and destination field attributes (for example, if the source
system captures a 2-line address field and the destination system
captures a 1-line address field, the interface has to recognize and
remember those differences).

Requirement 5: The interface must have the ability to recognize and tag
data items that are considered confidential.

#### Processing Requirements

Requirements for the exchange/interface between the CSE agency and the
courts pertaining to processing are provided in this section.

Requirement 1: The exchange/interface must operate independently of the
state and court systems (for example, if the interface fails, the CSE
agency and court systems are not negatively impacted).

Requirement 2: The generation of the files to be exchanged must be
completed without user intervention.

Requirement 3: Upon completion of an exchange, a record of the exchange
must be generated (a complete audit of all transactions must be
provided).

Requirement 4: The conversion of data from source to destination must be
done without user intervention (no manual loading of data).

Requirement 5: The exchange/interface must be initiated based on
triggers in the source system as well as by the request of state or
court staff.

Requirement 6: Paper exchange of data will be reduced.

Requirement 7: The exchange/interface must be able to accommodate the
data contained in the following documents and forms and also structure
the data for exchange and presentation.

[Documents]{.underline}

-   Orders for Support

-   Contempt Orders

-   Default Orders

[Forms]{.underline}

-   Petitions to Establish Paternity & Support

-   Petitions to Contempt

-   UIFSA Petitions

-   Depositions

-   Continuances

-   Service Process

#### Technical Requirements

Requirements for the exchange/interface between the CSE agency and the
courts pertaining to the technical aspects of the interface are provided
in this section.

Requirement 1: The exchange/interface must be hardware independent.

Requirement 2: The exchange/interface must be able to handle multiple
source/destination hardware configurations.

Requirement 3: The interface development language must be open and
interpretive.

Requirement 4: The exchange/interface must be able to handle multiple
source/destination operating systems and database management systems.

Requirement 5: The exchange/interface will flag incomplete information
if sent from the source system (for example, data requiring
verification, authorization, and/or approval will not be exchanged
unless flagged as being unverified).

Requirement 6: The exchange/interface must be self-describing (i.e. the
structure and content together in each document).

Requirement 7: The exchanged document must be human readable (i.e.
special tools must not be necessary for processing by computers).

Requirement 8: The exchanged documents must separate data from
presentation.

Requirement 9: Any software used in the exchange/interface must not be
proprietary.

Requirement 10: A mechanism of connectivity must be in place (such as
the internet, intranet, network).

Requirement 11: A security infrastructure must be in place (such as
firewalls, controlled access).

### Alternative Feasibility Requirements

#### Organizational Requirements

Requirements for the exchange/interface between the CSE agency and the
courts pertaining to organization are provided in this section.

Requirement 1: A workgroup must be established to address
standardization of interface exchange requirements, including but not
limited to data, business rules, definitions, and forms.

Requirement 2: The workgroup needs to recognize the unique
organizational structures of the state CSE agency and the courts (i.e.
state vs. county-administered, judicial vs. administrative).

#### Operational Requirements

Requirements for the exchange/interface between the CSE agency and the
courts pertaining to operations and on-going maintenance are provided in
this section.

Requirement 1: Organizational responsibility for the operation and
maintenance of the interface must be assigned/established.

Requirement 2: Resources beyond the initial implementation to support
on-going operations and maintenance must be planned.

Requirement 3: Source and destination information technology (IT)
organizations must take responsibility for maintaining the transaction
file generation function.

#### Legacy System Modification Requirements

Requirements for the exchange/interface between the CSE agency and the
courts pertaining to legacy system modification are provided in this
section.

Requirement 1: The legacy systems must have the capability of creating
the data set to be exchanged.

Requirement 2: The legacy systems must have the capability of accepting
an electronic update without user intervention.

Requirement 3: The legacy systems must be able to accept both total
record updates and partial record updates.

Requirement 4: The legacy systems must notify workers when the
exchange/interface updates the database.

Requirement 5: The legacy systems must be able to edit for required data
elements from the exchange/interface.

Requirement 6: The legacy systems must be able to report errors
triggered by the interface.

## Supporting Documents

To support the identification of the requirements and the definition and
feasibility assessment of the alternatives, a number of already
completed materials on the exchange of data between courts and state CSE
agencies has been reviewed and analyzed. Some of the background material
discussed below directly impacted the identification of specific
requirements as well as the definition of alternatives.

### National Task Force on Court Automation and Integration, Court Technology Survey Report 

The National Task Force on Court Automation and Integration, Court
Technology Survey Report (specified as the National Survey of Court
Information Technology Status in the SITC Statement of Work) is one of
the specific products included as background material for the
feasibility study. This report was developed as a joint effort by:

-   The Bureau of Justice Assistance

-   Conference of State Court Administrators

-   National Association for Court Management

-   National Center for State Courts; and

-   SEARCH

The study was conducted in cooperation with:

-   National Consortium on Court Automation Standards

-   COSCA/NACM Joint Technology Committee

-   Forum for the Advancement of Court Technology Industry Working Group

The goals of the survey were:

-   To identify what vendors believe they and the courts can do to
    enable vendors to do a better job of delivering information
    technology to the courts; and

-   To identify what courts believe they and vendors can do to
    facilitate court procurement and use of information technology
    products.

In documenting requirements and alternatives for this document, no
assumptions are made as to whether or not a vendor is to be used.
Therefore, there is minimal value in this survey document related to the
analysis reflected in this study. However, one of the critical factors
in determining the feasibility of developing an exchange/interface
between state CSE agencies and their courts is the status of court
automation. More standardization exists on the state side in terms of
automation. So, the findings of this report may prove valuable if an
exchange/interface is developed and it is likely that modifications to
the legacy court systems are required.

The entire survey report can be found in Appendix D.

### General Overview and Background Child Support XML Standards

The General Overview and Background Child Support XML Standards states
as its purpose:

> "The purpose of this document is to provide a generalized,
> non-technical overview and background of XML and its use for child
> support information sharing with courts. It is intended for a
> non-technical audience with little or no knowledge of XML and the
> concepts underlying the use of the court's XML standards for sharing
> data between child support agencies and courts."

Several points are discussed in this document that apply to the effort
of defining requirements and alternatives. The document focuses on XML
as a solution for handling the complexity of passing data and documents
between courts and state CSE agencies. This document builds on the
backbone of work completed in defining electronic court filing
standards. It extends the progress made in the development of court
filing standards and examines the use of XML to go beyond just court
filings and on to the exchange between courts and state CSE agencies.
The authors conclude "the electronic court filing standard can generally
support the needs of child support agencies, with the addition of some
specific elements needed to fully transmit child support orders". This
conclusion and its further discussion within the document provided input
to the identification of requirements and influenced the feasibility
assessment of each alternative.

The document provides a brief overview of XML, a summary of the court
filing standards, a discussion of the relationship between electronic
filing and child support DTDs, and a quick guide to reading a DTD. This
document was extensively used in the description of alternatives. The
document also includes some "next step" recommendations, which were also
considered as part of the assessment.

The basic architecture of the electronic court filing standard is the
"legal envelope." It is proposed that this design could be used as the
basis for the exchange between courts and state CSE agencies. The design
is a three-part structure with:

-   Section A presents basic data about the filing,

-   Section B presents the lead document and attachments, and

-   Section C presents data describing all persons, organizations, and
    businesses (actors) related to the case.

The design assumes generic data elements and minimal use of elements
with specific coded values. The design is well considered and takes
advantage of XML capabilities. It is limited in that some elements that
are needed between courts and CSE agencies are not included and more
work on the agreement between some specific codes and values still needs
to be accomplished. It also recognizes the extreme complexity of
standardization of elements on the court side and accepts that this is
something that may impede broad implementation of the solution.

This is an alternative that must be considered. The work reflected here
indicates that using XML is a viable technical solution for the exchange
of data between courts and state CSE agencies. This document and the
Draft Child Support XML Specification document were used as the basis
for components of the alternative descriptions.

The entire document is provided as Appendix E of this report.

### Draft Child Support XML Specification for IV-D Agency Review

The Source section of this document states:

> "The draft DTD specification was prepared under a Special Improvement
> Project (SIP) grant awarded to the National Center for State Courts by
> the US Department of Human Service Office of Child Support
> Enforcement, grant award number 90F10034. This work was conducted with
> a Courts/Child Support Work Group representing court and child support
> agencies appointed by the National Center for State Courts in
> September 2001."

Section 1.1 summarizes the overall purpose of the document:

> "The overall purpose of this specification was to provide a common
> structure for improved automated information and document exchange
> between participating child support enforcement agencies (CSEA) and
> courts by using common XML interfaces for electronic filing of child
> support matters into courts and for receipt of court information and
> documents back to child support agencies from courts."

This document presents the analysis completed to support using the
electronic court filing standard as the basis for an exchange between
courts and state CSE agencies. It uses the concept of the "legal
envelope" described in Appendix E and referred to above. Some key items
defining the scope of the court/ state exchange include:

-   Calculations included in the CSE systems are not included in the
    specifications,

-   The complexity of the many entities involved in a case can be
    accommodated, and

-   Service and notice information was determined to be a court concern.

The design presented here is both sound and practical. Many of the
complexities of the exchange of data are dealt with by proposing a
solution that minimizes their impact. The solution also recognizes that
meeting some of the CSE agency data needs is not possible due to
limitations on the court side. These limitations are addressed and there
is mutual understanding that the initial iterations of the exchange will
be limited.

One of the most powerful aspects to the proposal is the workgroup's
discussion of specific business processes and business rules and how
they fit into the exchange solution. This analysis further solidifies
that the proposed use of XML is viable and can support the business
needs (limitations are noted). The analysis has been reviewed and the
workgroup's solution has been incorporated into the identification of
requirements and the development of alternatives. The XML solution
presented here is viable and considered as an alternative.

The entire document is provided as Appendix F of this report.

### Court and CSE Data Cross Reference and Data Dictionary

At the present time, SITC has not been able to locate this document,
which is specified in the SITC Statement of Work.

### Child Support XML Standards Requirements Document

The Draft Child Support XML Specification for IV-D Agency Review cites a
"separate initial child support requirements document delivered under
the \[SIP\] grant \[that\] detailed specific child support case needs,
idiosyncrasies, and mapped needed child support elements against the
ECFS \[Electronic Court Filing Standard\]". At this time, SITC has not
been able to locate this document. However, it is assumed that the
general nature of the material contained in the document is covered by
the requirements presented here in this deliverable.

# Alternatives Analysis

## Introduction

This section presents alternatives to meeting the requirements
identified in Section 3. The alternatives are identified and assessed
against the requirements to determine their feasibility. The primary
focus of the analysis is to understand the strengths and weaknesses of
the different approaches and determine which scenario offers the best
potential going forward. This approach provides states with options even
though one or more of the alternatives may in fact be a better
technological solution based on the requirements.

Each alternative is also assessed for its suitability to support
interstate exchange although interstate exchange requirements are not
specifically described.

The alternatives were derived from an assessment of previous work
completed by the child support XML workgroup (described in Section 2)
and from interviews with states and courts. The alternatives are:

1.  XML-based interface

2.  Traditional system-to-system interface (Colorado based)

3.  Imaging (Washington based)

Additional alternatives were originally documented based on what some
states are currently doing. However, when initial assessments were
completed, these alternatives were determined not feasible for states to
consider as viable options. For example, the Commonwealth of
Pennsylvania has a unique organizational structure -- the local IV-D
agency is the agency of the court. All child support activities and
court functions occur in one place. Thus, all child support transactions
are completed via the Pennsylvania Automated Child Support Enforcement
System (PACSES). Although this structure essentially eliminates the need
for the exchange (since a single system is used), it is not realistic to
assume that other states can reorganize to facilitate CSE agency and
court information exchange in this manner.

## Alternative Descriptions

Each of the three alternatives is described below. They are described in
a standard manner that facilitates their assessment against the
requirements.

### Alternative 1 -- XML-based Interface

#### General Description

This alternative encompasses the approach of the workgroup mentioned
above to exchange information between courts and states based on the XML
court standard. XML provides the ability to exchange information between
different operating systems, computer applications and databases. A
detailed description of the workgroup's approach is provided in
Appendices E and F of this document.

#### Data Description

Since the data requirements presented in Section 3 of this document are
based on the work previously completed in defining a DTD, this
alternative is consistent with the requirements.

#### Processing Description

XML is the state-of-the-art means to exchange information between
diverse hardware, operating system, and application software system
environments. Using XML, the source computer takes the data (and
separate formatting information as well) to be transmitted and converts
it to XML. The XML file is transmitted to the destination computer and
converted to the appropriate structure and format of that system. The
benefit is that XML does not care about the source and destination
environments. XML allows for the reduction of paper flow since it can
build the data in any desired format, thus avoiding the exchange of
paper documents. Also, user intervention on either end of the exchange
is not required using XML since the instructions and presentation are
also exchanged along with the data.

#### Technical Description

The greatest advantage in implementing an XML-based solution is that the
source and destination hardware, operating system, and application
system environments do not matter. This alternative does not require
modifications to source or destination environments to ensure
homogeneity in the exchange. However, this alternative does require some
sort of connectivity (LAN, WAN, Internet) to exchange the file.

### Alternative 2 -- Traditional System-to-System Interface (Colorado)

#### General Description

Colorado has an automated interface with the courts. The Integrated
Court On-line Network (ICON), the state's court case management system,
interfaces nightly with the Family Support Registry (FSR) system (also
known as the State Disbursement Unit or SDU). The FSR system is an
extension of Colorado's Automated Child Support Enforcement System
(ACSES), specifically focused on child support collections managed by
the state's SDU. This system provides functionality that supports
billing, payment processing, disbursements, income assignment issuance,
and bank reconciliation.

#### Data Description

Since the data requirements presented in Section 3 of this document
encompass the data elements exchanged via Colorado's system-to-system
interface, this alternative is consistent with the requirements.

#### Processing Description

Court clerks enter information into ICON and the information is
transferred by FTP to the CSE agency. When the court system sends a
transaction to establish an account for a new order, a new case is
automatically generated in the state's central registry. For a new case,
no user intervention is required. For modifications to existing orders,
user intervention is sometimes required to match data from the court
system with the IV-D caseload. Approximately 60% of transactions are
processed automatically. The data set includes 40-50 data elements.

Fields are marked mandatory or non-mandatory but desired. An exception
report is returned to the court system nightly that indicates rejected
records. Corrections are made the next day.

For IV-D cases, hard copies of the orders arrive at the local CSE office
prior to the electronic transmission. For non-IV-D cases, hard copies of
the orders are not required.

#### Technical Description

The FSR system is hosted on an AS400, and batch interface programs
synchronize collections data between it and ACSES nightly. The ICON
system is hosted on an AS400 also and uses a private TCP/IP frame relay
network.

### Alternative 3 -- Imaging (Washington)

#### General Description

In 1987, a Central Regulations Law was passed requiring a central area
for status updates for interstate referrals. As a result, the Division
of Child Support (DCS) in the State of Washington began work to use
imaging technology to receive and process child support orders from the
county clerks. Imaging technology permits documents or forms such as
court orders to be transmitted from the court to the CSE agency
electronically. One of the primary benefits of this approach is the
elimination of paper and expediting the time required to transmit the
document by regular mail or courier. A description of the process flow
and project status can be found in Appendix C as part of the interview
documentation for the State of Washington.

#### Data Description

The electronic transmission of a child support order is the transmission
of the document itself. This means that the process is similar to
transmitting a fax or a photographic image over the Internet (a ".GIF"
file). The significance of this is that the only benefit being achieved
is the time delay avoided that is otherwise consumed in physically
carrying/mailing the document to the intended recipient. The data and
critical information within the document is not parsed or put into a
format that software applications can use, either to store, reason on,
or otherwise interpret the information content of the scanned document.
However, Washington is investigating how to tag and transmit specific
data elements contained in the order.

#### Processing Description

The Washington DCS Imaging System uses fax machines and scanners to
transport child support orders from the courts to the State's Division
of Child Support. This system was begun in 1987. At that time, which was
pre-windows technology, the only technology available was fax machines.
Fax machines were leased to all 39 counties and by 1997, 100% of all
orders were transmitted directly to the state office using fax machines.
Also in 1997, with the increase in volume of child support payment
processing, imaging technology was installed to expedite the payment
process. Because the Court Order Unit also wanted to utilize the
benefits of imaging technology, a case archive system was built. The
system was built on an infrastructure of imaging technology utilizing a
phased process. For those counties using fax machines, the paper faxes
were forwarded to a fax server. For those clerks who had imaging
systems, they were provided the capability to export directly into the
state system. Fax machines are being replaced with scanners so that
direct imaging will be available to all counties.

#### Technical Description

This alternative requires imaging hardware such as scanners. It also
requires that all parties that are either transmitting or receiving
information agree on the format of the electronic image (such as PDF,
TIFF). In addition, the mechanism used to tag and extract the relevant
data must be agreed upon (like XML). It also requires a connectivity
capability (LAN, WAN) and all security issues must be addressed (such as
firewalls).

## Common Requirements

There are characteristics separate from data, processing, and technology
that are common to each alternative. These items, specified as
alternative feasibility requirements, are provided in Section 3. Each of
these items is required no matter what technology-based alternative a
particular state and court may wish to pursue. These requirements must
be considered, planned for, and resourced prior to development of any
solution.

### Organizational Requirements

A prerequisite for a successful implementation of an information
exchange between CSE agencies and courts is the establishment of an
organizational entity that deals with data standardization. Of the
states interviewed, Colorado has the most mature and comprehensive model
of such an organization. A workgroup, composed of CSE agency and court
staff, standardized all child support forms statewide.

### Operational Requirements

The necessity to plan for the maintenance of software once
implementation is complete is often overlooked during automation
projects. An interface that shares information between agencies and
courts is dynamic. Additions or modifications will inevitably be
required based on Federal, state, and/or court statutory or regulatory
changes related to the Child Support Enforcement program. Ownership of,
and responsibility for, the interface must be identified prior to
implementation. In conjunction with the organizational requirements
dealing with data standardization, court and state IT entities must be
in a position to react swiftly to changing CSE requirements. Agreements
need to be established between IT organizations so delays in the
maintenance or enhancement of the interface are minimized. XML, for
example, provides a relatively easy means for modifications but someone
still has to make the changes.

### Legacy System Modification Requirements

Each state needs to assess current systems and determine what
modifications are necessary to facilitate the data and document
exchange.

## Alternative Evaluations

Each of the three alternatives was evaluated against the requirements
(described in Section 3). The evaluation of the alternative
specification requirements is presented in a narrative manner as well as
summarized for each alternative and requirement. Additionally, a
discussion of each alternative's interstate requirements is provided.

### Alternative Specification Requirements Evaluation 

In the following paragraphs, each of the alternatives is evaluated
within the context of the data, processing, and technical requirements.
Key strengths and weaknesses of each alternative are highlighted.

#### Alternative 1 -- XML-based Interface

#### Data Requirements {#data-requirements-1 .unnumbered}

With the exception of some additional data items derived from interviews
with states, the XML-based solution meets or exceeds the data
requirements. XML is designed to facilitate the flexible mapping of data
employing maintainable cross-references. XML is a technology
specifically designed for exchanging data between systems and
environments independently from the hardware and software architectures
of the source and destinations systems.

#### Processing Requirements {#processing-requirements-1 .unnumbered}

The XML solution has no weaknesses related to the processing
requirements. As part of the court filing standard, it is proposed that
for both sending information to and receiving information from the
court, the CSE system provides both data and actual documents in
electronic form. XML-formatted documents can thus be viewed
electronically and the XML-tagged data can populate the court's and the
CSE system's databases.

#### Technical Requirements {#technical-requirements-1 .unnumbered}

The technical requirements provided in Section 3 are synonymous with a
description of XML. There is not a better solution in terms of meeting
them. XML is specifically designed to be hardware and software
independent. It is specifically designed so that the interface is human
readable and self-describing. It is designed to separate data transfer
from presentation application (i.e. word processor, web format). It can
work as long as there is a communication path between the source and
destination systems.

There does not appear to be any disagreement, from either the previously
cited workgroup or the states interviewed under this project, regarding
the suitability of an XML solution. XML has the underlying capabilities
to best handle exchange of data between child support agencies and
courts. From a technical perspective, XML is the best solution, since it
is a tool set designed specifically for the needs of information
exchange in complex and heterogeneous environments.

#### Alternative 2 -- Traditional System-to-System Interface (Colorado)

#### Data Requirements {#data-requirements-2 .unnumbered}

Since the data requirements presented in Section 3 of this document
encompass the data elements exchanged via Colorado's system-to-system
interface, this alternative is consistent with the requirements.

#### Processing Requirements {#processing-requirements-2 .unnumbered}

The system-to-system interface operates independently of the state and
court systems -- i.e., if the interface fails, the legacy systems are
not negatively impacted. The conversion of data is completed without
user intervention and a record of the exchange is generated.

Approximately 60% of transactions are processed automatically. Some user
intervention is required to correct rejected records and for some data
matching for modifications to existing orders. Paper exchange is not
significantly reduced.

#### Technical Requirements {#technical-requirements-2 .unnumbered}

Each system-to-system interface has to be designed, developed, and
maintained and is not hardware or software independent.

A mechanism of connectivity is in place, as is a security
infrastructure. Also, an exception report is returned to the court
system nightly that indicates rejected records.

#### Alternative 3 -- Imaging (Washington)

#### Data Requirements {#data-requirements-3 .unnumbered}

Only a small subset of the required data elements are captured from the
imaged document and thus, a mechanism for addressing variations in
source and destination field attributes is not available for all the
required data elements. The capability exists to employ cross-references
and to tag confidential data.

#### Processing Requirements {#processing-requirements-3 .unnumbered}

The currently implemented process of imaging court orders satisfies the
requirements related to independent operation, reduction of paper, and
an audit trail and accommodates the documents and forms specified.
Because specific data element exchange has not been accomplished, those
requirements are not met by this alternative at this time.

#### Technical Requirements {#technical-requirements-3 .unnumbered}

Most of the technical requirements have not been addressed, but are
being planned for. Proprietary software has been resolved; connectivity
and a security infrastructure are in place.

### Alternative/Requirement Detailed Evaluation

The table below ranks each alternative against each of the data,
processing, and technical requirements. The ranking is relative. This
means that each alternative is ranked relative to the other alternatives
for each requirement. For each requirement, each alternative is given a
ranking of 1, 2, or 3 with 1 being the highest ranked alternative, 2
being the second highest, and so forth. If two or more alternatives are
deemed to be relatively equivalent in meeting a requirement, they
receive the same score. With this ranking, a lower total score indicates
which alternative best meets the requirements. The alternatives in the
matrix are:

Alt 1 = XML-based interface

Alt 2 = Traditional system-to-system interface (Colorado based)

Alt 3 = Imaging (Washington based)

  ------------------------------------------------------------------------------
  **Requirements**                                       **Alt   **Alt   **Alt
                                                         1**     2**     3**
  ------------------------------------------------------ ------- ------- -------
  **Data:**                                                              

  1\. The exchange/interface must be able to handle data 1       1       2
  that is structured both by case and person. The source                 
  and destination systems are either case oriented or                    
  person oriented, which means that the basic processing                 
  unit is either the case or the persons involved in the                 
  case. The basic data groups are listed in Section                      
  3.2.1.1.                                                               

  2\. The exchange/interface must employ                 1       1       1
  cross-references (i.e. the capability to connect cases                 
  to participants).                                                      

  3\. The source system fields must be mapped to the     1       1       2
  destination system fields with respect to format, data                 
  type, etc.                                                             

  4\. Algorithms must be established to address          1       1       3
  variances in source and destination field attributes                   
  (for example, if the source system captures a 2-line                   
  address field and the destination system captures a                    
  1-line address field, the interface has to recognize                   
  and remember those differences).                                       

  5\. The interface must have the ability to recognize   1       1       1
  and tag data items that are considered confidential.                   

  **Total for Data**                                     5       5       9

  **Processing:**                                                        

  1\. The exchange/interface must operate independently  1       1       1
  of the state and court systems (for example, if the                    
  interface fails, the CSE agency and court systems are                  
  not negatively impacted).                                              

  2\. The generation of the files to be exchanged must   1       1       3
  be completed without user intervention.                                

  3\. Upon completion of an exchange, a record of the    1       1       2
  exchange must be generated (a complete audit of all                    
  transactions must be provided).                                        

  4\. The conversion of data from source to destination  1       2       3
  must be done without user intervention (no manual                      
  loading of data).                                                      

  5\. The exchange/interface must be initiated based on  1       2       1
  triggers in the source system as well as by the                        
  request of state or court staff.                                       

  6\. Paper exchange of data will be reduced.            1       1       1

  7\. The exchange/interface must be able to accommodate 1       1       1
  the data contained in the documents and forms (listed                  
  in Requirement 7) and also structure the data for                      
  exchange and presentation.                                             

  Total for Processing                                   7       9       12

  **Technical:**                                                         

  1\. The exchange/interface must be hardware            1       3       3
  independent.                                                           

  2\. The exchange/interface must be able to handle      1       3       2
  multiple source/destination hardware configurations.                   

  3\. The interface development language must be open    1       3       2
  and interpretive.                                                      

  4\. The exchange/interface must be able to handle      1       3       2
  multiple source/destination operating systems and                      
  database management systems.                                           

  5\. The exchange/interface will flag incomplete        1       1       3
  information if sent from the source system (for                        
  example, data requiring verification, authorization,                   
  and/or approval will not be exchanged unless flagged                   
  as being unverified).                                                  

  6\. The exchange/interface must be self-describing     1       3       1
  (i.e. the structure and content together in each                       
  document).                                                             

  7\. The exchanged document must be human readable      1       2       1
  (i.e. special tools must not be necessary for                          
  processing by computers).                                              

  8\. The exchanged documents must separate data from    1       3       1
  presentation.                                                          

  9\. Any software used in the exchange/interface must   1       1       3
  not be proprietary.                                                    

  10\. A mechanism of connectivity must be in place      1       1       1
  (such as the internet, intranet, network).                             

  11\. A security infrastructure must be in place (such  1       1       1
  as firewalls, controlled access).                                      

  **Total for Technical**                                11      24      20

  **Total for All Requirements**                         23      38      41
  ------------------------------------------------------------------------------

It is not particularly surprising that the XML alternative scored the
best against the requirements. Many of the requirements were derived
from sources that have examined and analyzed information exchange and
had previously determined that XML is the "state-of-the-art" in terms of
information exchange between disparate computer systems.

The other two alternatives essentially scored the same. The traditional
exchange (Colorado based) scored better for data and processing while
the imaging (Washington based) scored better for technical. Both
alternatives 2 and 3 are mature solutions and are successful for their
respective states. Their weaknesses vs. XML are primarily because they
require more hard-coded interfaces and additional hardware or
proprietary software. Both have considered enhancements using XML.

### Interstate

A data and document exchange capability between CSE agencies and courts
could potentially be used to extend the range of information exchange
among states. Any alternative considered must be extensible to meet this
requirement. Each of the alternatives is assessed in the following
paragraphs as to its conduciveness to extending from court-to-state to
state-to-state.

#### Alternative 1 -- XML-based Interface

For XML, the requirement to exchange case, financial, and court order
information between states is not dissimilar to the requirement of
sending the information between CSE agencies and their own courts. From
a technical perspective, the challenge is to exchange information
between different state CSE systems that have different hardware and
software platforms. Since XML is a solution that is independent from the
source and destination hardware and software architectures, it is the
best solution to support interstate exchange. No significant
modifications to either source or destination environments are needed.
However, there does need to be agreement on what is exchanged from a
data content perspective. There is an assumption that most states have
the same set of core data in their CSE systems but it must also be
assumed that precise data formats vary.

#### Alternative 2 -- Traditional System-to-System Interface (Colorado)

A traditional system-to-system interface is uniquely developed to
operate within a particular state and/or court's hardware and software
environment. Because this solution is completely dependent on the source
and destination hardware and software architectures, it is not a viable
solution to support interstate exchange.

#### Alternative 3 -- Imaging (Washington)

Washington has completed its first phase of interstate referral. They
have built a case file correspondence imaging system -- 100% of all case
correspondence mail is centralized and 50% of all case files are imaged.
For interstate cases, 50% of incoming mail is forms that have been
requested from another state. All forms have bar codes that contain
information to index a case. If the statewide system had a forms table,
then automated actions could be performed. The interstate focus would
have to be in the standardization of the forms and barcodes so that
automated case setup could at least be achieved. Once this was
accomplished, then interstate cases could be treated just like
intrastate cases.

# Cost/Benefit Analysis

Developing a typical cost/benefit analysis for the identified
alternatives is not possible due to the many variables within any given
state that must be accounted for. Each state has a unique set of
characteristics (number of users, number of transactions, degree of
legacy modifications, hardware and software required, etc.) that make it
impractical to derive one set of costs for each alternative. However,
some general conclusions related to costs can be derived based on the
different alternatives. Also, it is possible to derive a relative
comparison of costs among the alternatives.

The analysis of the requirements and alternatives is structured in a
manner that makes it possible to derive a standard set of benefits. For
the most part, the benefits are the same for each alternative
conceptually, but providing a tangible measurement to the benefits is
limited by the variations from state to state. For example, determining
a discrete dollar amount for reduction of paper document storage would
be radically different for New York than for Wyoming.

To give states considering the development of a data exchange capability
between their CSE agencies and courts a concept of the costs involved, a
relative cost comparison between the alternatives has been developed.
This should give states, along with knowledge of their specific
environment, some idea of which alternative may be most applicable to
their situation.

## Costs

The cost analysis provides a general assessment of the expenses to a
state to develop an exchange interface. A majority of the effort
involved with any solution is expended on organizational changes,
ongoing operations, and legacy system modifications. These costs are not
reflected in the analysis since they are dependent on the specific state
and its current organizational structure, system environment (CSE agency
and court), and caseloads. Development/ implementation and ongoing costs
are relatively assessed among the three alternatives. It should be noted
that the development of the exchange capability is not a large or
expensive undertaking relative to statewide human services system
development and implementation projects. Just because one of the
alternatives is relatively less expensive than other alternatives, does
not mean a state should not consider them all. The alternatives in the
matrix are:

Alt 1 = XML based interface

Alt 2 = Traditional system-to-system interface (Colorado based)

Alt 3 = Imaging (Washington based)

  -----------------------------------------------------------------------------
  **Cost Category**                                     **Alt   **Alt   **Alt
                                                        1**     2**     3**
  ----------------------------------------------------- ------- ------- -------
  Development/Implementation Costs                                      

  Staff Costs (State/Court Staff, Contractor Staff)     L       H       M

  Hardware                                              L       L       H

  Software                                              L       L       M

  Other EDP Supplies                                    L       L       L

  Miscellaneous                                         L       L       L

  Training                                              L       L       M

  Indirect Costs                                        L       L       L

                                                                        

  Ongoing Costs                                                         

  Operations                                            L       L       L

  Maintenance/Enhancement                               L       H       M
  -----------------------------------------------------------------------------

Relatively speaking, the XML solution is least expensive. The
traditional interface (Colorado based) is most expensive relative to
staff costs for development and maintenance and the imaging solution
(Washington based) is most expensive relative to hardware.

## Benefits

Benefits of developing an automated information exchange between CSE
agencies and courts are provided in the table below. The table contains
the following items:

-   **Benefit** -- a name, title, descriptor of the benefit

-   **Rank** -- a relative ranking of the benefit in terms of the gain,
    savings, increase/decrease, etc. potential to a state/court

-   **Measurement** -- the unit(s) used to measure the gain, savings,
    increase/decrease, etc.

-   **Comments** -- further description of the benefit, rank, or
    measurement

  ---------------------------------------------------------------------------------
  **Benefit**      **Rank**   **Measurement**   **Comments**
  ---------------- ---------- ----------------- -----------------------------------
  Increased        H          \$                Increased collections can be
  Collections                                   achieved via quicker delivery of
                                                child support orders and quicker
                                                child support order establishments
                                                and enforcement actions.

  Positive Impact  H          \$                By improving state collections,
  on Federal                                    Federal performance incentives are
  Performance                                   maximized.
  Incentives                                    

  Paper Reduction  L          \$, Time          Dollar savings in paper, postage,
                                                storage, courier, etc. can be
                                                achieved. Also minimizes staff
                                                burden of archiving records and
                                                destroying archived records
                                                according to state regulations.

  Increased        H          \$                Increased medical support can be
  Medical                                       achieved via quicker delivery of
  Participation                                 support orders and quicker
                                                establishment of medical support,
                                                offsetting the government's
                                                responsibility for medical coverage
                                                for children.

  Reduced Data     M          Time              Due to current budget restrictions
  Entry                                         and hiring freezes, reduced data
                                                entry alleviates workload burden,
                                                could alleviate the need to
                                                backfill positions, and allow staff
                                                more time to concentrate on
                                                casework (and focus on the more
                                                difficult cases). Potential to
                                                alleviate backlog for both CSE
                                                agency and court.

  Maximize         M          Time              Alleviates workload burden and
  Existing                                      allows staff more time to
  Staffing                                      concentrate on casework. Any time
  Resources                                     staff can avoid dealing with paper
                                                is a labor savings. Every keystroke
                                                represents effort. Staff time is
                                                saved in distributing and filing
                                                documents.

  Facilitate       M          Time              Alleviates need for staff
  Access to                                     (caseworkers, court staff, process
  Current Case                                  servers, attorneys, etc.) to call,
  Information (for                              fax, email requests for current
  those who to                                  case information.
  need to know)                                 

  Facilitate       H          \$, Time          Improves data exchange between CSE
  National Data                                 agencies and their own courts. The
  Exchange                                      potential exists to improve data
                                                exchange among states (i.e.
                                                interstate). Alleviates need for
                                                staff to call, fax, email requests
                                                for current case information. Could
                                                also improve collections by
                                                expediting the process.

  Error Reduction  L          Time              Reduce the amount of time staff
                                                (agency and court) has to spend to
                                                correct data entry errors.
  ---------------------------------------------------------------------------------

The above benefits table provides states with indicators that may be
helpful in completing a detailed cost/benefit analysis prior to
developing an exchange interface. Each benefit has the potential to
support the justification of such a project. Information gathered via
interviews with states indicates that resources are extremely
constrained and any IT project beyond mission critical projects would
likely need to be justified and sold based on tangible benefits to the
states and courts.

# Recommendations

Based on the requirements and potential costs, a solution employing XML
does provide the best alternative for information exchange between CSE
agencies and courts. Additionally, due to its flexibility, it also
provides the best approach for extension to interstate data exchange. It
is understood that this approach might not be the most feasible given a
state's current situation and overall technical direction. If a state
already has absorbed the costs of imaging technology, many of the
negatives associated with an imaging solution are mitigated. If a state
has established statewide standardization of technology between its CSE
agency's applications and court applications, many of the negatives
associated with a traditional interface can be mitigated. Colorado and
Washington have successful and working solutions. Each of the
alternatives, given the right circumstances, can provide an adequate
means for exchanging data between the CSE agencies and their courts.
However, for purposes of this study, a solution employing XML is deemed
the preferred alternative.

The sections below highlight actions that states can take now,
regardless of the data and document exchange solution chosen, as well as
recommended next steps for moving toward implementation of an XML
solution.

## Recommended State Activities

Some overarching recommendations are identified that are independent
from the alternatives analyzed. First and foremost is completion of a
specific cost/benefit analysis. General categories that may be
considered for costs and benefits are provided in Section 5 but a
declining economy dictates that a more comprehensive assessment be
prepared to show justification for development. Additional overarching
recommendations are:

-   [Completion of current analysis of the existing state and court
    systems.]{.underline} It is critical that thorough documentation of
    the existing systems be in place prior to determination of an
    approach and initiation of data exchange development.

-   [Establishment of an entity to define standard data]{.underline}. To
    ensure that all involved parties are represented, a workgroup or
    committee should be established to work together to specify and
    define the required data to be exchanged. For example, Colorado
    successfully standardized all CSE forms statewide through the
    efforts of the document generation workgroup, which includes CSE
    agency (including county) and court representatives. To ensure
    appropriate representation, variables to consider when determining
    the composition of such a workgroup include state or county
    administered and court jurisdictions (district, etc.).

-   [Identification of opportunities for creative funding of the
    project]{.underline}. Grants, Federal participation, partnerships
    with universities, and partnerships with vendors should all be
    examined as funding sources.

-   [Establishment of an overall project plan with consideration of
    phased implementation.]{.underline} Each of the alternatives can be
    implemented in phases. Phases can be defined in terms of data
    content or targeted counties or regions or stakeholder groups. An
    iterative approach could be used to implement a small aspect of the
    application, which could then be piloted to acquire feedback for use
    in refining and expanding the application.

-   [Consideration of change management.]{.underline} States should
    consider the impact on business processes, workflow, and system
    users prior to development -- for both the CSE agency and the
    courts. This would include training and support issues.

## Next Steps

It has been determined that a solution employing XML provides the best
alternative for information exchange between CSE agencies and courts.
XML best meets the requirements and provides scalable capabilities.
Scalability is a significant benefit because it can expand beyond a CSE
agency and court data exchange to encompass a broader information
exchange capability, including interstate. Based on this finding, two
major activities are identified as next steps.

### Expand LegalXML DTD

It is recommended that OCSE pursue continuation of the work completed to
date by the child support XML workgroup. An expanded, comprehensive, and
uniform DTD could be used not only for information exchange between CSE
agencies and courts, but also for various other applications. The
recommended approach is to use the XML DTD as a guide, and build a
"palette" based on the data available in this study, data elements from
CSENet, information identified and defined by the Interstate Workgroup,
and more. The data requirements contained in this deliverable may be
revised after the work products completed by the Interstate Workgroup
are finalized.

### Complete Detailed Cost/Benefit Analyses

It is also recommended that detailed cost/benefit analyses be completed
for three states to further validate the XML endorsement reflected in
this study and to help them pursue implementation of a data and document
exchange solution. The following activities are proposed:

-   Develop and document the cost/benefit analysis approach,
    methodology, templates, and tools

-   Establish criteria for selecting candidate states for completion of
    a detailed cost/benefit analysis

-   Create a list of candidate states and gather information on their
    CSE environment (agency and court) and status of current data and
    document exchange capability

-   Select three states for completion of a detailed cost/benefit
    analysis

-   Customize as necessary the cost/benefit analysis approach and
    methodology, templates and tools based on the uniqueness of the
    selected states

-   Complete detailed cost/benefit analyses

-   Based on cost/benefit analysis results, pursue opportunities to
    implement a solution in a state that may include, but not be limited
    to, the following activities:

```{=html}
<!-- -->
```
-   Develop a detailed work plan and organizational strategy

-   Develop technical and functional requirements

-   Develop a prototype and see it through testing and pilot phases

OCSE may also consider pursuing opportunities to provide XML exposure to
states via training courses, conference presentations and workshops, and
materials available on the OCSE website.

[]{#__RefHeading___Toc37493058 .anchor}Appendices

A.  []{#__RefHeading___Toc37493059 .anchor}interview guide

The following survey instrument was used to structure the interviews
with state CSE contacts and court contacts.

[Questions relating to Current Process of Receiving/Sending Information
From/To the Courts]{.underline}

1.  **What** information do you currently receive from/send to the
    courts?

-   Data (e.g. case information, case history, case calendar, actor
    status, associated case list for particular actor, content of court
    policy database, existing docket information)

-   Documents (e.g. court order)

-   Forms (e.g. child support complaint or petition)

2.  **How** **are** you receiving/sending the information now?

-   What is the **method** by which you receive/send the information?
    (e.g. mail, fax, phone, electronic transfer, like email)

-   How **often** do you receive/send information?

-   Are there any **deficiencies, problems, issues or concerns** related
    to receiving/sending information?

3.  **How would you like to** receive/send it?

-   What is the **method** by which you would **like to** receive/send
    the information?

-   What would you **have to do on your side** to receive/send it this
    way?

-   Would you **send anything back** to the courts notifying them that
    data was received?

-   How would this method **improve the Child Support Enforcement
    process**? (e.g. savings in staff time, expediting collections,
    etc.)

[Questions relating to Electronic Interface with the Courts]{.underline}

4.  Do you have any **plans** to exchange data with your courts via an
    electronic interface?

-   **If so**, do you envision having to make modifications to your CSE
    system to accommodate this interface and if so, what would the
    modifications consist of?

5.  What is your **computing environment** with respect to the
    following:

-   What **hardware** does your current CSE system run on?

-   What **software** do you use?

-   What **Operating System** do you use?

-   What **Network** do you have?

-   What type of **Database** (database environment) would be the
    recipient of information from the courts?

6.  Concerning the **users** that would access information from the
    courts:

-   **How many** users would have access to the court supplied
    information

-   Of those, what **percentage have access to the Internet**

-   Of those, **what percentage have access to the E-mail**

-   Of those with E-mail access, what **e-mail application** do you use
    (e.g. LotusNotes, Outlook, etc)

7.  Who would **maintain/operate** the electronic interchange
    environment?

8.  Do you have any **documentation** related to constructing an
    electronic interface with the courts?

-   Project Plans

-   Cost Information

-   Design Documents

-   Implementation Plan

B.  []{#__RefHeading___Toc37493060 .anchor}interview summary

The following table summarizes the analysis performed from the
interviews conducted with the state and court contacts.

+----------+---------------------+------------------------------------+
| *        | **Contact**         | **Summary of Current Exchange      |
| *State** |                     | Process**                          |
+==========+=====================+====================================+
| Ca       | Amy Silva           | -   No current electronic          |
| lifornia |                     |     interchange capability         |
|          | Orange County       |                                    |
|          | Superior Court      | -   Electronic filing in place     |
|          |                     |     before new Child Support laws; |
|          |                     |     intend to begin new effort     |
|          |                     |     when money is available        |
|          |                     |                                    |
|          |                     | -   Use imaging technology to      |
|          |                     |     electronically send documents  |
+----------+---------------------+------------------------------------+
| Colorado | Craig Goellner,     | -   Automated payment processing   |
|          | Systems Director    |                                    |
|          |                     | -   Automated case registry --     |
|          | Division of CSE     |     court orders are transferred   |
|          |                     |     nightly from Court CCMS to CSE |
|          | Bob Roper           |     case registry                  |
|          |                     |                                    |
|          | Court Information   |                                    |
|          | Officer             |                                    |
|          |                     |                                    |
|          | Supreme Court of CO |                                    |
+----------+---------------------+------------------------------------+
| Georgia  | Cindy Moss, Program | -   Court Filing Interoperability  |
|          | Director,           |     Pilot Project provides Georgia |
|          | Information Systems |     courts and attorneys with      |
|          |                     |     proof-of-concept of electronic |
|          | Ronnie Bates        |     court filing and to better     |
|          |                     |     understand the need for, and   |
|          | Georgia Dept. of    |     barriers to, developing court  |
|          | Human Resources,    |     filing systems and standards   |
|          | Office of Child     |     in Georgia.                    |
|          | Support Enforcement |                                    |
|          |                     |                                    |
|          | Todd Vincent,       |                                    |
|          | contractor to the   |                                    |
|          | State of Georgia    |                                    |
+----------+---------------------+------------------------------------+
| L        | Robbie Endris       | -   Electronic Federal Case        |
| ouisiana |                     |     Registry                       |
|          | Program Director -- |                                    |
|          | Field Operations\   | -   No electronic exchange in      |
|          | Support Enforcement |     Child Support                  |
|          | Services            |                                    |
|          |                     | -   Using scanning technology      |
+----------+---------------------+------------------------------------+
| Missouri | Alyson Campbell     | -   Courts enter orders into       |
|          |                     |     statewide CSE system, MACSS    |
|          | Deputy Director,    |                                    |
|          | DCSE/ISTU           | -   Courts have their own judicial |
|          |                     |     information system and         |
|          |                     |     maintain distinct court        |
|          |                     |     information; there is no       |
|          |                     |     duplication between the two    |
|          |                     |     systems.                       |
+----------+---------------------+------------------------------------+
| New      | Joanne Browne,      | -   Disbanded electronic filing    |
| Mexico   | Helen Nelson, Tom   |     workgroup                      |
|          | Barr (Chief         |                                    |
|          | Counsel)            | -   E-filing pilot in one court;   |
|          |                     |     project ended due to lack of   |
|          | Child Support       |     funding                        |
|          | Agency              |                                    |
|          |                     |                                    |
|          | Renee Cascio        |                                    |
|          |                     |                                    |
|          | New Mexico Courts   |                                    |
+----------+---------------------+------------------------------------+
| Penn     | Dan Richard, IV-D   | -   Unique organizational          |
| sylvania | Director            |     structure -- the local IV-D    |
|          |                     |     agency (Domestic Relations) is |
|          | Joyce Match (for    |     the court in Pennsylvania      |
|          | Jeff Rowe,          |                                    |
|          | Application Manager | -   All CSE related activities are |
|          | for PACSES)         |     in one place                   |
|          |                     |                                    |
|          |                     | -   Forms are standardized         |
|          |                     |     statewide                      |
+----------+---------------------+------------------------------------+
| Texas    | Jacqueline Nguyen   | -   4 largest counties send        |
|          | and Karen Clements  |     dataset electronically to      |
|          |                     |     courts which is used to create |
|          | Texas Office of the |     a record to establish a file   |
|          | Attorney General    |     date and docket number;        |
|          |                     |     nothing returned from court    |
|          |                     |                                    |
|          |                     | -   Benefit: get file dates faster |
|          |                     |                                    |
|          |                     | -   Still rely on paper documents  |
+----------+---------------------+------------------------------------+
| Wa       | Steve Spitzer       | -   Imaging system to              |
| shington |                     |     electronically transmit court  |
|          | System Manager      |     orders (currently only 29% of  |
|          |                     |     court orders are paper)        |
|          | DCS SEMS -- Imaging |                                    |
|          | Project             | -   Using XML                      |
|          |                     |                                    |
|          | Gary Masten, County | -   Have centralized 100% of case  |
|          | Clerk               |     correspondence                 |
+----------+---------------------+------------------------------------+
| W        | Dave White          | -   No electronic exchange         |
| isconsin |                     |     capability; not needed since   |
|          | Child Support       |     CSE agency is co-located with  |
|          | Specialist (CSE     |     the court                      |
|          | Call Center),       |                                    |
|          | Bureau of Partner   | -   Office of the State Courts     |
|          | Services, Dept. of  |     recently completed a two-year  |
|          | Workforce           |     e-filing study                 |
|          | Development         |                                    |
|          |                     | -   Court staff have access to     |
|          | Dan Floeter, Family |     statewide child support        |
|          | Court Commissioner; |     system, KIDS                   |
|          | Kerry Widish,       |                                    |
|          |                     | -   CSE agency has access to court |
|          | Court Manager;      |     imaged database, which         |
|          | Donna Wills, Net    |     contains family and paternity  |
|          | Administrator; Gail |     court documents                |
|          | Richardson, Madison |                                    |
|          | County Court        |                                    |
|          | Administrator       |                                    |
+----------+---------------------+------------------------------------+

C.  []{#__RefHeading___Toc37493061 .anchor}Interview Notes

The following notes document the interviews conducted with the state and
court contacts.

**Notes on Discussion with Amy Silva, Orange County Superior Court**

#### State of California, Orange County {#state-of-california-orange-county .unnumbered}

**Date: 12/9/2002**

No current e-filing project, had one from 1995-1998. Local CSE agency
was filing cases electronically. Data consisted of case name and number,
party name and case number was automatically dispensed. Did not have
imaging then; document was sent next day, so still had paper. A case
tracking system already contained the data. When document came in, all
that had to be done was stamp it; eliminated data entry. In 1997,
changed methodology of CS judgment; 1058 was law that created child
support program; stopped e-filing because it would take a lot of effort
to make changes to the system. Since that time, there have been
additional changes in how CS cases are handled; new forms, new laws. For
questions on methodology of how it was done, should contact the IT
systems people.

In the future, would like to begin e-filing with CS agency; going to
talk to other courts and see if they want to do e-filing also. CA's CSE
system vendor was Lockheed-Martin and after many years, never got the
system done. Some of the smaller counties were using Lockheed-Martin
system, but the system was never implemented statewide. Then every
county was told to pick a system to be on -- there will be 3 or 4
versions of software. Orange County chose to use the LA and San Diego
system (40% of population in these counties). The counties meet as a
consortium to decide changes. LA (ARS) system is being used. If wanted
to do e-filing, would have to discuss with other 2 counties; so, it will
take a long time to accomplish.

E-filing project is on hold; need to initialize the discussion; not
ready for quite a while; Orange County converted to ARS 5 months ago and
they want to do e-filing.

Are using imaging now (for 2 years); want image to get burned
automatically, so don't have to scan documents; then data entry has to
associate image with specific document; so have to connect Case
Management system and imaging system. Initial pleading is sent
electronically, (not sent as paper) and then it is scanned for placement
in the imaging database. Register of actions uses imaging to do all
their work; every file or document is imaged now. More than 1 person can
view them this way. If CSE could access imaging database, then the
process would be more efficient. CSE sends in requests for judgments,
various documents; 2 groups would have to work together to access images
(have to deal with firewalls, etc). CSE does have access to case
tracking system (BANNER), brought it up in 1995.

Criminal uses another product.

Everyone has separate databases, even those who use BANNER (juvenile,
family law); OC files 25,000 cases (new family law, includes CS). CS is
about 1000/month; order to show cause is one of most often filed --
about 1300 a month. 18 courtrooms for family law (3 for CS law).

However ARS generates pleadings or documents, it could electronically be
sent to courts. CA is forms driven (all forms are standardized); so when
do initial data entry of minor child, DOB, salary, etc. and a complaint
gets generated, it would be more efficient if an automated process could
send data to courts. Court would have to tag it so could be uploaded to
case tracking system; so would like for them to talk in that sense. A
lot of discussion now on how to access database; do not want CSE to come
directly into system; would give inquiry rights. Court needs case name,
type of case (paternity, parentage), who filed; so on pleading would
like to tag those fields only. Would have to work out how it is
uploaded; court really tracks documents; would not want most of data
that CS creates.

Between 1995-1997, court would give case number automatically and that
got attached to pleading; beginning of e-filing.

Contact: Mary Lou DesRochers, Exec. Director for Orange County superior
courts; she is involved in e-filing project divorces (other family law,
not CS), might know other family law courts who are doing some e-filing;
714-834-6045. Admin Office of Courts, Technology Unit might know of
technology project; Diana Krishna, 415-865-7463. Orange County System
people; Nancy Hawkins (Manager); 714-935-6262 or Kim, 935-6782
(Supervisor, reports to Nancy); Both have info about e-filing.

Issues with e-filing in 95:

-   Need to make sure only one case gets filed and same case doesn't get
    filed 3 times

-   Data entry people at DA office would hit enter key more than once,
    so same case got multiple case numbers

ARS system -- gave CCS block of case numbers so the system generates
case number and they generate report that also goes to court; it was a
way to track and ensure accountability of what was being sent over.

Both sides need reporting mechanism to make sure nothing is getting lost
(like logging system on both sides).

In 1995, if had defendant in office and wanted to prepare case and serve
him, could do it in real-time while person was in office (transmitted to
courts in real-time and got back a case number while the defendant was
in office).

When make changes to both systems, in 1995, each side paid their own
way; CSE are better staffed than courts now (courts has \$20M shortfall
now, bad economy).

Electronic interface is high on priority list, if not part of ARS, would
be pursuing it now.

Bad economy could stop it; can't replace anyone that leaves; can't hire,
so that could stop it; so realistically, can't tackle right away, but
are many advantages.

**Notes on Interview with Craig Goellner, State of Colorado**

**Date: 11/4/2002**

Question 1. Colorado has an automated interface with their courts. They
have a limited state case registry and they establish accounts for
payments through their SDU. When a case is established, the court sends
a transaction to set up an account (if new order) or modification(s) to
an existing order. When the court sends a transaction for a new order, a
new case is automatically generated in the central registry. For a new
case, there is no user intervention; interface is crude. There are
instances where they are trying to match data from the courts with IV-D
caseloads, which sometimes requires human intervention, but ½ to 2/3 of
transactions are processed automatically. The number of data elements
are 40-50. (**Craig said he would send us the data elements**).

When asked if anything is sent back, he answered that an acknowledgement
and rejection (error) loop does exist, but they don't send
[data]{.underline} back. Courts are told that something is received,
etc. Some of the data is control data.

Question: Is court interested in IV-D case registry? Non IV-D is what
the court gives them; very limited. There is a non-disclosure indicator
that can be set on IV-D side. The court is rewriting their system to
incorporate a graphical user interface. They are also looking at XML.
The IV-D side recognizes that there would be value if the filings could
be done electronically. Other than that there is no interest.

Colorado is county-administered (it is the local district court that is
working with the local CSE). In the IV-D world, paper drives the
establishment or modification of an order, so paper comes back as well
as an electronic copy (paper comes first). In the non IV-D side, only
get an electronic order because the parties are pursuing the order
themselves, so open an FSR account (just to populate the state case
registry).

CSE has a document generation facility, so all forms are standardized.
Throughout the state, everyone is using the same documents (there are
hundreds of documents). IV-D world has standardized on documents
exchanged with courts. When the document generation was created, a
committee was formed (representing all parties) to approve all changes
to IV-D legal documents. Once approved, they were programmed into the
document generation facility. This lends itself to XML (potential is
high).

Jackie Barnett has done technical work on the interface; now one large
generic transaction. It is like a higher level of integration, but there
is not material to interchange. They are getting what they need. Can be
compared to e-filing.

Question: What are some indicators that would let you embrace XML?

-   Doesn't have time to figure out how to marry XML with CSE system

-   Have to deal with confidentiality (encryption or secure transport
    mechanism)

-   Would be interesting to see what GA has done

-   Same formats at DTD; again more technical tasks

-   What is the application that would give you the most bang for the
    buck, like e-filing or wage withholding. DFAD is using flat
    technology; XML could help.

-   Court needs to answer how XML could help within their infrastructure

-   Colorado Courts -- statewide point of receipt (i.e. portal)

-   Court filing standard allows an electronic document to be used in an
    envelope, so one step would be to transmit PDF electronically just
    using browser technologies

Question: What is carrot for the courts for using electronic transfer?

-   Anytime you are not dealing with paper is a labor savings. If you
    had a repository, could provide web-access to those with a need to
    know (distributing documents, filing documents, etc)

-   Every keystroke is a major effort to them, so if could file
    electronically, that would be another benefit.

Question: What other states are you aware of that might have an
electronic interface with the courts?

-   NM (check XML work group)

-   TX (has done some limited electronic filing)

-   OR -- maybe, not sure

-   GA

Craig asked if there were any groups working together to standardize
forms to be exchanged because you need to have a human infrastructure in
place before applying technology.

Craig to email contact information for Jackie Barnett.

**Notes on Interview with Bob Roper, Court Information Officer**

**State of Colorado**

**Date: 12/9/2002**

Question 1:

Support Orders

-   Court Case Management System is court managed and was built in-house
    about 2-3 years ago **(Bob will confirm)**

-   Whatever orders courts issue are transferred nightly from CCMS to
    CSE registry

-   There are mandatory fields that must be completed and are some
    non-mandatory fields that are also flagged when transfer is made
    because they also want that information

-   Get back exceptions nightly, which are error messages on rejected
    records or missing information (based on flags set for
    required/wanted data); corrections are made next day

-   Court orders are standardized

-   Court order system -- data elements are the same

-   Don't have to follow-up with hard copies

Question 2:

Deficiencies/Issues

-   Court has none; everything is working smoothly

-   **Percentage of errors returned, Bob will get those numbers**

Question 5:

-   Hardware is IBM AS 400/730

-   SW is Court Case Management System (ICON, Integrated Court On-line
    Network)

-   Clerks key in information and it is transferred by FTP to CSE system

-   OS is OS400

-   Private TCPIP frame relay network

-   Database is DB400 (same as DB2)

-   **\# of data elements (Bob will get that for us)**

```{=html}
<!-- -->
```
-   He will break it down by mandatory and non-mandatory

```{=html}
<!-- -->
```
-   Interface maintained on court side

-   **Documentation**

```{=html}
<!-- -->
```
-   Bob will check on what they have and will get back to us

XML

-   XML is technology of choice; wanted to use it initially, but was not
    available when they built their system

-   They were following the Terrie Bousquin (former New Mexico CIO)
    effort (XML standard group? Legal XML workgroup?)

-   Would love to be a pilot for our effort once standards are finalized

-   Benefits that they don't already have

```{=html}
<!-- -->
```
-   Real time updates

-   Facilitate national data exchange -- ease with which Colorado could
    exchange information with other jurisdictions if there was a
    standard for tagging fields

-   Effort to convert

    -   Have to train staff

    -   3-6 months with 1 FTE

    -   Craig would also need project help

They also have a Statewide Criminal Justice Information system (CJIS);
they are talking about converting it to XML in-house.

**Notes on Interview with Cindy Moss, Program Director, Information
Systems, GA Office of CSE and Ronnie Bates, State of Georgia**

**Date: 11/20/2002**

Comments on Georgia Courts Automation Commission\'s Interoperability
Pilot Project implemented by Georgia State University:

-   Website: <http://e-ct-file.gsu.edu/>

-   Douglas County typically files 4 cases per week which are sent FTP
    to remote server (Word Perfect format)

-   Court file is stamped (XML/PDF format) -- using LegalXML
    recommendations on fields

-   Document can be viewed via a web browser

-   Access is through a website

-   Updates are made to clerks database

-   Manual updates are required to CSE system

-   All legal documents filed with the court -- petitions, initial
    pleadings for support or contempt

Benefits:

-   No trips to courthouse

-   Reduced copies

-   Process server is notified electronically

-   Service information is electronically sent to courts and electronic
    notification is sent to CSE

-   Only one website -- just different links

How is system being paid for?

-   Currently Douglas County is only county that is operational

-   No one wants to pay for it

-   Was implemented by e-filing.com

-   Future is based on funding

-   Another circuit court is interested but they have a different
    operating system

-   Until it implements all of electronic filing, they are hesitant to
    put it out

-   Requested a SIP grant; if they get the grant then they can make some
    of the modifications

-   \$5 of what is paid to process server would be given to e-filing.com

-   GA doesn't pay a clerk fee, so can't use that avenue

-   Funding issue is BIG; there are no extra dollars

-   There is no marketing information; currently word-of-mouth

Example of savings:

-   Benefits document -- Pleading \--\> signature approval \--\> filing
    \--\> process server; this used to take 22 days; with electronic
    filing it is now a maximum of 5 days in pilot county

-   Petition/Pleading to establish support/legal documents --
    deficiency: manually input into the Case Management System

Other Benefits

-   Douglas County wants to be able to share data electronically

-   Could eliminate document creation; just go directly to the server

-   Document format is not an issue; each county could require a
    different format as long as the fields are the same

-   Can fax a document too and it can be FTPed and put into a database,
    so it will eliminate data entry

-   Interstate forms could be sent using XML

Currently working on Comprehensive Plan: Electronic submission using
XML. Estimated completion date is December 20, 2002.

Why is XML the way to go?

-   Ability to cross platforms and update databases

-   Simplicity (not like Cobol)

-   Ability to take a fax and convert it

-   Easily tagged to make modifications

Other systems that we should check into: Riverside County website

**[SURVEY (completed survey received from Georgia):]{.underline}**

[Questions relating to Current Process of Receiving/Sending Information
From/To the Courts]{.underline}

1.  **What** information do you currently receive from/send to the
    courts?

-   Data (e.g. case information, case history, case calendar, actor
    status, associated case list for particular actor, content of court
    policy database, existing docket information)

> Court Calendar

-   Documents (e.g. court order)

> Orders for Support
>
> Contempt Orders
>
> Default Orders

-   Forms (e.g. child support complaint or petition)

> Petitions to Establish Paternity & Support
>
> Petitions to Contempt
>
> Rule Nisi
>
> UIFSA Petitions
>
> Depositions
>
> Continuances
>
> Service Process

2.  **How** **are** you receiving/sending the information now?

-   What is the **method** by which you receive/send the information?
    (e.g. mail, fax, phone, electronic transfer, like email)

> Mail
>
> In Person
>
> Electronic ( E-filing)
>
> Fax
>
> Phone

-   How **often** do you receive/send information?

> Daily

-   Are there any **deficiencies, problems, issues or concerns** related
    to receiving/sending information?

> Mail/In Person -- timeframe and man hours. Currently we must take the
> documents to the courthouse have the Judge sign, return to the office
> make 3 copies, return to the court for filing, go back to the office,
> return to the court house to pick up the documents, return to the
> office, call the process server to pick up documents for service, wait
> for service, process server returns service papers to office, make
> copies, return to court house to file service papers.

3.  **How would you like to** receive/send it?

-   What is the **method** by which you would **like to** receive/send
    the information?

> Electronic Filing. Generate electronic documents, Attorney approved,
> document goes to Judge electronically, he signs, then it is submitted
> to the Clerk, she files electronically, auto notice sent to OCSE that
> document filed and ready for pick up at the same time the process
> server receives notice. He serves the documents and then
> electronically submits service papers back, clerk electronically files
> and notifies OCSE. OCSE computer system auto accepts data and updates
> the database. Notices auto go out to CP/NCP. Constituent self-service.

-   What would you **have to do on your side** to receive/send it this
    way?

> Technical upgrades and programming

-   Would you **send anything back** to the courts notifying them that
    data was received?

No

-   How would this method **improve the Child Support Enforcement
    process**? (e.g. savings in staff time, expediting collections,
    etc.)

> Save man hours, which could be used to take actions to collect
> support. Decrease the time to obtain orders and court dates.
>
> Improved Customer Service.

[Questions relating to Electronic Interface with the Courts]{.underline}

4.  Do you have any **plans** to exchange data with your courts via an
    electronic interface?

> Yes, pilot currently underway.

-   **If so**, do you envision having to make modifications to your CSE
    system to accommodate this interface and if so, what would the
    modifications consist of?

> Yes, need to be able to accept data from the court system.

5.  What is your **computing environment** with respect to the
    following:

-   What **hardware** does your current CSE system run on?

> Mainframe, CICS

-   What **software** do you use?

> \$TARS application, WordPerfect

-   What **Operating System** do you use?

> Windows 95/98

-   What **Network** do you have?

> LAN is Novell

-   What type of **Database** (database environment) would be the
    recipient of information from the courts?

> DB2

6.  Concerning the **users** that would access information from the
    courts:

-   **How many** users would have access to the court supplied
    information

1400

-   Of those, what percentage have access to the Internet

100

-   Of those, what percentage have access to the E-mail

100

-   Of those with E-mail access, what **e-mail application** do you use
    (e.g. LotusNotes, Outlook, etc)

Groupwise

7.  Who would **maintain/operate** the electronic interchange
    environment? Vendor

8.  Do you have any **documentation** related to constructing an
    electronic interface with the courts? Yes

-   Project Plans

-   Cost Information

-   Design Documents

-   Implementation Plan

**Notes on Discussion with Todd Vincent -- developer for Georgia Courts
Automation Commission\'s Interoperability Pilot Project**

**State of Georgia**

**Date: 2/28/2003**

Georgia Courts Automation Commission\'s Interoperability Pilot Project
Discussion

-   There are 5-7 applications with different interfaces that all have
    to talk to each other.

-   Georgia had a back-end mainframe and document generation system that
    merged into WordPerfect. They now use WORD and their own document
    generation system; they take data and documents and send through
    court filing process (based on Legal XML -- using DTD). Generic way
    to pass filing info; once it gets to court, goes through 2
    applications and then goes through adapter that takes data and puts
    it into the case management system; they are moving to another
    system.

-   Project funding: vendor gives work and software free. They made an
    arrangement with sheriff for service of process; vendor gets piece
    of money paid to sheriff. Want to roll out to other places of state;
    dependent on volume also. Todd is funded by courts; vendor is not
    paid for. Todd is a contractor for the state (through the
    University); he is also a contractor for the university; project
    answers to GA courts automation commission.

-   CA has a 2^nd^ generation court filing process; Georgia will be
    moving to this type of process; there is a link on their website
    describing this process.

-   Issue is not technology, but the funding; submitted a SIP grant
    request; did not get a grant; theirs is not a good business model
    for vendors to get involved in; courts and DHR can't come up with
    adequate funding; they plan to repackage the SIP grant request into
    smaller amount.

-   They want to get involved with an actual implementation; have one of
    the most advanced implementation systems in the country; information
    flows in circle -- DHR-court-DHR. Wanted the grant to close the loop
    back into the DHR system; need \$200K over extended period of time.
    Big issue is training and support; not a lot of data that gets
    passed over; have to facilitate communication among all parties.
    Data issue -- 7 systems all with different data.

-   Information necessary for filing (Legal XML). Court doesn't care
    about data is document (DHR has that in their systems); court only
    cares about filing information.

-   CSE process: File a complaint and 4 other documents which initiates
    case; hearing set; and that date is set and communicated manually;
    subsequent filings; case sits for 2 years maybe and other documents
    are filed; existing case \# will come over with document and other
    documents will be associated that way. Prioritize easiest exchanges
    and do those first; small steps. What they are doing is most
    advanced; only funding issue; Ronnie Bates could give more detail
    and another perspective.

**Notes on Discussion with Robbie Endris, Program Director - Field
Operations\
Support Enforcement Services**

**State of Louisiana**

**Date: 12/12/2002**

-   Louisiana is only doing Federal Case Registry electronically

-   Not doing any electronic exchange in Child Support

-   Have bought scanner/printers

-   They do have an XML workgroup

-   Their IT workgroup is in social services, under division of
    administration.

-   There is now one parent agency for IT for the state. CSE has as one
    of its higher priorities to get moved there. They have a good CSE
    system.

-   Contact in IT group is: Mark Hodges, 225-922-2075

One of their technology goals is to get technology to the caseworkers in
the field (by means of laptops) so that they can input their data as
they collect it and it will then get uploaded into the CSE system; also
want to be able to take laptop into court room and do input in
courtroom.

Issue in Louisiana:

-   They have expedited their child support process by means of hearing
    officers who can hear the case and make an initial assessment (they
    have a lot of hearing officers); this doesn't take up district court
    time; cases move quicker through. Hearing officer decision may be
    appealed to an elected judge within 72 hours; if not appealed, then
    judge has to put signature on it; can cause problem; always 72 hour
    delay; can wait a month to get paper order.

```{=html}
<!-- -->
```
-   How do they deal with this potential delay -- for most of the
    jurisdictions, when CS attorney leaves court, he has a copy of the
    recommendation in hand; can act on recommendation (usually wait 3
    days to see if recommendation will be appealed)

Louisiana is state-based; judicial, not administrative; license
suspension is only administrative process in the state.

**Notes on Discussion with Alyson Campbell, Deputy Director DCSE/ISTU**

**State of Missouri**

**Date: 2/26/2003**

Information exchange process between CSE agency and the court:

-   MACSS (Missouri Automated Child Support System) -- courts enter
    orders into MACSS (both IV-D and non-IV-D cases); can see the order
    in the system; have been doing this since 1998; court clerks access
    MACSS with PCs with 3270 emulation.

-   Child support staff can see court order information in MACSS and
    payment information if circuit clerk receives the payment; now most
    payments have been redirected to SDU; for those few cases that the
    court receives and receipts payment -- it is done in MACSS. Child
    support staff don't see docket sheet, petitions.

-   Courts have their own judicial information system and they maintain
    court records there as well; information is different in the two
    system; no duplication.

The Office of the State Court Administrator governs the courts. They
have developed a new web-based program called CASENET. CASENET is open
to the public; it provides information like docket entries for cases.
When all CSE staff have Internet access, they would be interested in the
CASENET system. It is new and its utility to CSE staff has not been
evaluated; an example of its use would be for criminal non-support cases
-- cases could be tracked without having to call the district attorney's
office for information.

Opportunity for increased efficiency via electronic transfer:

-   Some enforcement actions require certified copies of court order --
    primarily interstate cases that require an interstate referral
    asking for enforcement on Missouri's behalf (small number of cases);
    have to ask for certified copy manually; can't get it electronically
    (needs seal). Long delay in bigger courts (Jackson county can be
    months); smaller courts would have within 2 weeks; St. Louis City
    also big court and there is delay there too. Federal law or state
    statute requires certified copies of court orders; Missouri is an
    administrative state and they don't require certified copy of court
    order for intrastate cases.

-   Otherwise they have what they need in MACSS; from the time MACSS was
    brought up in 1988, non-IV-D cases were included, so don't have to
    go back to the court to ask for more information.

Missouri has not adopted electronic signature.

Missouri is just now becoming technology-enabled; in the last fiscal
year CSE staff were given PCs, prior to that they had green screens;
proposals are on the table for imaging and web communication; budget is
an issue.

**Notes on Interview with Joanne Browne, Helen Nelson, Tom Barr (Chief
Counsel), State of New Mexico**

**Date: 12/3/2002**

New Mexico had a working group some time ago (since disbanded) to define
the requirements for electronic filing; composed of CSE agency and court
staff; meetings were sporadic; not much headway and no products were
generated. There was a design document created and **Joanne will send
that to us**. The workgroup looked at XML; not aware of any other
technologies considered.

All legal forms are accessible on-line and are data scrapped into a
database. **Joanne will give us the data elements captured.** The forms
are part of a packet. The Navajo Nation has access to the forms, but
don't use all of them.

Survey Instrument:

-   NM does not file anything electronically with the courts; they can
    access certain information, but are not filing anything
    electronically at this time;

-   Electronic signature is legal in NM, but are not using it

-   Court clerks do not have access to CSE system

-   CSE agency can view court system

-   Courts have their own system and assign their own case ID number.
    Case information, case history, etc. is also kept on the court
    system.

-   Document interchange is through the mail or delivered to the
    courthouse in person

-   They might be able to pull up a calendar

-   All documents are hard copy

-   Information is exchanged daily in the larger cities

-   There is not a CSE office in every county seat

-   Problems related to receiving/sending information:

```{=html}
<!-- -->
```
-   It takes several weeks in Albuquerque to process documents; shorter
    times in other parts of state. Enforcement petitions are processed
    first.

-   Albuquerque is flooded with petitions

-   Courts are under funded and have been so for last 8 years

```{=html}
<!-- -->
```
-   Enforcement action is filed the day it is received

-   When information is received from the court, it must be entered
    manually into CSE system; time consuming

-   Only acknowledgement from court of information sent is a date stamp

-   What would like to receive electronically

```{=html}
<!-- -->
```
-   All filings

-   Like to file electronically and get endorsed copies back
    electronically

```{=html}
<!-- -->
```
-   Their working group did look into XML; need to review design
    document to see what was done

-   No plans to resurrect the workgroup (it was composed of agency and
    court staff)

-   Electronic interface would be major impact to the courts and
    modifications would be fairly minimal

-   Only technology solution discussed by the workgroup was XML

-   Benefits to electronic interface

```{=html}
<!-- -->
```
-   Money savings (postage and time spent going back and forth to
    courthouse)

-   More expeditious

-   Slow downs and bottlenecks affect everything

-   Easier to track at both ends

-   Would expedite collections

-   Positive impact on Federal performance incentives

Privacy has already been addressed (most filings are public record).

**Notes on Interview with Renee Cascio**

**New Mexico Courts**

**Date: 1/24/2003**

Current exchange capability with the CSE agency:

-   Electronically send data file, place on FTP site and child support
    agency pulls it down. Occurs at least monthly. Information sent
    includes case number, date of order issuance, party demographic data
    (such as names, dates of birth, SSNs), address, relationship, when
    child support ordered, amount, and a flag for domestic violence (as
    specified from the parties). Follow with certified copies of orders.
    Nothing received electronically from the CSE agency.

-   Statewide case management system -- in every district court in the
    state.

-   Don't image court documents at all.

-   Individuals have to submit pleadings through the court for a case to
    be opened. Child support agency doesn't open cases to her knowledge
    -- goes through court. Don't receive anything from the agency.

-   Had e-filing pilot project in one court in the state; had to end
    because legislature wouldn't fund it. Not dealing with any
    electronic exchange currently. Electronic signature was a
    significant issue. **Will talk to IT people about availability of
    data elements identified for the pilot and send to us if possible.**

-   The courts only hear and consider what's presented to them --
    anything other than that is a violation of judicial ethics.

-   Interstate data exchange -- no exchange with other states. Believe
    that the information they send to the CSE agency is forwarded to the
    Federal Registry, but there is no follow-up to confirm this.

Still track the latest with LegalXML.

**Notes on Interview with Dan Richard (IV-D Director) and Joyce Match
(for Jeff Rowe, Application Manager for PACSES)**

**Commonwealth of Pennsylvania**

**Date: 2/12/2003**

-   Local IV-D agency is the court in Pennsylvania -- Court of Common
    Pleas and a Domestic Relations Section (IV-D agency) in every
    county; unique relationship. Pennsylvania is a judicial process
    state. Domestic Relations is a highly administrative branch of the
    local court system. Docketing activities are completed by Domestic
    Relations themselves.

-   All CSE related activities are in one place. Child support functions
    completed in the statewide child support system, PACSES.

-   If a complaint is filed for child support, a conference takes place
    during which an interim order is generated. If not appealed within
    15 days, becomes final; then a paper copy is issued that the judge
    will stamp; or it is pre-printed from the court order.

-   PACSES has 354 forms within the system, including orders for
    support, license suspension, liens on assets, income attachments.
    Forms are standardized statewide.

-   There is no waiting for an order; IV-D agency is creating the order;
    some have rubber stamp; some send to the judge for review and
    signature; local offices have different requirements. Don't have to
    wait for piece of paper to post payment or respond to customer
    concern.

-   Similar organizational structure in Michigan -- "Friend of the
    Court", which performs a similar function as Domestic Relations in
    Pennsylvania. Not sure if they can establish a temporary order.
    Friend of the Court is an administrative agency that takes care of
    enforcement and related actions; they don't hold support hearings or
    establish the order.

-   Pennsylvania's organizational structure -- advantages include a
    streamlined process, no extra judicial process for contempt, don't
    have to refer cases to a court because the court has spoken. Really
    no disadvantages, other than issues that arise when two separate
    branches of government interact -- separation of power issues, can't
    regulate the courts, neither side can dictate to the other.
    Cooperative agreements are with the judicial branch -- have to be
    aware of political differences and issues. Most counties are of
    sufficient size to have family court judges who are familiar with
    the program, so they are not going to another body where they have
    to start from scratch if there are larger issues. Support guidelines
    are issued by Supreme Court rule, so can't be declared
    unconstitutional; therefore, can circumvent a lot of jurisdictional
    issues.

-   PACSES was fully certified in December 2001 (including PRWORA).

-   Technical environment: Unisys Clearpath mainframe with servers in
    counties where forms and screens (GUI interface) are downloaded.
    Store form templates and latest versions of screens at the county
    level. Each county worker has a PC; they are upgrading to IBM
    state-of-the-art flat screen PCs. Also have PACSES homepage, data
    warehouse, portal, and intranet.

-   Applications: COBOL, support layer is proprietary to the state as a
    bridge between COBOL programs and screens so it is easier to write
    the programs.

-   Database: DMS, RDMS (converting slowly).

-   Want to share information with other courts, like child support with
    criminal, domestic violence, custody; there is also some
    conversation of communicating with other agencies.

-   Child welfare is an administrative agency in Pennsylvania, not part
    of the court. To place a child, they have to go to court and file a
    petition and start there.

-   Interstate: Pennsylvania is fully CSENet compliant and communicates
    that way. Interstate cases are handled at the county level, not
    centralized. Philadelphia County has the largest caseload (140,000
    active cases).

**Notes on Interview with Jacqueline Nguyen and Karen Clements**

**State of Texas**

**Date: 12/5/2002**

State-based, judicial state with a quasi-administrative method as well

254 counties in Texas

Current Data Exchange Process:

-   When a pleading is produced, CSE creates a dataset and sends it to
    court and it is used to create a record in their system

-   Court establishes a file date and docket number and their permanent
    record of pleading

-   Replaces their data entry process; eliminates data entry errors;
    still have to follow up with paper (petitions or pleadings)

-   Only used in 4 largest counties -- looking to expand; this covers
    most of cases (60-70% of cases); all have different systems
    capability; have to assist with some programming as well; other
    counties still file manually.

Plans:

-   Group in formation; e-filing work group

-   It has not met yet

-   They want to look into ways of electronic filing

-   They are just at point of sending people to training to understand
    more about the technology

-   No charter at this point

-   Agency staff only at first, eventually bringing in other groups

Do get anything back when send dataset:

-   No, are working on cog number and file date that will automatically
    update CSE system; not in place now; now get it back manually and
    have to put it in CSE system;

-   It is helping courts

Benefits:

-   Expedites process; helps get file dates in couple of days; no help
    in data entry though;

-   Reduces court backlog which helps the agency process cases

Question 8:

-   Have some documentation, but may not be same as will have for
    electronic interface with courts;

-   Timeframe for implementing true interface -- one of first topics for
    workgroup; workgroup will be agency first, then involve other
    entities they would interact with.

Will have 100 new district clerks because of election; also new attorney
general.

Benefit of electronic interface:

-   Savings, staff time;

-   Eliminate errors;

-   Expedite process of establishing CS order, which would lead to
    expediting collection.

Other Comments:

-   No resistance on court side

-   CSE makes changes and sometimes buys equipment for the courts

-   They pay for hardware and programming effort for courts

-   Resources are only problem; in 4 counties CSE provides programmers

-   4 largest counties have most of caseload

-   Just starting working group/committee to look at electronic filing

-   Get filing date electronically

-   Still get paper

Texas is interested in the results of the feasibility study, especially
the alternatives analysis and CBA.

\*Send the NCSC link

**[SURVEY (completed survey received from Texas)]{.underline}**

[Questions relating to Current Process of Receiving/Sending Information
From/To the Courts]{.underline}

1.  **What** information do you currently receive from/send to the
    courts?

-   Data (e.g. case information, case history, case calendar, actor
    status, associated case list for particular actor, content of court
    policy database, existing docket information)

  -------------------------------------- --------------------------------
  ***SEND TO COURTS***                   ***RECEIVE FROM COURTS***

  *Case Information*                     *Filing Date*

  *Parties Information*                  *Hearing Date*

                                         *Cause Number*

                                         
  -------------------------------------- --------------------------------

-   

-   Documents (e.g. court order)

  -------------------------------------- --------------------------------
  ***SEND TO COURTS***                   ***RECEIVE FROM COURTS***

  *Court Orders (for Judge's signature)* *Court Orders (with Judge's
                                         signature)*

                                         
  -------------------------------------- --------------------------------

-   

-   Forms (e.g. child support complaint or petition)

+-------------------------------------+--------------------------------+
| ***SEND TO COURTS***                | ***RECEIVE FROM COURTS***      |
+-------------------------------------+--------------------------------+
| *Petitions to...*                   | *Notice of Hearing*            |
|                                     |                                |
| *Establish Paternity*               |                                |
|                                     |                                |
| *Establish Child Support Order*     |                                |
|                                     |                                |
| *Enforce Child Support Order*       |                                |
+-------------------------------------+--------------------------------+
|                                     |                                |
+-------------------------------------+--------------------------------+

2.  **How** **are** you receiving/sending the information now?

-   What is the **method** by which you receive/send the information?
    (e.g. mail, fax, phone, electronic transfer, like email)

  ----------------------------------- -----------------------------------
  ***SEND TO COURTS***                ***RECEIVE FROM COURTS***

  *Personal delivery*                 *OAG-CSD staff personally pick-up*

  *Mail*                              *Mail*

  *Electronic -- limited use for data 
  transfer only*                      

                                      
  ----------------------------------- -----------------------------------

-   How **often** do you receive/send information?

  -------------------------------------- --------------------------------
  ***SEND TO COURTS***                   ***RECEIVE FROM COURTS***

  *Daily*                                *Daily*

                                         
  -------------------------------------- --------------------------------

-   Are there any **deficiencies, problems, issues or concerns** related
    to receiving/sending information?

  ------------------------------------ ----------------------------------
  ***SEND TO COURTS***                 ***RECEIVE FROM COURTS***

  *Any electronic data transfer must   *Delays in data entry (due to
  be followed-up with a paper copy of  backlogs) by Court staff results
  documents or forms filed.*           in filing dates being aside well
                                       after the OAG-CSD has delivered
                                       documents/forms.*
  ------------------------------------ ----------------------------------

3.  **How would you like to** receive/send it?

-   What is the **method** by which you would **like to** receive/send
    the information?

+----------------------------------+-----------------------------------+
| ***SEND TO COURTS***             | ***RECEIVE FROM COURTS***         |
+----------------------------------+-----------------------------------+
| *True electronic filing          | *Electronic data transfer and     |
| [without]{.underline} follow-up* | notices*                          |
|                                  |                                   |
| *With paper copies*              |                                   |
+----------------------------------+-----------------------------------+

-   What would you **have to do on your side** to receive/send it this
    way?

```{=html}
<!-- -->
```
-   Systems programming changes to allow for data transfer

-   Coordinate with approximately 250 District Clerks in Texas to
    develop and implement

-   Coordinate with other entities individually, e.g. different
    districts of Bankruptcy Courts

```{=html}
<!-- -->
```
-   Would you **send anything back** to the courts notifying them that
    data was received?

> *Yes, confirmation that data transfer was received.*

-   How would this method **improve the Child Support Enforcement
    process**? (e.g. savings in staff time, expediting collections,
    etc.)

```{=html}
<!-- -->
```
-   Savings in staff time

-   Reduce/eliminate data entry errors

[Questions relating to Electronic Interface with the Courts]{.underline}

4.  Do you have any **plans** to exchange data with your courts via an
    electronic interface?

-   **If so**, do you envision having to make modifications to your CSE
    system to accommodate this interface and if so, what would the
    modifications consist of?

> *Yes. Current programming to create interface to provide updates to
> the system of filing date, hearing date, cause number, indicator that
> filing was completed. Programming also to be performed to accommodate
> electronic filing with bankruptcy courts.*

5.  What is your **computing environment** with respect to the
    following:

-   What **hardware** does your current CSE system run on?

```{=html}
<!-- -->
```
-   Compaq Deskpro EN833

-   EVO 1.8 Ghz Desktops

-   Dell Latitude 700 Mhz Notebooks

```{=html}
<!-- -->
```
-   What **software** do you use?

> *Please refer to attached list, at end of survey.*

-   What **Operating System** do you use?

> *Windows 98 until March 2003, after which will be Windows XP*

-   What **Network** do you have?

> *Netware 6*

-   What type of **Database** (database environment) would be the
    recipient of information from the courts?

> *ADABAS Natural*

6.  Concerning the **users** that would access information from the
    courts:

-   **How many** users would have access to the court supplied
    information

> *All OAG-CSD Field Operations employees, approximately 2,100.*

-   Of those, what percentage have access to the Internet

> *100%*

-   Of those, what percentage have access to the E-mail

> *100%*

-   Of those with E-mail access, what **e-mail application** do you use
    (e.g. LotusNotes, Outlook, etc)

> *Novell Groupwise*

7.  Who would **maintain/operate** the electronic interchange
    environment?

> *Likely the OAG-CSD, as is currently the case with limited electronic
> filing current being performed in interfaces with four county District
> Clerk's offices.*

8.  Do you have any **documentation** related to constructing an
    electronic interface with the courts?

-   Project Plans

-   Cost Information

-   Design Documents

-   Implementation Plan

> *Because current data exchange with county District Clerks is not true
> e-filing, it is not necessarily the basis for documentation of
> electronic filing to be developed.*
>
> *Development and documentation of electronic filing with Bankruptcy
> Courts is in progress.*

  ----------------------------------------------------------------------------
  **Application**                                                **Version**
  -------------------------------------------------------------- -------------
  Acrobat Reader                                                 5.05

  Compaq Diagnostics \*                                          4.02a

  Earthlink Lite                                                 5.0.7

  Entire Connection                                              4.3.1.1

  Groupwise Client \*                                            6.0 SP2

  GWFax Client \*                                                5.5

  IPTV Viewer                                                    3.4

  Java 2 Runtime Environment \*                                  1.4.1

  MacroExpress                                                   3.0f

  Shockwave                                                      8.5.1

  Flash \*                                                       6

  Authorware                                                     6.5

  Netscape Communicator \*                                       4.8

  Norton AntiVirus Corporate Edition                             7.61 41b

  Novell Client \*                                               4.83 SP1

  Novell Client for Windows                                      

  Remote Management                                              

  Zenworks Imaging Service                                       

  Zenworks Application Launcher                                  

  Novell Workstation Manager                                     

  Novell Distributed Print Services                              

  Office Professional \*                                         XP SP1

  Access                                                         

  Excel                                                          

  PowerPoint                                                     

  Word                                                           

  Photo Editor                                                   

  PowerToys                                                      XP

  Alt-Tab                                                        

  CmdHere                                                        

  TweakUI                                                        

  Printer drivers                                                 

  Lexmark Optra, E32x (PCL)                                      7.4

  Epson Stylus C80                                               5.3

  Xerox DocuColor 12                                             1.5

  QuickTime Player                                               6

  RealOne Player                                                 6

  Rumba for Mainframe                                            7.1

  Seiko Smart Label                                              4.61

  Sybase Client                                                  12.5

  TechSmith Codec                                                2.0.2

  Visio Viewer \*                                                2002

  VitalAgent                                                     8.2.5

  VPN Client                                                     3.52

  Windows Media Player                                           8

  Internet Explorer                                              6.0 SP1

  Windows Script Host                                            5.6

  System Restore                                                  

  Remote Desktop Connection                                       

  WinZip \*                                                      8.1

  WinZip Command Line Add-on \*                                  1

  WordPerfect                                                     8 / 10
  ----------------------------------------------------------------------------

**Notes on Interview with Steve Spitzer, System Manager, DCS SEMS
Imaging Project and Gary Masten, County Clerk**

**State of Washington**

#### Date: 12/10/2002 {#date-12102002 .unnumbered}

Washington is state-based, administrative remedies.

SEMS Imaging System Discussion

-   System had its genesis in 1987 when the Central Registry Law came
    out; it provided for a central area for status updates for
    interstate referrals -- it let other states know status of a case.

-   Washington created a centralized area (Central Repository); cases
    were established within the CSE system.

-   Legislation was initiated that required county clerks to submit
    copies of child support orders to a central location and payments
    had to be submitted to this same central location (regardless if the
    case were IV-D or not); so all orders and payments came to the
    central registry (was initially a nightmare because there are 39
    counties).

-   Technology available at that time (pre-windows) was fax; fax
    machines were leased for all counties (slow, labor intensive for
    clerks; some refused to fax orders and just mailed them).

-   By 1997, 100% of orders and payments were coming to the central
    location; welfare reform had just gone into effect; SDU was now the
    law.

-   In 1997 an imaging system was installed to process child support
    payments to keep up with volume (80,000 payments/month; by October
    2002 there were 196,000 payments/month with 100,000 being
    electronically deposited); no new staff were hired.

-   Court order unit also wanted something built, so in 1997 Case
    Archive system was built.

-   Built an infrastructure in an imaging environment; followed a
    4-phase process:

1.  Identified present processes used in counties

2.  Had to be able to process paper and then switch those using fax to
    redirect images to fax server

3.  Identified those clerks that had an imaging system and have the
    capability to export directly into the state system with index
    information; so county clerk would not have a delay for case setup
    (would be done automatically) and would go directly to state-wide
    system; no extra work for caseworker

4.  Then double back on low technology counties without imaging systems;
    state would provide imaging systems to them to eliminate fax; scan
    would go directly to state system

-   Phase 3 is complicated; counties have chosen different imaging
    products; so have to publish standards; 4 standards already exist;
    standard 5 is case file application (case file imaging system to
    eliminate archiving).

-   IV-A is also building an imaging system and considering being able
    to exchange information with them; they are using XML.

-   Currently only 29% of court orders are paper (fax or mail; 5% mail).

-   Have centralized 100% of case correspondence.

-   Washington uses IRS codes to build administrative remedies; they
    take direct enforcement actions; majority are Superior Court orders
    (only few are absent of court order which are usually separated
    parents); most are entered by county clerks; trend is more IV-D
    agencies are in control to see that program is carried out
    efficiently (like SDU).

-   Centralized court orders should be done so that all caseworkers can
    query system.

-   Benefits of XML:

```{=html}
<!-- -->
```
-   Standard file format; wouldn't matter what kind of system sender has

-   TIF is still used for imaging; XML would have name of image file, or
    may contain many different court orders and relates back to images
    that come in separately

-   Adding XML because it is becoming the standard

-   Most imaging systems have export capability; some use PDF format and
    they convert to Group 4 TIFF compression; some are multi-page
    format; so have to be able to read multi-page TIFF and PDF

-   Counties are protective of their firewalls, so have to be able to
    map servers; WA uses Virtual Private Network which allows them to
    get behind the state firewall and make the transfer

-   Preferred way to send images is email (but are limitations on file
    size)

-   Can be difficult to change infrastructure

-   So, they are trying to identify the most common methods for
    exporting; XML could help with trying to standardize the methods

```{=html}
<!-- -->
```
-   Documentation

```{=html}
<!-- -->
```
-   They are writing a System Documentation Book

-   Have some description documentation (flow diagrams, phases); are in
    VISIO, Steve will send

-   Cost-benefit data

-   Had quality tools that collected info about court order piece

-   Have won several national awards and the award documentation
    contains benefit data

-   Steve will send documentation and we will follow-up

**Washington County Clerks and DCS Imaging System**

DCS began efforts a few years ago to use imaging technology to receive
and process child support orders from the county clerks. The strategy
has been to implement this in four phases as budget and development
cycles allow. Phases One and Two are now complete. To expedite the
process, Washington has combined Phases Three and Four to be implemented
concurrently. Brief descriptions of the phases, with their respective
status, are provided below.

1.  [Phase One]{.underline} -- Converts all faxes and mailed orders to
    images via scanners in DCS Central Operations. The purpose of this
    important phase was to introduce court order imaging to DCS staff
    and develop the DCS court order imaging infrastructure. This phase
    did not affect the county clerks. This phase is now complete.

2.  [Phase Two]{.underline} -- This phase simply redirected the clerks'
    DCS fax machine phone number to a new Fax Server phone number. This
    required the clerks to add bar code separator pages between faxed
    court order documents in order for the DCS Fax Server to recognize
    the documents. This phase saved DCS Central Operations the chore of
    having to sort and manually scan the court order documents. An
    unexpected twist was discovered when it was revealed that the clerks
    with imaging systems could not easily add the bar code separator
    sheets when using the fax out features of their imaging systems.
    This excluded the clerks with imaging systems from the Phase Two
    development. Phase Two is now complete.

3.  [Phase Three]{.underline} -- During this phase, DCS negotiates with
    the county clerks who have imaging systems and arranges for those
    counties to export directly out of their imaging systems into the
    DCS imaging system. Depending on the county capability, DCS may also
    import shared index data. DCS has successfully tested this with
    Pierce County. Pierce County has been using this method since April
    5, 2002. The State now has many more counties converted to this
    method. Negotiations with the county network staff will be
    successful, but it takes time to address security concerns. It is
    estimated that the clerks with imaging systems will be converted by
    March 2003. Benefits to the DCS Central Operations Unit will include
    the elimination of sorting and scanning the paper. The benefits to
    the county will depend on how the county's imaging system workflow
    is designed and the current process to get court order documents to
    the DCS Central Operations Unit. These county benefits may range
    from neutral to substantial, depending on the county. Overall
    benefits will include quicker delivery of child support orders and
    faster DCS establishment and enforcement actions.

4.  [Phase Four]{.underline} -- During this phase, DCS-provided fax
    machines will be replaced with scanners. This solution is intended
    for those counties who do not have imaging systems. The State has
    identified 18 counties that fit this criterion and all have been
    contacted. Nine of them are ready to make the change right now. The
    State is either negotiating or waiting for responses from the other
    nine. Process should be complete no later than June 2003, if all 18
    remaining counties are converted to this solution. Presently,
    Snohomish County is using this solution and the feedback received
    has been very positive. For counties that have been laboring over
    fax machines, this is a welcome solution. It also helps the DCS
    Central Operations Unit since staff will no longer have to sort and
    scan the paper. In addition, the child support orders are delivered
    faster resulting in quicker child support enforcement activities.

To summarize, if all goes well with the acquisition request, Washington
should be able to complete Phase Three by March 2003 and complete Phase
Four by June 2003. For counties that are eligible for Phase Four, two
counties per month should be converted beginning October 2002.

***Current status***: 75% of all court orders are now imported from the
counties to the system; 100% of all mail is imaged; 50% of the back file
conversion of case file document is completed.

For counties that fax court orders to the state, data exchanged
currently consists of a bar code separator page for each faxed court
document that identifies the document.

For those advanced counties that are exporting the document directly out
of their imaging system, those data elements that are relevant to the
statewide child support system (such as date filed and cause number) are
indexed and that information is inserted into the child support system
directly. The electronic court order is transmitted electronically to
the DCS imaging system.

To fully automate setup of the child support cases, it is necessary to
expand the number of data elements indexed from the court order. This
task is currently being investigated. There are strict rules about how
an order is formatted, so court orders are fairly standard. OCR
technology is being considered to identify the particular section that
specifies order amount (for example) and to capture the value specified
and then automatically transmit it to the child support system.

The data requirements that specify how the data would be mapped will be
considered during the design of the indexing capability.

**Insert Washington's Imaging Process Flow Chart (1 page)**

**Insert Washington's System Development Overview (1 page)**

**Notes on Interview with Dave White, Child Support Specialist (CSE Call
Center)**

**Bureau of Partner Services, Department of Workforce Development**

**State of Wisconsin**

**Date: 2/21/2003**

Current exchange is a paper process. CSE agency is co-located with the
courts.

Office of the State Courts recently finished a two-year e-filing study.
Study recommends a pilot in appellate and circuit court. Contacts
regarding study: Teresa Owen, 608-261-4301 and Andrea Olson (Clerk of
Court Automation Project \[CCAP\] technical staff member), 608-264-6908.

Completed a cost/benefit analysis for a KIDS/CCAP interface in 1994;
didn't proceed primarily because of lack of funding and also determined
it wasn't worth the effort.

Order processing -- CSE agency staff involved in court cases, present in
court. They generate the paperwork and file with the court.

Interstate: use CSENet. Incoming request comes to state office and is
sent to counties. Other states do not send requests or communicate with
courts directly.

E-filing would have a significant impact on the agency.

Bureau of Child Support, Operations Section, KIDS contact -- Steve
Buechner, 608-267-9539.

**Notes on Interview with Dan Floeter, Family Court Commissioner; Kerry
Widish, Court Manager; Donna Wills, Net Administrator; Gail Richardson,
Madison County Court Administrator**

**State of Wisconsin**

**Date: 2/26/2003**

Existing capability of electronic exchange from court perspective:

-   CSE agency emails calendars to courts

-   KIDS access -- have look-up capability, can schedule court dates,
    generate notices, update addresses, look for an order and the order
    amount, review and print payment records, do income assignments, see
    case notes.

-   Started imaging last year. Imaged database contains family and
    paternity court documents (stored on county server); available for
    users to view after scanned; IV-D also has access to the database.

Imaged database process -- orders are generated by KIDS; hard copies are
sent to court and those are imaged; Dane County server stores the
images; not everyone has passwords or direct access on their desks.

Courts system -- county; KIDS -- statewide. Office of State Courts uses
CCAP system. Office staff on county network. Support enforcement staff
on county network. Paperwork is exchanged between state and county
systems.

Benefit of electronic interface:

-   Is suspect because they would have to change the way they do
    business. Have access to KIDS for what they need.

-   Study for electronic filing indicated there would be a benefit for
    clerk's office, public defenders, attorneys with respect to added
    efficiency; child support was not mentioned in the discussions.
    Study going on to the State Supreme Court; will be 2 years before it
    is a reality.

New courthouse is being built and will be finished in 2005. Offices will
be wired for KIDS so they will not lose any access they currently have.
Will have access to imaged orders for newer cases where orders have been
imaged. May change the way they do things; electronic filing may be
available from CCAP which would change the environment.

Suggestion was made to talk to someone in CCAP about the electronic
filing study.

D.  []{#__RefHeading___Toc37493062 .anchor}National Survey of Court
    Information Technology Status

E.  []{#__RefHeading___Toc37493063 .anchor}General overview and
    background child support XML standards

F.  []{#__RefHeading___Toc37493064 .anchor}Draft child support XML
    specification for iv-d agency review