Details
-
Improvement
-
Resolution: Done
-
Major
-
None
-
None
-
None
Description
Summary of outcomes for Data Standard 3.0
- Problem Addressed: Several properties on student are the 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). In practice, this has resulted in "data thrashing" as various LEA systems try to write different values. Additionally, it was determined that the DisplacementStatus property on Student was unnecessary and could be captured as part of the StudentCharacteristic common type.
- High-level Reasoning: By creating a new StudentEducationOrganizationAssociation and relocating the properties in question, student data may be collected in stored in the context of their relationship with a particular EducationOrganization, most commonly the LEA.
- Changes Made: The DisplacementStatus property was removed from Student and a value of "Displaced" was added to the StudentCharacteristic descriptor to capture this information. The existing StudentEducationOrganizationAssociation was renamed to StudentEducationOrganizationResponsibilityAssociation and continues to collect the same data as in the previous version. A new association was created called StudentEducationOrganizationAssociation (associating the Student and EducationOrganization entities) and included in the StudentEnrollment interchange and the StudentIdentificationAndDemographics and Enrollment domains. The following properties were relocated from Student to the new association:
- Disability
- EconomicDisadvantaged (later removed from the model all together)
- LimitedEnglishProficiency
- SchoolFoodServicesEligibility (later relocated to a new StudentProgramAssociation subclass)
Original ticket description follows:
Several properties on student are the 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). In practice, this has resulted in "data thrashing" as various LEA systems try to write different values. The goal is to look at modeling solutions.
Attachments
Issue Links
- is cloned by
-
DATASTD-1119 Investigate Bundling Subsets of Student Properties
- Closed
- relates to
-
DATASTD-973 Avoidance of 'data thrashing' on key /student resource data elements
- Closed
-
DATASTD-960 Add date history to Student domain entity
- Closed
-
DATASTD-961 Add date history to Staff domain entity
- Closed