0 a

National Child Abuse and Neglect Data System (NCANDS)

Attachment II-A_CF_AG Instruct_200604

National Child Abuse and Neglect Data System (NCANDS)

OMB: 0980-0229

Document [doc]
Download: doc | pdf


OMB No. 0980-0229

Expiration Date: ______________


Attachment II-A

Child File and Agency File Instructions


According to the Paperwork Reduction Act of 1995 (Public Law 104-13), the public reporting burden for information collection must be estimated. The collection of Agency File information is estimated to average 93 hours per response, including the time for reviewing instructions, gathering and maintaining the data needed, and reviewing the collection of information. An agency may not conduct or sponsor, and a person is not required to respond to, a collection of information unless it displays a currently valid OMB control number. Respondents may direct comments concerning this estimate to: John A. Gaudiosi, Mathematical Statistician, Children's Bureau, 1250 Maryland Avenue SW, Room 8116, Washington, DC 20024 (jgaudiosi@acf.hhs.gov)


1. PREPARING THE CHILD FILE AND AGENCY FILE DATA FILES


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. The Agency File contains State agency summary or other data, as required under the Child Abuse Prevention and Treatment Act [42 U.S.C. 5101 et seq.] (CAPTA). The data in this file cannot be derived from the case-level data. This attachment explains how the State creates and submits both of these data files to NCANDS.


States not able to submit the two data files will continue to submit only Summary Data Component (SDC) data, according to the instructions outlined in Attachment II-D, Summary Data Component (SDC) File Contents

.


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. Each submission period, the State submits this Child File, along with the Agency File. This 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 Type and Maltreatment Disposition Level 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.


Identifier Field

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 other identifier fields may be left blank.


Alphabetic Field

An alphabetic field only contains alphabetic characters. The field length would be exactly as specified in the record layout.


Alphanumeric Field

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.


Numeric Field

A numeric field only contains numeric characters. The field length would be exactly as specified in the record layout.


Date Field

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.


Blanks = not collected/not applicable

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.


  1. The Child File is generated via the execution of a State prepared computer program, i.e., the State Data Conversion System, Step 2 above.

  2. 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.

  3. 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.


1.2 Completing the Agency File


The Agency File is a pre-formatted file containing summary type questions. The State enters the appropriate answers directly into the pre-formatted file. Most of these data elements, submitted with the Child File, are required by CAPTA. The Agency File contains 28 data elements.


1.2.1 Overview of the Agency File


The Agency File consists of the following data areas:

  • Identifying Information, including State identification and year of submission;

  • State Comments about this year’s Data;

  • State Comments about each Data Element;

  • Preventive Service Counts, including a variety of elements containing counts with respect to State Grants, Community-Based Resources, title IV–B Services, Maternal and Child Health Block Grants, title XX Block Grants, and other preventive services;

  • Screened-Out Report Counts;

  • Out-of-Court Contact Counts;

  • Additional Child Fatality Counts; and

  • Child Protective Services Workforce Counts.


These areas of information are further described in Attachment II-C, Agency File.


1.2.2 Agency File Record Format


The Agency File collects two types of information: the data values representing the answers to the Agency questions and State supplied comments about the data. The State enters Agency information into a pre-formatted file. Once the data have been submitted, both the data values and the comments will be extracted from the Agency File, validated, and placed into an NCANDS database for analysis. The Agency File has the following characteristics and format:


  • There are 28 questions in the file, many of which apply toward satisfying the CAPTA requirements;

  • There is a General State Comments section for the State to enter comments about the State data in general;

  • There is a Comments about this year’s data section for the State to enter comments specifically about the data being submitted this year;

  • Each question is clearly stated;

  • Associated with each question is an adjacent empty field, provided for the State to enter the answer to the specific question;

  • Following each answer is a State Comment area, provided for the State to enter comments about the answer provided for the specific question;

  • All comments, either general or question-specific, are entered as free-form sentences;

  • The first few questions are for identification purposes in the file and allow for the entry of the State ID and the Submission Year; and

  • Except for the identifying data element records at the beginning, all of the data elements to be entered by the State are numeric counts or totals.


1.2.3 Types of Agency Data Entry


The State submits the data via an automated data collection tool. This Agency File should be transmitted to NCANDS at the same time as the Child File.


The General State Comments and the Comments about this year’s data are entered into the specified areas at the top of the table. The State’s answers to the questions are placed into the specified cells. Comments concerning the answer to a given question are entered into the row following the question.




2. SUBMITTING THE DATA FILES


This section provides instructions for submitting the Child File and the Agency File to NCANDS. It also explains how States may request technical assistance concerning any area of the NCANDS data submission preparation or process.


In the discussions below, the phrase “data submission” refers to the submission of both the Child File and the Agency File to NCANDS. These two data files are to be submitted at the same time.


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, the data from both the Child File and the Agency File will be 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 Child and Agency data files are submitted to NCANDS together. The sections below provide details for the submission of data from the State to NCANDS, including the transmission media contents, the media labeling, and the shipping instructions.





2.2.1 Transmission Media Contents


Several different data media types are accepted for a State’s submission of data, either test or full-year data. State data files, the Child File and the Agency File may be submitted to NCANDS in the format of either e-mail file attachments (for data files compressed to less than 2mb, via an available Web-based secure storage, or CD-ROM. For data files, the State may use commercial compression software to reduce the size of the transmitted files, such as WinZip.


      1. Data Media Labeling


If the data submission is made via e-mail, the Topic of the e-mail should be:

“State” Child File Data – Year yyyy”, e.g., “CA Child File Data – Year 2003.”


When data are submitted by the State on CD-ROM, the following information should be attached on an external label to each piece of the media.


  • Submitting State;

  • Data Period being Submitted;

  • Date of Data Submission;

  • Type of Data Submission (test or full); and

  • Media Item Count: __ of __.


When the data media are submitted, the State should include the following information in the transmittal letter or e-mail:


  • Name of the Agency submitting the data;

  • Agency’s full address; and

  • Contact person’s name, telephone number; fax number, and e-mail address.


2.2.3 Shipping Instructions


If the submission is mailed, it should be sent it to:

John A. Gaudiosi, D.B.A.

Mathematical Statistician

Children’s Bureau

1250 Maryland Avenue SW, Rm 8116

Washington, DC 20024


or to:


NCANDS Technical Team

Walter R. McDonald & Associates, Inc.

12300 Twinbrook Parkway, Suite 310

Rockville, MD 20852


If the submission is sent via e-mail, please call the NCANDS Technical Team at 301-881-2590 for the e-mail address.


It is recommended the State make a copy of the data submission files for safe keeping prior to shipping the data.


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

jgaudiosi@acf.hhs.gov

2

II-A.

File Typeapplication/msword
File TitleAttachment
AuthorYing-Ying T. Yuan
Last Modified ByMarty Rowland
File Modified2006-04-19
File Created2006-04-19

© 2024 OMB.report | Privacy Policy