Investigate Bundling Subsets of Student Properties

Summary of outcomes for Data Standard 3.0

• Problem Addressed: StudentIndicator and StudentCharacteristic have been determined to be captured as a result of evaluation processes by LEAs, and therefore are subject to change, and subject to having different values if the student is enrolled at more than one LEA (e.g. if the student transfers or is dual-enrolled). Additionally, it was determined that the EconomicDisadvantaged property (formerly on Student and moved to StudentEducationOrganizationAssociation in DATASTD-1086) was unnecessary and could be captured as part of the StudentCharacteristic common type.
• High-level Reasoning: By relocating the properties in question, student data may be collected and stored in the context of their relationship with a particular EducationOrganization, most commonly the LEA.
• Changes Made: The EconomicDisadvantaged property was removed from StudentEducationOrganizationAssociation and a value of "Economic Disadvantaged" was added to the StudentCharacteristic descriptor to capture this information. StudentIndicator and StudentCharacteristic were relocated from Student to StudentEducationOrganizationAssociation.

Original ticket description follows:
The Student domain entity contains many first-level entities, many of which change or are updated at different rates. When evaluating the ability to provide date history of different Student elements, it may make sense to group properties together based on the nature of the element and the pace at which the underlying data may change or require update.