Reporting & Data Quality
On this page
| For report generation instructions, see Supervisor Guide: Reports. |
|
Target-state design page: the screens below are the design engagement’s
target mockups, not the as-built system. Built today: data-quality issues are
created by craig-reporting’s own inbound-event validators (per-event-type
missing-field checks against a documented producer-payload allowlist), listed
on the reporting dashboard with a severity breakdown and an issues list; the
AFCARS and NCANDS submission surfaces exist as workflow records with
review/approve/transmit/export routes. The two programs differ today: NCANDS
extraction is built (the #654/https://gitlab.com/gadhs/application/ccwis/craig/-/issues/655[#655]/https://gitlab.com/gadhs/application/ccwis/craig/-/issues/656[#656] trio) — generate materializes real
cases-sourced child rows with database-authoritative counts (including the
fatality count), stamps |
The Reporting module is designed to satisfy the Comprehensive Child Welfare Information System (CCWIS) requirement to maintain ongoing automated data quality monitoring and to generate all required federal reports — primarily AFCARS (Adoption and Foster Care Analysis and Reporting System) and NCANDS (National Child Abuse and Neglect Data System). Data quality issues are surfaced in real time to the workers who can fix them, not just to administrators after the fact.
Primary users: Supervisors, Administrators (the reporting navigation admits supervisors and administrators)
Screen 1: Data Quality Dashboard
The dashboard gives supervisors and administrators a continuous view of data quality across the jurisdiction. In the target design, the Rules Engine monitors all cases against federal and state data quality standards and populates this view automatically, with no manual data pulls or batch jobs. As built, the view is populated by craig-reporting’s own per-event validators.
Key elements:
-
Automated monitoring: the design target is Rules-Engine evaluation of all case data against a jurisdiction data-quality plan; as built, checks are per-event missing-field validations local to craig-reporting, surfaced without batch jobs or exports.
-
AFCARS / NCANDS readiness: the design target is a readiness percentage that updates as workers correct errors; as built, the metrics behind those tiles have no writer yet, so they render a placeholder.
-
Critical errors panel: the design target links each error type directly to the filtered list of cases needing correction; as built, the dashboard shows a severity breakdown and links to the flat issues list.
-
Timeliness breakdown: each federally-monitored timeframe is reported separately so supervisors can identify which specific requirements need attention.
-
Trend line: quarterly trend allows administrators to see whether data quality is improving over time and document progress for Administration for Children and Families (ACF) review (45 CFR § 1355.55).
Screen 2: AFCARS Submission Workflow
The submission workflow guides administrators through the steps required to produce a clean AFCARS file for transmission to ACF. In the target design the system validates all records before allowing submission; as built, AFCARS validation and extraction are pending (see the note above).
Key elements:
-
Four-step workflow: validation must be clean before agency review can begin; agency review must be complete before state approval; state approval must be granted before transmission. The built workflow records enforce this sequence, though with extraction unbuilt a draft stub cannot yet advance through it.
-
Record counts: AFCARS counts are displayed before submission so administrators can verify the numbers match their own tracking before sending to ACF.
-
Inline error remediation: the design target links each validation error type to the cases with that error, with re-validation inside the workflow; as built, validation errors are a single count on the submission record.
-
Export Preview File: the design target is a preview of the AFCARS flat file; as built, the export is a metadata-only TSV (no record content yet).
-
Submission to ACF: in the target design the final step sends the file directly to ACF’s transmission system (the legacy Statewide Automated Child Welfare Information System — SACWIS — channel) and records the acknowledgment; as built, transmit records the timestamp only (a status-only stub).
Screen 3: NCANDS Submission
NCANDS captures child abuse and neglect data from investigations and is submitted annually. The workflow mirrors AFCARS but draws from the Intake module rather than the placement record.
Key elements:
-
Dual submission cadence: AFCARS is submitted quarterly; NCANDS is submitted annually for the federal fiscal year ending September 30. Calendar management is a design target — as built, the AFCARS reporting period is a free-text label, while the NCANDS year functionally drives the fiscal-year export.
-
Fatality tracking: child fatalities are a mandatory NCANDS data element; as built, the submission carries a fatality count derived from the materialized child rows, and per-case quality-review flagging is a design target.
-
State approval gate: the state administrator’s approval is the final step before transmission; this provides a governance checkpoint consistent with state agency accountability requirements.