Student Identification and Demographics Domain - Best Practices

Contents

Purpose

In the Ed-Fi Unified Data Model, student demographic data is generally found in the Student Identification and Demographics domain as a well-defined attribute in the core model, as a Student Characteristic, or as a Student Indicator. There are also cases, particularly when a demographic indicator is closely associated with a program, where this information is stored in the Alternative and Supplemental Services domain, within student program association entities. The following is intended to clarify how to distinguish where this data should be stored.

Student Demographic Elements

Many core student demographic indicators are stored in the StudentEducationOrganizationAssociation and Student entities. These elements break down as follows:

Student Program Associations

Student program and program subclasses defined for federal education programs hold eligibility and participation status information for students. These entities break down as follows:

Student Characteristic vs Student Program Association

Student characteristics SHOULD NOT be used as proxies for program participation or eligibility indicators, as this duplicates data capture in the model and forces complexity onto downstream systems, who must look for data in multiple places.

As an example, if a student is eligible for participation in the federal food service program, this should be captured as a program association (StudentSchoolFoodServiceProgramAssociation with the ParticipationStatus set to "Eligible" or active status); this characteristic SHOULD NOT be captured as a independent characteristic (StudentCharacteristic) called "Food service eligible" (or similar value). 

However, if a demographic indicator is not-program specific, then it is appropriate to (systems SHOULD) capture the relationship on the StudentEducationOrganizationAssociation. In the above case, if a LEA had a student characteristic of "Economic Disadvantaged" that was distinct from the federal food service participation, then it is appropriate to capture this as a StudentCharacteristic on StudentEducationOrganizationAssociation.

Student Characteristic vs Student Indicator

StudentCharacteristic is a descriptor, limiting the data stored here to pre-defined option sets, with each option being a boolean / binary option.

Student characteristics have an optional array, Period, to define BeginDate and EndDate values. Characteristics are intended to have a "true/false" status where if a student has a StudentCharacteristic defined, it is considered true or active. If a characteristic is not present on a student record, then it is considered false or not applicable to the student. If a student is a part of a single parent household, this is a true/false state of "Single Parent" and works well as a StudentCharacteristic.

StudentIndicator is a key-value store intended to store student metrics - calculated values or values that are non-boolean in nature. The IndicatorName defines the measure and the Indicator holds the value for that measure. Indicators may be grouped and also have an optional array Period to define BeginDate and EndDate values. A metric like "Home Internet Access" works well here, where more open-ended values like "Broadband", "DSL", "Dial-up", "Cellular service", or "No internet access" may apply.

Modeling as an Attribute, Student Characteristic, Student Indicator, or Program Data

A good indicator of whether or not a data point should be reported as a student demographic attribute, student characteristic, or as a student program is whether or not the student is evaluated for services based on the data point.

For example, "Homeless" is both a Student Characteristic descriptor value, a Program Type descriptor value, and a Student Program Association subclass, Student Homeless Program Association. In this case, if the student is evaluated for services around the homeless demographic, then the data should be reported as either a Student Program Association or Student Homeless Program Association. The former is for a State or Local program and the latter is specifically for the federally reported McKinney-Vento Homeless program.

General guidelines can be summarized as follows:

Disabilities Special Case

In the field, it is common for student disability data to be managed by both a student information system (SIS) and a Special Education (SPED) application. In this case, the SIS should usually default to recording the disability data in the StudentEducationOrganizationAssociation Disability elements, and the SPED application should default to recording the disability data in the StudentSpecialEducationProgramAssociation Disability elements. This reflects that the SIS indicator is usually an overall, district-wide indicator used across programs and academics, while the program data captured is formally connected with the SPED program. This also prevents the two systems from over-writing each other's data.