Overview

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.

Assessment Identity Changes (DATASTD-1214, DATASTD-1194, DATASTD-1117)

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 composite key values do not guarantee uniqueness.
• An individual key field may not be available for a particular assessment (e.g., a technically valid assessment can have no prescribed grade level).

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.

Increase Flexibility in Assessment Domain Model for Grade Levels and Subjects (DATASTD-1214, DATASTD-1199, DATASTD-1198, DATASTD-1197, DATASTD-1235)

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.

Introduce Grade Levels and Characteristics to All Levels of the Course Hierarchy (DATASTD-1259)

The Ed-Fi core data model has a multi-leveled hierarchy for courses:

• Course (a set of subject matter and planned outcomes for student learning).
• CourseOffering (a Course indexed to time / the course catalog).
• Section (an instance of a CourseOffering: students and teachers meeting at specific times and places to pursue a Course). 

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.

All Individual Changes

If the list does not appear, you can use this direct link to all changes.