OMB No. 0970-0424
Expiration Date: XX/XX/XXXX
The Paperwork Reduction Act Statement: The described collection of information is voluntary and will be used to inform the annual Child Maltreatment Report by providing specific data about children who have been maltreated. Public reporting burden for this collection of information is estimated to average 42.6 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. The OMB number and expiration date for the described collection are OMB #: 0970-0424, Exp: XX/XX/XXXX. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden to Cara Kelly; cara.kelly@acf.hhs.gov.
SPECIFICATIONS FOR CREATING THE CHILD FILE
The Child File contains records of case-level data on children (victims and nonvictims) who are the subject of a report of alleged child abuse or neglect. The Child File consists of child records, each record having the same format. Each child record contains information about only one child, and information about the associated abuse report. For each child record, there are numerous data elements grouped into various data categories (e.g., all child demographics are grouped into the Child Data section).
Although not a requirement, states are encouraged to sort the Child File by report ID then child ID before submission. This sort places the report IDs in order and all children with the same report would appear sequentially. This simplifies the process of viewing records in the original file, if needed.
This section explains how the state creates the Child File. This includes describing 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. For each submission period, the state submits the Child File, the Agency File, and the state commentary.
The data collection year for a submission period follows the FFY, October 1 through September 30. All reports with a disposition date within that 12-month period are submitted.
Child
File Record
#
Report
ID
Child
ID
Each record contains significant information concerning the:
report
child
maltreatments
child and caregiver risk factors
services
staff data
perpetrators
additional fields
All records should be the same length, with the exact number of blank characters being used to replace any data fields where data are not available. Each of the records must conform to the record layout for the NCANDS Child File, where each field in the record layout has a fixed length, as defined in the Child File Record Layout. There should be a delimiter, a carriage return (CR) and line feed (LF), at the end of each record.
The Child File is a “text” file, also referred to as an American Standard Code for Information Interchange (ASCII) file.
Because a child may appear in more than one report it is necessary to associate the child with all of the reports in which that child appears. This is accomplished by having both the report ID and the child ID in each record. The combination of the report ID and the child ID together identifies a report-child pair (RC pair) and forms the unique primary key field of the Child File. The data associated with an RC pair represent all the information about the allegations concerning that child in this report.
A child record allows for recording up to four NCANDS maltreatment types. Each of the four maltreatment types has an associated maltreatment level as to whether the alleged maltreatments were: substantiated, indicated, alternative response (AR) victim, AR nonvictim, unsubstantiated, unsubstantiated due to intentionally false reporting, closed with no finding, or no alleged maltreatment.
Every record in the Child File represents a child who can be classified as a victim or a nonvictim for each RC-pair. The determination of whether a child is a victim or not is computed from the information in the record. A child may be a victim in one report and a nonvictim in another report. For any RC-pair, being a victim depends upon the four maltreatment levels linked to the four maltreatment types. A child is a victim in the RC-pair if any of the maltreatment level fields are coded as substantiated or indicated. If the maltreatment death field is coded “yes,” at least one maltreatment type must have an associated maltreatment level of substantiated or indicated. A child is classified as a victim or nonvictim based on only that child’s maltreatment levels, not other children in the same report, so a child can be classified as a victim in a report even when all the other children are classified as nonvictims.
Each report in the Child File has a report disposition. The report disposition is based on the lowest maltreatment level code value across all maltreatment levels in the report. A report, in which the lowest numeric (most severe) maltreatment level code value is 01-substantiated, is assigned a substantiated report disposition. A report, in which the lowest numeric maltreatment level code value is 02-indicated, is assigned an indicated report disposition.
This section discusses several important error conditions that a state should take steps to avoid. The error conditions include the following:
A child cannot be associated more than once with the same report. A child ID cannot be associated more than once with the same report ID. In other words, a Child File record cannot have the same combination of report ID-child ID as any other Child File record. If this condition occurs, all records with the same report ID-child ID are deleted during validation.
Investigation and assessment maltreatment levels are not allowed within a single report. If this error is detected, the entire report will be removed from the file. The maltreatment level of “No Alleged Maltreatment” can be used in either an investigation or assessment report.
All children in a report cannot have “no alleged maltreatments.” Some states investigate or assess all children in a family when there are allegations of maltreatment against one child, even if other children do not have allegations of maltreatment. These other children in a report can receive a code of No Alleged Maltreatment. When No Alleged Maltreatment is used, it is both a maltreatment type and a maltreatment level. If all children in a report have No Alleged Maltreatment, this is considered an error and the entire report is removed during validation. For additional information, reporting guidance, and validation rules about No Alleged Maltreatment, please see Technical Bulletin #13.
A perpetrator cannot have all perpetrator maltreatment fields coded as no. If this error is found, all data associated with that perpetrator in the specific record are deleted during validation. If the perpetrator is not positively linked to any of the maltreatments, the state should not provide perpetrator data.
All states are encouraged to submit high-quality data for all fields in the Child File. NCANDS data are a critical source of information for many publications, reports, and activities of the federal government, child welfare personnel, researchers, and others. Therefore, states should examine carefully the logic on all fields that are extracted from their state child welfare information systems. The value distribution reports found on the NCANDS Website are helpful tools in making these assessments. Data elements lacking sufficient quality or comprehensiveness should be further examined and the state should consider not reporting on that specific data element. The state should seek assistance from the NCANDS Technical Team via telephone or email as needed to identify and resolve problems.
There are fields required as part of a complete Child File. Additionally, the AFCARS ID field is required for the CFSR. Required fields are indicated on the mapping forms.
Field Number |
Long Name |
Short Name |
1 |
submission year |
SUBYR |
2 |
state territory |
STATERR |
3 |
report ID |
RPTID |
4 |
child ID |
CHID |
6 |
report date |
RPTDT |
9 |
report disposition |
RPTDISP |
10 |
report disposition date |
RPDISPDT |
26 |
maltreatment-1 type |
CHMAL1 |
27 |
maltreatment-1 disposition level |
MAL1LEV |
145 |
AFCARS ID |
AFCARSID |
The data in the Child File is validated within the NCANDS Website after uploading. There are rules which govern how this validation process is accomplished. With many of the validation rules, there are associated consequences if the application of the rule fails. An example of a rule is “A coded field must have a valid NCANDS code.” The associated consequence would be “The error will be logged and the field will be blanked.” These rules and consequences are defined in the mapping forms for the Child File. A complete, stand-alone set of the validation rules is also available as an appendix to the NCANDS Website User Guide.
There are several levels of consequences related to the validation rules. Minor consequences will involve noting the error and taking no action. At times, the error detected in the field will require the entire record to be dropped from the file. The most severe consequences will necessitate dropping all records associated with that Report ID from the file.
OVERVIEW OF THE CHILD FILE RECORD
The following file and record layout information is basic with respect to submitting the Child File:
The Child File is a single, flat text file with no relational data structure.
The file only consists of child records, each record referring to data associated with one child within a report.
A child record is uniquely defined by the linking of the report ID of the record to the Child ID of the record. This is commonly referred to as the report-child pair, the RC pair, or the event, where a unique RC pair represents a single child record in the submission file. a child may appear in multiple reports.
Each record consists of the 152 fields as defined in the Child File data elements list. The total child record length is 338 characters. The record layout is the same for all records in the data file.
The delimiter, a carriage return (CR) or a line feed (LF), should be inserted at the end of each record for the data file to be read by the Validation Program.
There are currently 152 fields in the Child File. If a state is unable to report on these fields, blanks should be submitted in the Child File.
Each 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 the data elements in the record are grouped into these data sections, including:
Report Data (characteristics)
Child Data (demographics)
Maltreatment Data
Child Risk Factors
Caregiver Risk Factors
Services Provided (to the child/family)
Staff Data
Perpetrator Data (demographics, maltreatment data)
Additional Fields
The state should always submit data for all appropriate data sections (fields 1–87, 145–152). Data for the Perpetrators section (fields 88–144) should be submitted only if the child in the record is a substantiated or indicated victim. A complete list of the data elements within these categories can be found in the Child and Agency Data Element Lists.
The Report Data section contains the two identifying fields (submission year and state ID) and general information about the report. The first identifying field for the record is the report ID. The second identifying field for the record is the Child ID. All remaining fields in the Report Data section are attributes related to the report ID.
If a report involves multiple children, the Report Data fields, except for the child ID, are identical on each record containing the same report ID. For example, if there were three children in the report, the data in the entire Report Data section would be identical for all three child records, except for the three different child IDs.
The Child Data section contains general information about the specific child in the record. All fields in this section are attributes related to the child ID.
The fields in the Maltreatment Data section include information about maltreatment types and maltreatment disposition levels. Up to four allegations of maltreatment are coded with the decision regarding the allegation. The Maltreatment Death field is also included in this section. If the maltreatment death field is coded “yes,” at least one maltreatment type must have an associated maltreatment level of substantiated or indicated.
The fields in the Child Risk Factors section indicate whether the child suffered from one or more disabilities or problems.
The fields in the Caregiver Risk Factors section indicate whether the child's family or caregiver(s) suffered from one or more disabilities or problems. Additional family or caregiver fields in this section include information on the living environment of the child, which might affect the child or place the child at-risk for maltreatment.
The fields in the Services Data section contain information about postresponse services, which are provided for the child or family. A service must continue after the report disposition date to be counted
as a postresponse service. A service can start at any time prior to the report disposition date provided it is associated with the CPS response. Exhibit 3 Allowable Service Patterns demonstrates critical timelines associated with service delivery. NCANDS Technical Team Liaisons are available to provide additional assistance with understanding allowable service patterns in the Child File.
Report
Date
Report
Disposition Date
90
Days
After
Disposition Date
There are three foster care related fields: foster care services, removal date, and foster care discharge date. All three fields are used to determine if a child received foster care services related to the CPS response. Because foster care is a postresponse service, it must follow the same rules as other postresponse services. See Exhibit 3, Allowable Service Patterns.
The removal date indicates whether the foster care service is related to the current CPS response. If a child was removed from home prior to the current CPS response (already in care), the date of the most recent removal should be reported. If a child has been removed more than once, related to the current CPS response, the removal date is the most recent removal resulting from this CPS response. It may be the same as the report date or shortly after.
It is important to note that there are separate sets of rules regarding foster care removal dates. For purposes of validation, removal dates prior to the report date are accepted. However, only records with removal dates occurring between the report date and 90 days after the report disposition date are included when reporting the number of victims and nonvictims removed from the home because of the investigation in the Child Maltreatment report. See Exhibit 4 Allowable Removal Date Patterns for Analysis.
Arrows are removal dates.
Report
Date
Disposition
Date
Disposition
Date
+ 90
Days
The foster care discharge date must occur after the foster care removal date and is used to confirm that the foster care service continued past the report disposition date. Exhibit 5, Allowable Discharge Dates Patterns demonstrates critical timelines associated with foster care discharge dates. The green line indicates acceptable foster care discharge dates. When foster care discharge dates occur along the red lines, the NCANDS Website blanks the three foster care fields (foster care service, removal date, discharge date). If the child was not discharged from foster care, the removal date should contain a valid date and the foster care discharge field will be blank.
Report Date
Removal Date
Report Disposition Date
Foster Care Services with discharge dates on the green line are allowed in the Child File. Foster Care Services with discharge dates on the red lines are not allowed in the Child File.Staff Data
The fields in the Staff Data section (fields 86–87) contain identification information about the CPS worker and the CPS worker's supervisor who were associated with the child on the date of the report disposition.
Perpetrator Data
The fields in the Perpetrator Data section (fields 88–144) allow for the submission of information on a maximum of three persons who are found to be perpetrators of maltreatment. If the child was not found to be a substantiated or indicated victim of maltreatment, the Perpetrator Data section is left blank. The four perpetrator maltreatment fields for each perpetrator should be linked by the state to the four sets of maltreatment type and maltreatment disposition level fields reported for the child victim (fields 26–33).
The Child File record layout is periodically revised. As new fields are added, they are appended to the end of the Child File in the Additional Fields section. When current fields are modified, new code values are added without adjusting existing code values. Please refer to the mapping forms for these fields for more detailed information and instruction.
The Justice for Victims of Trafficking Act of 2015 includes an amendment to Child Abuse Prevention and Treatment Act (CAPTA) to collect data about victims of sex trafficking. As of FFY 2018, the Child File was revised, by adding a new maltreatment type code, 7-sex trafficking, to all four maltreatment type fields (fields 26, 28, 30, and 32). NCANDS also changed validation and data quality rules to allow states to report victims and nonvictims of sex trafficking under 24 years old. States that can report labor trafficking should use code 8-other and add a statement in State Commentary.
The Comprehensive Addiction and Recovery Act (CARA) of 2016 includes amendments to CAPTA to collect data about infants with prenatal substance exposure (IPSE). As of FFY 2018, NCANDS uses three existing fields to identify these infants, an infant must meet all three conditions to be counted as an IPSE:
Field 8, report source: 02 = medical personnel
Field 12, age: 00 = age <1 year old
Fields 35, 36, child risk factor alcohol abuse and/or or drug abuse: 1 = yes
As of FFY 2018, two fields were added to the Child File to collect additional data about IPSE:
Field 151 Has a plan of safe care: to collect the number of IPSE who also have a plan of safe care. This field is a subset of the total number of IPSE.
Field 152, Referral to appropriate services: to collect the number of IPSE who also have a referral to appropriate services. This field is a subset of the total number of IPSE. The plan of safe care and referral to services may be created at any point during an investigation or assessment and are not postresponse services. More information can be found in Technical Bulletin # 12_REVISED and the mapping forms for these fields.
THE IMPORTANCE OF UNIQUE IDENTIFIERS
Unique identifiers provide the ability to specifically identify a report, child, worker, supervisor, or perpetrator via an identifier field. The Children’s Bureau uses unique identifiers for identifying repeat children for the CFSR. Additionally, most analyses in the Child Maltreatment report are computed using unique identifiers. The identifier fields are:
report ID
child ID
worker ID
supervisor ID
perpetrator ID
AFCARS ID
The following basic concepts are applied to the use and assignment of unique identifiers, regardless of the field:
The same report (child, perpetrator, etc.) is never assigned an additional identifier, causing multiple identifiers.
The same identifier is never assigned to a different report (child, perpetrator, etc.), causing shared identifiers.
Other key concepts are:
The report identifier should be the same for all child records 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 the child records that are part of the same report. However, a given child identifier should only be associated once with a specific report ID.
The combination of the Report ID and Child ID form a unique identifier for a child in a report. This combination is referred to as the Report Child Pair and should not be duplicated within the submission year or across submission years.
If a worker or supervisor changes roles (e.g., from a worker to a supervisor), the person should retain the originally assigned identifier.
A unique perpetrator identifier might occur in any one of the three perpetrator ID fields in a record. The same perpetrator might be identified by perpetrator-1 ID in one record and perpetrator-2 ID or perpetrator-3 ID in another record but must maintain the same identifier in each instance. However, a perpetrator identifier should only appear once within a single child record.
The AFCARS ID is assigned to only one specific child. The child is never assigned an additional AFCARS ID and the same AFCARS ID is never assigned to another child. If the same child is involved in multiple reports, the child should be assigned the same AFCARS ID for all those reports.
Encryption is a process that changes (encodes) data from the original state into an “encrypted” state. The purpose of encryption is to prevent unauthorized persons from seeing or deriving the original data that were encrypted. The opposite process of encryption is “decryption.” This process allows the encrypted data to be “un-encrypted” back into its original state. This decryption is used to retrieve the original data from the encrypted state.
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 must be applied by the state to all identification fields within the Child File. Appropriate identifier encryption means that no one would be able to identify a person because of seeing the identifier. Care must be taken that the encryption methodology used to encrypt the NCANDS AFCARS ID field is the same methodology that
is used for the record number in the AFCARS File. It is also important for the state to completely and privately document its identifier encryption and decryption methodologies. At times it is necessary for a state to decrypt an identifier to determine the source of a validation error. The same encryption methodology should be used year after year for data submissions to ensure ID integrity across years for purposes of analysis.
As part of the NCANDS annual data collection process, states are asked to verify that their data are sufficiently encrypted. However, some states are not able to verify that the data meet encryption guidelines. To protect confidentiality and make all states’ data available to researchers, a double- encryption process is applied to all records in approved data submissions to systematically de-identify the unique identifiers associated with the report, child, perpetrator, worker, and supervisor. This process ensures data security and allows researchers to conduct analyses across years. The encryption certificate should be submitted at the time of the FFY 2019 Child File data submission and is kept on file and referenced when the accepted Child File data are sent to the National Data Archive on Child Abuse and Neglect (NDACAN).
Encryption certificates are requested any time a Child File from a prior year is submitted. Please contact your NCANDS state Liaison for an encryption certificate template for resubmissions.
States needing assistance with encryption methodology should contact the Federal Regional Office or the Children's Bureau for further information.
Many state CPS units are developing differential responses to referrals received from mandated and other reporters. Some states focus on providing services to screened-out referrals, while others are developing alternatives to investigations as their response to a screened-in referral. In NCANDS, counts of screened- out referrals are reported in the Agency File. They are not reported in the Child File.
States report screened-in referral data to NCANDS in the Child File for both types of responses— investigation response (IR) and alternative response (AR). NCANDS uses AR as a generic term referring to a CPS response to screened-in referrals, which may have different procedural and conclusory elements from an IR. States may use the term differential response, family assessment response, or non- investigation response for what is called AR in NCANDS. For NCANDS reporting purposes, states are given the option of using report dispositions and maltreatment levels of AR victim and AR nonvictim. (States are asked to provide specifics on AR programs in commentary.)
To bring NCANDS in line with child welfare practice and federal performance outcomes, as of 2015 NCANDS no longer includes AR victim dispositions in the victim counts.
Certain Child File data fields require additional guidance as they apply to an alternative response. These terms and their usage for AR are listed below.
Report date: In AR, this is the date that the referral was received by CPS. It does not refer to a decision to screen in or screen out, or a decision to investigate or provide AR.
Investigation start date: In AR, this date refers to the first face-to-face contact with a child in the family who receives a response from CPS. If this face-to-face contact is not possible, the date would be when CPS initially contacted any party who could provide information essential to the assessment.
Report disposition: In AR, there is no disposition per se, so this field is used to indicate that the report received an AR (victim or nonvictim). The report disposition should be AR victim if at least one child in the report had an AR victim maltreatment level, otherwise it should be AR nonvictim. A report with an AR disposition should only contain records with AR maltreatment levels. The maltreatment disposition of no alleged maltreatment can be used in either IR or AR reports.
Report disposition date: In AR, this field refers to the point in time at the end of the assessment when a CPS worker makes a final determination (disposition) about whether the alleged maltreatment occurred.
Maltreatment levels: It is important to note that the maltreatment levels must all be related to either IR or AR. A single record cannot contain both IR and AR maltreatment levels and a single report cannot have multiple records where one record has IR maltreatment levels and another record has AR maltreatment levels. If a family receives both IR and AR, two different reports need to be included in the Child File. The maltreatment level of no alleged maltreatment is only used when at least one other child in the report is investigated or assessed.
Perpetrator: Children in an AR are not associated with perpetrator data.
Postresponse services: In AR, this field flags whether the family or a child receives services after the completion of the CPS response. This may be through a referral to ongoing services, foster care services, etc. The service may have started either before or during the provision of the CPS response but must continue past the report disposition date to be flagged in this field. All service fields are linked to this concept of postresponse or post completion of a response.
Service date: In AR, this field refers to the start of services because of the CPS response. This date has many options as it could be before the start of the CPS response, during the CPS response, or after the completion of the CPS response. If all services were completed before the end of the CPS response, the postresponse service field would be no; there would be no date under service date; and no services flagged in the service fields.
The following information is provided for the state IT staff to assist in the development of the state Child File Data Extraction Program. The IT staff should refer to Child File Record Layout . Although many of the conversion operations will be relatively straightforward, the following eight topics will require special programming attention:
The Child File is generated via the execution of the state-prepared computer program, typically designed from the state completed Child File mapping forms.
The Child File is a fixed-length record file. All field and record lengths in this file must be strictly followed to avoid data loss. The column positions of each field in the child record must be strictly followed. The data submitted by the state are delimited. A delimiter is inserted after column 338 in each record.
Fields being submitted with no data in them should always contain blank information, containing the exact number of blanks to match the length of the field.
Special care must be taken with the AFCARS ID field. For a child, the value that is placed into the NCANDS AFCARS ID field must be the same value that the state uses or would use for the Record Number field in the AFCARS File for that specific child. The AFCARS ID field must be encrypted using the AFCARS Encryption Tool with the same encryption algorithm as is used for
the Record Number field in the state AFCARS file. The state may find it beneficial to utilize the AFCARS Encryption Tool for all encryption needs in the NCANDS record. Care should also be taken in all the encryption processing so the AFCARS ID is not double encrypted (an encryption of an encrypted ID).
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 database. These identifiers must be encrypted to protect the actual identity of the individual. The state should use the same encryption method consistently from year to year.
If the state algorithm for generating the report ID, child ID, worker ID, supervisor ID, perpetrator ID, or AFCARS ID does not deliver a full NCANDS length field, the identifier field should be left-filled with zeroes to provide the exact number of characters needed for the field.
The state Child File data extraction program should adhere strictly to the state's defined specification in the mapping forms. Deviations from the mapping specification could result in validation errors. The mapping forms list all error conditions associated with each specific field.
While it is not a requirement, it is a good policy to sort the Child File sequentially by RC pairs (i.e., child ID within report ID).
This section is directed to the state IT staff responsible for writing the data extraction program. One of the most difficult tasks in preparing the data extraction program is the proper selection of records for the Child File. Because state databases vary, data may be stored according to a variety of different data models across the states. These data models might focus upon storing data by event, by child profile, etc. Exhibit 6, Child Record Selection Tips, shows the high-level criteria needed to make the appropriate record selections for the Child File records.
|
|
|
Selected report has a report disposition |
|
Selected report has report disposition date in NCANDS submission year |
|
Selected child is a child within a selected report |
|
Selected child has a maltreatment disposition level |
|
Selected maltreatments are the four most significant maltreatments for a selected child |
|
Selected child risks are all indicated risks of selected child |
|
Selected caregivers are all caregivers of selected child |
|
Selected caregiver risks are all indicated caregiver risks of selected caregiver |
|
Selected services are all services to child or family provided according to exhibit 5–2 allowable service patterns |
|
Selected caseworker is most recent worker |
|
Selected supervisor is supervisor of most recent worker |
|
Selected perpetrators are perpetrators associated with the selected child where at least one child maltreatment disposition level is “substantiated,” or “indicated” |
|
Selected AFCARS ID of selected child |
|
Incident Date of selected child for selected report |
|
State has conducted the investigation or has been involved in the investigation, regardless of who has jurisdiction, e.g., tribal or military investigation |
This section contains examples to help the state further understand the general principles used for the construction of records in the Child File. The reader should review the general disposition information prior to studying this section.
Step 1: A report can pertain to more than one child. There is no limit to the number of children in each report.
Step 2: A child can be the subject of more than one report in the reporting period. This represents a child that is the subject of multiple allegations of abuse in the Child File over time. A child appears in a report as a single record.
Step 3: A child in a report can have up to four maltreatments. All maltreatments for a child must be of a different type. All of these maltreatments reside in a single record with the child. Each maltreatment type has its own maltreatment level, which is the disposition or finding associated with that specific maltreatment type.
Step 4: Up to three perpetrators can be reported per child in a report. A perpetrator cannot appear more than one time in a child record. For example, two Perpetrator B’s cannot occur in one child record. The three perpetrator data sections all reside in a single record with the child.
Step 5: A perpetrator can be associated with more than one report and more than one child in a report. The NCANDS Website will remove all perpetrator data if all perpetrator maltreatment fields are coded as no or use a combination of no and blank because this indicates the perpetrator was not responsible for any maltreatments. As seen above, no Perpetrator data should be submitted for records where the child has no maltreatment disposition level of substantiated or indicated. Additionally, no alleged perpetrator should be included in the record if it is known that the person is not associated with a substantiated or indicated maltreatment disposition level.
Step 6: For a child in a report, each substantiated maltreatment type, can be linked to a specific perpetrator through the perpetrator maltreatment fields. To link a perpetrator to a maltreatment, code the associated perpetrator maltreatment field to “yes.” For example, to link perpetrator 1 to maltreatment type 1, first check to see if maltreatment type 1 is substantiated or indicated. If it is, then code perpetrator 1 maltreatment 1 to “yes.” This can be repeated for each substantiated or indicated maltreatment and each perpetrator. In the figure below, the Perpetrator A is linked to substantiated maltreatments 1, 2, and 3, but is not linked to substantiated maltreatment 4. Code the perpetrator maltreatment fields for Perpetrator A to “1-yes” for substantiated maltreatments 1, 2, and 3, and “2-no” for substantiated maltreatment 4.
If a state wishes to use SPSS to analyze its state data, the output TXT file from the NCANDS Website first needs to be converted to SPSS format. Older versions of SPSS should be set in Unicode mode when running the conversion syntax This enables SPPS to better read special characters in the AFCARS ID field. Beginning with SPSS version 20, Unicode is the default language setting. To check if SPSS Statistics has Unicode (universal character set) selected:
Launch the application. Do not select any data.
Go to Edit>Options>Language, and in the Character Encoding for Data and Syntax box, “Unicode (universal character set)” should be selected.
When data files saved in CODE PAGE MODE (the default in prior versions) are read in SPSS with a UNICODE setting, the defined width of all string variables is tripled. If you are experiencing difficulties matching files, go into the variable view of each file and manually adjust the width of string fields so they match.
The NCANDS conversion syntax for FFY 2019 includes special encoding in the ‘DATA LIST’ command to better enable reading of the AFCARS ID field in the files used for the CFSR. This does not affect the SAV file created with this syntax. This syntax is named create_master_sav_fy2019_encoding.sps and is in the SPSS folder on the NCANDS Website under Resources>View Resources>Global.
File Type | application/vnd.openxmlformats-officedocument.wordprocessingml.document |
File Title | Microsoft Word - B-2.docx |
Author | adowner |
File Modified | 0000-00-00 |
File Created | 2023-07-29 |