Data Standard v3.1a introduces a limited set of breaking changes to the Data Standard v3.0 model in the Assessment domain and a small number of non-breaking changes in other core student information system domains. The changes with the most impact on field implementations are described below. Those working with assessment data integrations are advised to review all changes listed in the All Individual Changes section below.
A number of issues raised by implementers concern the composite key of the Assessment entity. The composite key in the Data Standard v3.0 is composed of 4 elements: AssessmentTitle, Version, GradeLevel and Subject. This key cascades into other domain entities including ObjectiveAssessment, AssessmentItem, and StudentAssessment.
This structure presents a few issues in field use:
The proposed v3.1a introduces a new key consisting of AssessmentIdentifier and Namespace. This key follows the "partial-key surrogate pattern" where a source system surrogate key (in this case, AssessmentIdentifier) is introduced and is scoped organizationally (in this case, by a vendor-specific Namespace). Based on implementer feedback, it appears that vendors most typically use UUIDs for the surrogate key.
The Data Standard v3.0 requires a grade level collection on the Assessment entity. Assessment providers note that assessments often do not target a particular grade level, but rather can be applicable to many grade levels. In addition, some assessments have no clear grade-level indexing (e.g., an IQ test). In accordance with this, GradeLevel is made an optional collection in Assessment in the proposed v3.1a.
Assessment providers also noted that assessments can cover multiple subject areas, so AcademicSubject was made into a required collection on Assessment.
Since learning objective metadata regarding grade level and subject behave similarly to that of the Assessment entity, the changes above were also made to the GradeLevel and AcademicSubject in the LearningObjective entity. On LearningStandard, GradeLevel was additionally converted from a required field into a required collection.
The Ed-Fi core data model has a multi-leveled hierarchy for courses:
Over time, we have seen that many characteristics can be assigned to any level of this hierarchy. For example, a Course could be designed as dual credit, or it could be offered as dual credit during a particular semester (i.e., as a CourseOffering). Or, in some circumstances, only a particular Section could be dual credit. The same is often true of grade-level indexing for course-data: it can occur at any level.
Accordingly, Course, CourseOffering, and Section are all made "parallel" with respect to these characteristics: with this change, each entity has an optional collection of CourseLevelCharacteristics and an optional collection of OfferedGradeLevels. Further, the definitions state that these properties should only be assigned at lower levels of the hierarchy if the values differ. This change introduces an "override" semantic into this part of the data model.
If the list does not appear, you can use this direct link to all changes.