CCWIS: federal requirements for a child welfare information system

Reference article · 6 min read

Every title IV-E agency that replaces a SACWIS-era child welfare system runs into the same surprise: the federal conditions attached to the money are mostly about information, not about software. The Comprehensive Child Welfare Information System (CCWIS) rule, issued by the Administration for Children and Families (ACF) and codified in the federal child welfare regulations, sets conditions on what data the agency holds, how accurate that data is, who it is exchanged with, and how the design is documented. It says comparatively little about screens, workflows, or product features.

That distinction shapes the whole project. Agencies that treat CCWIS as a feature checklist tend to satisfy the parts they worried about and stumble on the parts they did not. The findings that actually appear are usually owned by program, legal, and data staff rather than developers: bi-directional exchanges with external partners, the agreements that authorize them, and a data quality plan the agency genuinely operates. The rule has been amended since it was first published and continues to be interpreted through ACF guidance, so confirm current regulatory text, cost allocation terms, and deadlines with ACF and your own counsel before locking a project plan.

What CCWIS changed from SACWIS

SACWIS was built around a single comprehensive system. CCWIS is not. The rule permits an agency to assemble its child welfare information system from modules, including components operated by other agencies or vendors, provided the agency can account for the data and describe the design.

From one system to one authoritative dataset. The agency must maintain the required child welfare data and be able to show where each element lives, regardless of how many modules are involved.
Modularity expectation. Designs are expected to be modular, with business rules separated from core code where practicable, documented interfaces, and components that can be replaced without rebuilding the whole system.
Reuse. Custom software built with federal funds generally carries federal license and reuse rights, and ACF expects design artifacts and code to be shareable with other title IV-E agencies.
Enhanced funding is conditional. Elevated federal financial participation for design, development, and installation is tied to the project meeting CCWIS requirements. ACF can withhold, reduce, or disallow that participation if the system falls out of compliance, so treat compliance as a funding control, not a paperwork exercise.

The automated functions the system must support

CCWIS is judged in part on whether the system supports the automated functions needed to administer title IV-B and IV-E programs and to produce federal reporting. In practice that spans intake, investigation or assessment, case planning, placement, eligibility determination and payment, and the underlying data for AFCARS, NCANDS, and NYTD submissions. When scoping, sort desired functionality into three buckets: what the rule requires, what state law or court rules require, and what the agency wants. Only the first carries CCWIS finding risk, and conflating the three is how scope and schedule get away from a project.

Data exchanges are where compliance usually breaks

The rule requires the agency to exchange data with a defined set of partners, and where practicable those exchanges are bi-directional rather than a one-way extract. The typical partner list includes the courts, Medicaid and other human services programs such as child support and TANF, state and local education agencies, contracted service providers, child abuse and neglect systems, and the systems of other title IV-E agencies. Exchanges are expected to follow the agency's own documented data exchange standard rather than a different hand-built interface for each partner.

The software side of this is rarely the obstacle. The obstacle is the memorandum of understanding, the data sharing agreement, the confidentiality analysis, and the partner's willingness and technical capacity to send data back. Start those conversations at project initiation, not at integration testing. Where an exchange is not practicable, document the determination and the reasoning in writing at the time you make it.

The data quality plan

The rule requires a data quality plan covering completeness, timeliness, accuracy, and consistency of the data the system holds, along with how the agency monitors quality, detects problems, and corrects them. The rule also contemplates recurring data quality reviews on a defined cycle; confirm the current interval and content expectations with ACF.

The common failure is a plan written for a submission and then shelved. A plan that survives review names the specific measures, the owner of each, the frequency of monitoring, the threshold that triggers action, and where the results are recorded. Reviewers look for evidence that the cycle ran and that identified problems were actually remediated.

Documenting compliance and what a review looks like

Compliance lives in artifacts, and those artifacts are produced through the advance planning document process that governs federally funded human services systems. Expect to maintain and keep current:

The APD and its updates, including prior approval requests where thresholds apply.
Notification to ACF of the agency's intent and design approach.
Design documentation, including the data model, module descriptions, and interface documentation.
The project management plan and current schedule.
The inventory of data exchanges, the supporting agreements, and any practicability determinations.
The data quality plan and the results of completed reviews.

A CCWIS review is largely a documentation review, supplemented by discussion with agency staff and, where warranted, demonstrations. If ACF identifies non-compliance, the agency is generally given an opportunity to submit and execute a plan to correct it within a defined period. Unresolved non-compliance is what puts enhanced funding at risk. Keeping documentation current as the project changes is far cheaper than reconstructing it under a review deadline.

What to ask vendors and put in the contract

Ask how exchanges are built, not whether they are supported. Request a description of the exchange standard, the message formats, and how a new partner is onboarded without custom code.
Require design documentation as a deliverable. Data model, interface specifications, and module boundaries should be contract deliverables with acceptance criteria, not artifacts produced on request.
Address license and reuse rights explicitly. Confirm the agency receives the rights the federal rules require for custom software funded with federal dollars, and that those rights survive contract termination.
Separate configuration from code in writing. Require that policy-driven business rules be configurable by agency staff, and define what counts as configuration versus a change order.
Assign compliance support. Name who drafts and updates the APD material, who maintains the exchange inventory, and who supports the agency during a CCWIS review.
Plan the exit. Require data extraction in a documented, non-proprietary format so a future module replacement is a procurement decision rather than a rebuild.

HQT works with state and local agencies on systems engineering and software development for regulated program systems, including the modular design and data exchange work that CCWIS contemplates.

Frequently asked questions

What is the difference between SACWIS and CCWIS?

SACWIS was built around a single comprehensive statewide system that handled child welfare case management in one place. CCWIS replaced that model with a data-centered approach that allows a modular system assembled from multiple components, as long as the agency maintains the required data and documents the design. CCWIS also adds explicit requirements for data quality planning and for bi-directional data exchanges with courts, Medicaid, education agencies, and providers.

Do we lose enhanced federal funding if our CCWIS project is found non-compliant?

Enhanced federal financial participation for design, development, and installation is conditioned on meeting CCWIS requirements, so sustained non-compliance can lead ACF to withhold, reduce, or disallow that participation. In practice ACF generally identifies findings and gives the agency an opportunity to submit and execute a plan to correct them within a set period. Funding consequences follow unresolved non-compliance rather than a single finding, but the specific terms and timelines should be confirmed with ACF.

Which data exchanges does CCWIS actually require?

The rule requires exchanges with a defined set of partners, typically including the courts, Medicaid and related human services programs, state and local education agencies, contracted service providers, child abuse and neglect systems, and other title IV-E agencies' systems. Where practicable those exchanges must be bi-directional rather than a one-way extract, and they should follow the agency's documented data exchange standard. If an exchange is not practicable, the agency should document that determination and the reasoning behind it.

What should a CCWIS data quality plan contain?

It should address completeness, timeliness, accuracy, and consistency of the data the system holds, and describe how the agency monitors quality, detects problems, and corrects them. A plan that holds up under review names specific measures, the staff member responsible for each, the monitoring frequency, the threshold that triggers action, and where results are recorded. Reviewers look for evidence that the monitoring cycle actually ran and that identified issues were remediated.

How early should we involve courts and Medicaid in a child welfare system replacement?

At project initiation, before design work begins. The technical side of an exchange is rarely the constraint; the memorandum of understanding, the confidentiality analysis, and the partner's capacity to send data back are what set the schedule. Agencies that defer these conversations until integration testing routinely find that the agreement, not the interface, is the critical path.