Casebook PBC Logo
Schedule Demo

On June 2, 2016, the Administration for Children and Families (ACF) issued a final Comprehensive Child Welfare Information System (CCWIS) rule to replace the Statewide and Tribal Automated Child Welfare Information Systems (S/TACWIS) rule, which for more than twenty years had been the vehicle through which states sought federal assistance for funding child welfare technology efforts. This brief provides our analysis of the final rule and its implications for states and tribes seeking to modernize their technology portfolios. Note: States should consult with ACF regarding definitive interpretations of the rule.

CCWIS as a Force for Innovation

A key purpose of the CCWIS rule is to specify how states and tribes may obtain federal financial participation (FFP) for a CCWIS project. As with S/TACWIS, ACF determines CCWIS compliance through review and approval of a state’s or tribe’s Advance Planning Document (APD) or a Notice of Intent (for projects below the APD threshold), as well as through periodic federal monitoring. The rule does not change the APD process or the FFP rate, which remains at 50% of project costs. CCWIS, like its predecessor, is optional for states and tribes. The nature of what qualifies as a “project,” however, has changed significantly with CCWIS.

Under the old S/TACWIS rules, FFP was only available to a state or tribe that developed and operated a single, large system that all public and private child welfare workers used. Moreover, ACF mandated fifty-one distinct functions that any such monolithic S/TACWIS system had to support.

Under the new CCWIS rule, ACF does not specify such functional requirements. Instead, IV-E agencies are encouraged to innovate in keeping with their individual needs and practices. For example, states and tribes may obtain FFP to build smaller, more modular subsets of functionality aligned with their practice models, or perhaps with an incremental legacy system replacement plan.

They might choose to obtain certain types of data through automated integrations rather than collect it within the child welfare application itself. From an implementation perspective, they might opt for a project approach based on modern Agile software development techniques, as California and other states have done.

The states’ early responses to CCWIS—as embodied in procurements issued around the time the final rule was released—have already shown an eagerness to experiment with such new approaches.

A Laser Focus on Data

CCWIS specifies requirements for categories of data needed in child welfare information systems and how that data must be stored, managed and exchanged across systems. The emphasis in CCWIS shifts from required functions to best practices in data management and system design. This shift recognizes the crucial role of accurate and timely data in driving better child outcomes.

Differences between CCWIS Projects and S/TACWIS Projects

Bi-directional Data Exchanges

The most significant difference between CCWIS and S/TACWIS is that IV-E agencies are no longer required to have users directly enter all data into the state’s primary child welfare application. Instead, the data may be collected in other systems and provided to CCWIS application(s) through bi-directional data exchanges. Five mandatory data exchanges have been added to the six exchanges required under S/TACWIS.

The S/TACWIS mandatory exchanges were:

  • IV-E/IV-B financial systems
  • IV-E eligibility systems
  • Title XIX Medicaid eligibility systems
  • IV-A TANF systems
  • IV-D child support systems
  • State child abuse and neglect systems

CCWIS adds these mandatory exchanges:

  • Medicaid claims
  • Education systems
  • Child welfare courts
  • Child welfare contributing agencies (CWCAs), if these CWCAs collect CCWIS data
  • Any other systems the IV-E agency uses to collect CCWIS data

If a state contracts with CWCAs to deliver child welfare services, the state must either require those agencies to enter that information directly into CCWIS (as under S/TACWIS) or establish bi-directional data exchanges so that this data can be transmitted to and maintained in CCWIS. Timelines for implementing new functionality or new bidirectional data exchanges depend on a state’s approved APD.

Data Quality

A second major change is the emphasis on data quality rather than child welfare functions. Where S/TACWIS regulations mandated that systems support specific functional requirements, CCWIS defines the scope of CCWIS data and mandates closer monitoring of the quality of that data.

This emphasis on data quality is all the more crucial given that states and tribes are now free to distribute data collection across multiple systems and then aggregate the data in the core CCWIS application. The CCWIS final rule expects closer monitoring of data so that this new flexibility in data collection methods doesn’t compromise the completeness, timeliness, accuracy or consistency of the data.

Data quality provisions of the rule include:

  • a new data quality plan that each IV-E agency must develop, submit and use to monitor and correct any quality issues
  • a new biennial data quality review
  • a requirement for data exchange standards for the bi-directional CWCA integrations
  • automated functions that monitor data quality, including a new requirement for automated functions that alert staff to collect, update or correct CCWIS data; staff include direct users of CCWIS and staff at contracted CWCAs who use their own systems

One consequence of allowing states to collect data from multiple systems—and of moving from requirements based on functionality to requirements driven by data needs and data quality monitoring—is that states can now tailor CCWIS functions to their unique business needs. Business processes may now vary between and within states as long as complete, timely, accurate and consistent data is stored and managed in CCWIS. Each state/tribe will choose the automated functions they wish to develop as part of their CCWIS, then document and update that list as part of their APD submissions.

Design Requirements

The third major difference between CCWIS regulations and S/TACWIS is that the new CCWIS regulations specify design requirements. These design requirements replace the long list of federal functional requirements. The CCWIS design requirements apply to (i) all new development after a 24-month transition period for a S/TACWIS or non-S/TACWIS transitioning to a CCWIS, and to (ii) all functions in newly-minted CCWIS systems.

New CCWIS functions must:

  • be modularly designed and separate business rules from core programming (waived for Software as a Service systems owned and maintained by vendors)
  • be documented in plain language o follow information technology standards that promote efficient, economical and effective development
  • be shareable and reusable by other states, tribes, and agencies

The Transition Period

The rule provides for a transition period of 24 months (ending August 1, 2018) during which a Title IV-E agency with an S/TACWIS or a non-S/TACWIS project must indicate to ACF whether it intends to:

  1. transition the existing S/TACWIS or nonS/TACWIS to a CCWIS;
  2. become a non-CCWIS agency; or
  3. build a new CCWIS

The transition period gives agencies time to evaluate their current needs, review data requirements, assess current IT systems and decide which of the three options is the best fit. The Title IV-E agency does not need to finish the transition within the 24 months, only indicate the path it’s chosen. The rule does not establish a timeframe for finishing a CCWIS project; the IV-E agency proposes a timeframe in a subsequent APD. During the transition period, a IV-E agency may continue to claim FFP according to its current ACF-approved cost allocation methodology.

Weighing the Options

States and tribes may find some benefit in opting to transition their current system rather than build a brand-new CCWIS. IV-E agencies can preserve their investments in current systems by opting to use those systems as the foundation for a CCWIS compliant system. If a state or tribe properly notifies ACF during the transition period of its intent to transition its legacy system to CCWIS, then only automated functions that are to be developed after the transition period are required to the meet CCWIS design requirements. Existing automated functions are exempt from this requirement.

An agency might, for example, extend its existing system with new CCWIS-compliant functionality, or tie in cloud-hosted services that actually replace system components that no longer serve the agency’s needs. Recent state procurements in Illinois and California have focused on upgrading business processes like Placement Matching and Intake with modern solutions which satisfy CCWIS design requirements by exchanging data with the legacy system through web services. Agencies may find such an incremental approach more suited to their budgetary and organizational constraints.

If an agency chooses the new-system route, by contrast, all the functionality in that new CCWIS must meet all CCWIS design requirements. New CCWIS systems can become exempt from CCWIS design requirements in only two ways: (1) ACF grants a waiver exempting the functionality from one or more of the design requirements, or (2) the functionality is part of commercial off-the-shelf (COTS) or vendor-maintained Software as a Service (SaaS) solutions not subject to the design requirement.

At the close of the transition period all child welfare systems will be classified as either CCWIS or non-CCWIS. Non-CCWIS states and tribes may build a new CCWIS at any time by going through the required ACF approval processes, but it appears that the option to transition a current system to CCWIS will ultimately be closed.

CCWIS Cost Allocation

Through the APD or Notice of Intent process, ACF may approve CCWIS cost allocation for automated functions/modules developed under an ACF-approved plan if the planned functionality:

  • meets CCWIS design requirements or is exempted by a CCWIS design waiver
  • supports at least one of the project requirements that defines a CCWIS
  • does not duplicate functionality within CCWIS or systems supporting CWCAs
  • is consistently used by all child welfare users responsible for the area supported by the automated function/module

The rule makes clear that the existence of duplicated functionality will not cause ACF to classify a system as non-CCWIS. The agency may claim non-CCWIS cost allocation for the duplicated function, and the system may remain a CCWIS. More generally, states/tribes may build a system that partially qualifies for the CCWIS cost allocation while the remaining parts of the system do not. This is a significant change from S/TACWIS, which required IV-E agencies to implement a system providing all mandatory S/TACWIS functionality to qualify for S/TACWIS FFP.

Implications for States and Tribes

As the overview to the final rule states, new CCWIS systems may contain all the functions required to collect and maintain CCWIS data (similar to a current S/TACWIS); may act as a data repository that aggregates data captured in other systems; or may fall somewhere between these two poles.

States may hire vendors in a variety of roles, from managing the CCWIS data repository to building functional modules that meet the business needs of users and exchange quality data with the CCWIS data repository. Some states may opt to procure both types of services, or others in keeping with CCWIS.

The most immediate task for states and tribes is to assess, during the 24-month transition period, whether they want to (i) transition their current S/TACWIS or nonS/TACWIS to a CCWIS, (ii) go the nonCCWIS route, or (iii) build a brand-new CCWIS.

An existing system that is compliant with the current S/TACWIS requirements may be able to achieve CCWIS compliance by developing the five newly required bi-directional data exchanges and documenting data quality procedures in the new and required data quality plan. ACF acknowledges this possibility in the rule, though it will conduct a case-by-case evaluation.

We believe that non-S/TACWIS systems will need to focus on new themes if they wish to become CCWIS-compliant. Presumably, the APD approval process will no longer be focused on the fifty-one functional requirements and will instead turn on (i) reporting and other uses and categories of data that will be needed and (ii) how those data are stored and managed in CCWIS and exchanged across other systems. We expect that these new project requirements which emphasize data management, in addition to the new design requirements of modularity, reusability and efficient, economical and effective development, will replace the old federal checklist of functions.

What You Can Do Now

Action steps we recommend for agencies with non-S/TACWIS systems include:

  • Assess required federal and state child welfare data needs and requirements (perhaps re-evaluating state requirements)
  • Assess the use of current information systems to understand what it would take to make them CCWIS-compliant
  • Evaluate whether the best strategy is to collect data directly in CCWIS or in other systems (existing or new) that exchange data with CCWIS
  • Establish IT budgets if they choose to either transition to CCWIS or build a new CCWIS

A Bold Policy Initiative

CCWIS is a bold policy initiative that reflects twenty years of collective experience, among countless stakeholders, in fielding systems to improve outcomes for children. By focusing on data and data quality rather than the particulars of how states and vendors implement specific functionality, it promises to spur innovation across the country and stimulate creative solutions that are closely tailored to the local concerns of specific IV-E agencies.

While the practical implications of CCWIS will emerge only as APDs and projects get underway, there are steps agencies should take now to set their course and lay the groundwork for the future. With the clock running on the CCWIS two-year transition period, there is much good work to be done.