Attachment II-1. A
Child File Instructions
1. PREPARING THE CHILD FILE
The data submission period is defined as the Federal fiscal year. The Child File, as in the past, contains case-level data on each child reported as an alleged victim of child abuse or neglect.
1.1 Creating the Child File
This section describes the structure of the file, the data records in the file, the data elements in the records, and the procedures used for constructing the data file. The Child File consists of child records, each record having the same format. Each child record contains information about only one child, in addition to information about the associated abuse report. The records in the file are ordered by reports so all children within a given report appear together in the file. Within each child record are several data elements, grouped into various data categories.
1.1.1 Overview of the Child Record
Each child record in the Child File allows for the reporting of information about a child associated with a report of alleged child abuse or neglect. All of the data elements in the child record are grouped into these logical data sections:
Report Data (characteristics);
Child Data (demographics);
Maltreatment Data;
Child Risk Factors (disabilities, problems, etc.);
Caretaker Risk Factors (disabilities, problems, etc.);
Services Provided (to the child/family);
Staff Data;
Perpetrator Data (demographics and some maltreatment related data linking perpetrators to child victims); and
Additional Fields.
The details of the record layout can be found in Attachment II-B, Child File Record Layout.
The Report Data section (fields 1–11) contains the two file identifying fields, Submission Year and State ID, and general information about the abuse report. The identifying field for the report, which the child record belongs to, is the Report ID. The identifying field for the child in the child record is the Child ID. All remaining fields in the section are attributes relating to the Report ID.
If a report involves multiple children, the Report Data fields, with the exception of the Child ID, would be identical on each record containing the same Report ID. For example, if there were three children in the report, the data in this entire Report Data section would be identical for all three child records, except for the three different Child IDs.
The Child Data section (fields 12–25) contains general information about the child in the record. All fields in this section are attributes relating to the Child ID.
The fields in the Maltreatment Data section (fields 26–34) include information about maltreatments to the child and the maltreatment disposition level for each specific maltreatment. There is also a field addressing Maltreatment Death.
The fields in the Child Risk Factors section (fields 35–43) indicate whether the child suffered from one or more disabilities or problems. The fields in the Caretaker Risk Factors section (fields 44–55) indicate whether the child’s family or caretaker suffered from one or more disabilities or problems. Additional family or caretaker fields include information on the living environment of the child at the time of the alleged abuse, which might affect the child or place the child at-risk.
The fields in the Services Data section (fields 56–85) contain information about post investigative services, which are opened for the child and/or the child’s family. Each of these services may occur before, during, or as-a-result of the investigation of the report but must continue after the Report Disposition Date.
The fields in the Staff Data section (fields 86–87) contain identification information about the CPS Worker and CPS Worker’s Supervisor, who were associated with the child on the date of the Report Disposition.
The fields in the Perpetrators Data section (fields 88–144) allow for the submission of information on a maximum of three persons who have been established as perpetrators of child victims, e.g., any child with a Maltreatment Disposition Level of “substantiated”, “indicated”, or “alternative response disposition-victim.” The four Perpetrator Maltreatment fields link each perpetrator to the four sets of Maltreatment Types and Maltreatment Disposition Levels fields reported for the child victim (fields 26–34).
The Additional Fields section (fields 145–146) includes the applicable AFCARS ID of the child and the date of the maltreatment incident.
1.1.2 The Use and Encryption of Identifiers
Unique identifiers are critical for the analysis of Child File data because they allow the most successful selection and retrieval of information during the analytical process. All States are encouraged to submit unique identifiers. The NCANDS uses unique identifiers to link multiple children to the same report, for identifying repeat child victims, for identifying repeat perpetrators, and for identifying workers and supervisors. This section discusses in more detail the general concepts concerning unique identification fields.
Each report of child maltreatment should be given a unique report identifier by the State, the field Report ID. A unique identifier for a report is an identifier, which is assigned only one time and to only one specific report. Hence, the report is never assigned an additional identifier (causing multiple identifiers) and the same identifier is never assigned to another report (causing shared identifiers). If the State system does not use report identifiers (e.g., the State only uses a child identifier), the State should create a unique report identifier for the Child File. The report identifier should be the same for all records (children) involved in the same report. For example, if three children were involved in a report, each child record in the report would have the same report identifier, but each child would have a different child identifier. The report identifier is the key field for associating all of the records (children) that are part of the same report.
Similarly, each child should be given a unique child identifier by the State, the field Child ID. A unique identifier for a child is an identifier, which is assigned only one time and to only one specific child. Hence, the child is never assigned an additional identifier (causing multiple identifiers) and the same identifier is never assigned to another child (causing shared identifiers). If the same child is involved in multiple reports, the child should be assigned the same child identifier for all of those reports. However, a given child identifier should only be submitted one time within a given report.
The same unique identifier logic should be applied for the fields of Worker ID and Supervisor ID. A unique identifier for a CPS staff person is an identifier, which is assigned only one time and to only one specific person. Hence, the staff person is never assigned an additional identifier (causing multiple identifiers) and the same identifier is never assigned to another staff person (causing shared identifiers). If the same staff person is involved with multiple reports or with multiple children in a report, the staff person should be assigned the same identifier for all occurrences. Furthermore, if a staff person changes roles, e.g., from a worker to a supervisor, it is advisable that the staff person retains the originally assigned identifier.
Each perpetrator reported by the State should also be given a unique perpetrator identifier by the State, the fields Perpetrator-1 ID, Perpetrator-2 ID, and Perpetrator-3 ID. A unique identifier for a perpetrator is an identifier, which is assigned only one time and to only one specific perpetrator. Hence, the perpetrator is never assigned an additional identifier (causing multiple identifiers) and the same identifier is never assigned to another perpetrator (causing shared identifiers). If the same perpetrator is involved in multiple reports or with multiple children in a report, the perpetrator should be assigned the same perpetrator identifier for all occurrences. However, a given perpetrator identifier should only be submitted one time for a given child in a given report, e.g., a given perpetrator can only appear one time within a single child record.
As data are submitted to NCANDS, the confidentiality of all persons and reports in the data must be strictly preserved. To maintain this confidentiality, appropriate identifier encryption should be applied by the State to all identification fields. Hence, the actual case record identifiers, used within the State databases, should not be included in the Child File. Each identifier for report, child, worker, supervisor, and perpetrator should be encrypted or translated by the State into a new unique identifier at the time the Child File is written. It is also important for the State to completely and privately document their identifier encryption methodology and use the same encryption methodology year after year for data submissions.
States needing assistance with encryption methodology should contact the Children’s Bureau for further information.
1.1.3 Types of Child Record Fields
The various types of fields in the child record are described below. In all cases, each of the data fields have a fixed length and if the State has no value for any given field, the field should be filled with the appropriate number of blank characters.
The identifier fields in the record are Report ID, Child ID, Worker ID, Supervisor ID, Perpetrator ID, and AFCARS ID. Each identifier field is alphanumeric, 12 characters long, with no imbedded blank characters, nor special characters. Each of these identifiers are to be encrypted by the State.
The Report ID and the Child ID are required identifier fields and each field must contain data for all child records submitted. The Perpetrator ID is required if perpetrator data are reported. All respondents are encouraged to include the potential or actual AFCARS ID for the child.
An alphabetic field only contains alphabetic characters. The field length would be exactly as specified in the record layout.
An alphanumeric field only contains alphabetic, numeric, or a mixture of the two types. The field length would be exactly as specified in the record layout.
A numeric field only contains numeric characters. The field length would be exactly as specified in the record layout.
A date field is a numeric field, exactly eight characters in length. The field should be in the “mmddyyyy,” format where “mm” is the month, “dd” is the day, and “yyyy” is the year.
1.1.4 Child Record Coded Fields
Many of the data fields in the child record are coded fields. Any data value submitted in a given coded field needs to match one of the specified values for that field. The following common coding conventions are utilized consistently throughout the child record. The NCANDS codes are defined in Attachment II-B, Child File Record Layout.
If information for a given field or section is not collected at all by the State, the State would place “blanks” in the field, e.g., the State does not collect Perpetrator Age and the field would be left blank. The number of blanks inserted for the field would be identical to the specified field length.
If information for a given field or section is not applicable, the State would place “blanks” in that field, e.g., only one maltreatment was collected and maltreatments 2, 3 and 4 would be left blank. The number of blanks inserted for the field would be identical to the specified field length.
“8” or “88” = other
The “8” or “88” code would be used when the code values do not adequately describe the code value needed by the State, e.g., the State cannot map a certain maltreatment into the NCANDS code values and the code “8” would be used to indicate “other” maltreatment.
“9” or “99” = unknown
The “9” or “99” code would be used if the State does capture and store this information on a routine basis, but the data were not captured or were missing for the given record, e.g., the Perpetrator Age was not determined during the investigation.
“1” = yes, “2” = no
For fields requiring a “yes” or “no” response, the values of “1” = yes and “2” = no are used consistently across all fields.
1.1.5 Child File and Child Record Formats
The following file and record format information should be used in submitting Child File.
The Child File is submitted to NCANDS as a single, flat American Standard Code for Information Interchange (ASCII) file. The file consists of child records, each of which refers to the data associated with one child within a given report. A child record is uniquely defined by the Report ID of the record being linked to the Child ID of the record. This is commonly referred to as the “Report-Child” pair or the “RC” pair, where a unique “RC” pair represents a single child record in the submission file.
Each record consists of the 146 fields as defined in Attachment II-B, Child File Record Layout. The total child record length is 312 characters. The record layout is the same for all records in the data file.
The data records in the file should be sorted in ascending order by the Child ID within the Report ID. This places the data records in a favorable order for processing.
1.1.6 Steps in Preparing the Child File
These are the suggested steps in preparing for the submission of the Child File.
Step 1—State Maps the Data
The first step for a State is to go through all of the data elements in the child record and define a mapping of the State data system into the NCANDS data elements. This mapping definition usually becomes a “technical specification” for obtaining data from the State data system and transforming that data into the NCANDS format.
Defining this mapping is best done through the combined efforts of representatives from the State Child Welfare programmatic staff, the State computer programming staff, and the NCANDS Technical Team. These people are very effective in mutually assisting each other in understanding what State data will satisfy the Child File fields and where those data values will come from in the State data system. The Technical Team can help the State staff to understand the definitions of the data. Close cooperation and consultation between these three areas of expertise will be of great value in achieving an accurate and timely conversion of State data into the NCANDS format.
Step 2—State Develops the Data Conversion System
The completed mapping definition from Step 1 represents the Functional Specification for the data conversion system. From this specification, the State computer programming staff writes the computer programs to export and convert the data from the State data system into the Child File.
Step 3—State Produces the Child File
The State executes the State Data Conversion System from Step 2 to produce the Child File for submission.
1.1.7 Child File Programming Considerations
The following information is provided for the State computer programming staff to assist in the development of the State Conversion system. The programming staff should refer to Attachment II-B, Child File Record Layout. Many of the conversion operations will be relatively straightforward. However, the topics listed below will require special programming attention.
The Child File is generated via the execution of a State prepared computer program, i.e., the State Data Conversion System, Step 2 above.
All field lengths in the child record should be strictly followed. The data being transmitted to the State are not delimited, and therefore, are character position sensitive.
Fields which are submitted with no data in them should be “blank”, containing the exact number of blanks to match the length of the field.
4. No Report ID, Child ID, Worker ID, Supervisor ID, Perpetrator ID, or AFCARS ID is to be transferred directly into the child record from the State system. These identifiers should be encrypted in some manner to protect the actual identity of the individual. The same encryption method should be used each year.
5. The State algorithm for generating the Report ID, Child ID, Worker ID, Supervisor ID, Perpetrator ID, and AFCARS ID may not deliver a full NCANDS length field. If this is the case, the identifier field should be “left-zero-filled” to provide the exact number of characters for the field.
6. The State Data Conversion System should adhere strictly to the State’s defined specification, Step 1 above. Deviations from the mapping specification could result in validation errors being generated as the data file is being processed by the NCANDS Technical Team.
7. The Child File should be sorted to put the child records in order by child within report.
2. SUBMITTING THE DATA FILES
This section provides instructions for submitting the Child File to NCANDS. It also explains how States may request technical assistance concerning any area of the NCANDS data submission preparation or process.
2.1 Data Submission Overview
A State may submit data to NCANDS either as a test data submission or as a final data submission for a given period. Both of these submission types have the same data format and both are reviewed via the NCANDS validation process to assure proper formatting and coding of the data fields in the submission. All data submissions should include only data with a Report Disposition Date occurring during the specified submission period.
Test data submissions are utilized by States who are new participants or by States who have gone through significant system changes at the State level, e.g., migration to a SACWIS type system, etc. It is recommended that the State submit the entire set of data for the reporting period for the test data submission. A subset of the total data set may optionally be submitted as a test. If a subset of data is submitted for test, the submission should include a mixture of both substantiated and unsubstantiated cases, with several hundred records of each type.
After the data are received, they are validated. As validation issues are detected in the data, Technical Team members designated by the Children’s Bureau will work closely with the State to identify and resolve the issues. When the major issues are all resolved, the last data submission represents the Final Data Submission for the reporting period. States with previous Child File experience and no computer system changes at the State level usually make only one data submission for a given reporting period.
Once the final data submission for a State has successfully completed the validation process and been accepted, the State data set is loaded into the NCANDS database.
2.2 Submitting Data to NCANDS
The sections below provide details for the submission of data from the State to NCANDS, including instructions for uploading data on the NCANDS Portal and data file labeling.
The method to be used by the State for submitting the Child File to the NCANDS Technical Team is through the State site on the NCANDS Portal. After the State has generated its Child File, the file is compressed prior to submission via a standard commercial data compression utility (e.g., WinZip, etc.).
To upload the data on the NCANDS Portal, follow these steps:
On the State site, click on the “Check Data Status” on the Data Collection toolbar.
Select the appropriate Year and Period of the data being submitted.
Click on the “Enter” button under the Child File section. This will navigate to the file upload page.
Click on the “Browse” button and select the data file.
Click on “Open.”
Click on the “Submit” button. If the data submission is successful the data submission status page will be displayed.
2.2.1 Data File Labeling
The State data submission should be named with the following naming convention:
State ID_DataYearChild_yyyymmdd.txt where the date represents the data extraction date (e.g. AZ_FFY2008Child_20090331.txt ). The compressed file should be named: State ID_DataYearChild_yyyymmdd.zip where the date represents the submission date (e.g., AZ_FFY2008Child_20090331.zip).
2.3 TECHNICAL ASSISTANCE
For technical assistance or questions concerning the preparation and submission of data, the State should contact:
John A. Gaudiosi, D.B.A.
Mathematical Statistician
Children's Bureau
Administration on Children, Youth and Families/ACF
U.S. Department of Health and Human Services
1250 Maryland Avenue SW, Rm 8116
Washington, DC 20024
202-205-8625
II.1.A-
| File Type | application/msword |
| File Title | Attachment |
| Author | Ying-Ying T. Yuan |
| Last Modified By | Ying-Ying Yuan |
| File Modified | 2009-07-23 |
| File Created | 2009-07-23 |