Page Comparison

Contents

Student Characteristic vs Student Program Association

In the Ed-Fi Unified Data Model, student demographic data is generally found in the Student Identification and Demographics domain. There are 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.

Contents

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 Demographic Elements

Many core student demographic indicators are stored in the Student Education Organization Association and Student entities. A breakdown of these elements is as follows:

Modeling as Demographic or Program Data

A good indicator of whether or not a data point should be reported as a student demographic 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 should always 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 others data.