ED-FI RFC 22 - ASSESSMENT OUTCOMES API
- Eric Jansson
- Stephen Fuqua
- Ian Christopher (Deactivated)
- Miguel Kaminski
This space has not been actively maintained for the past few years and some of the content may be outdated. The Ed-Fi Alliance is actively working to revamp the content over the course of the next few months. Please reach out to us if you have any questions in the meantime and we will try to help clarify and/or expedite updates to particular RFC documents.
This document refers to Ed-Fi Data Standard v3.2, which has since been replaced by Ed-Fi Data Standard v4 and Ed-Fi Data Standard v5, both of which are actively supported.
Ed-Fi Request for Comment 22: Assessment Outcomes API
Products: Ed-Fi Data Standard v3.2a
Affects: Ed-Fi ODS / API, RFC 21
Obsoletes: --
Obsoleted By: --
Status: Active
Ed-Fi Alliance
October 25, 2019
Contents
Overview
This RFC proposes a set of changes to the data exchange models covered in ED-FI RFC 21 - ASSESSMENT OUTCOMES API. The proposed changes are the result of ongoing field work operationalizing the data exchange structures in RFC 21, and seek to expand the data elements or make other changes necessary to support use cases around the exchange of data for domains common to student information systems.
The changes proposed in this RFC are intended to be non-breaking to most API clients. "Non-breaking" in this context generally means that data model changes are additive and optional, datatypes are generalized or field lengths are expanded. However, any change to a data model is potentially breaking given the specific API client behavior, so all API users are cautioned to review the changes carefully.
In order to help make the RFC non-breaking, the RFC also proposes deprecation of data model elements. Deprecation communicates that a data element or other API behavior is intended for removal in a future release, and likely in the next major release. Deprecation is therefore a recommendation to avoid use of certain data fields or features. Deprecation may be accompanied by information listing alternative or preferred options.
This RFC introduces two new use cases into the current domain design.
Social Emotional Learning
The RFC introduces elements to allow the capture of social emotional learning outcomes. These additions necessary are not extensive, but with them the domain model is believed to be usable to capture the most common outputs of K–12 SEL work. An exemplar use case is as follows:
Use Case
A school district desires to capture the results of its social emotional learning (SEL) program in order to combine that information with other performance data points also available for the student. The data is intended to be useful at both a classroom and building or higher administrative level, and therefore includes both the outcomes of the student's engagements with SEL classroom activities (including surveys or assessment instruments) as well as outcome metrics that represent overall student performance over time against a district-adopted rubric.
Learning Standards Mapping
The RFC introduces the capability of mapping learning standard to other learning standards, in relations of equivalence (including partial equivalence).
Use Case
An education agency has academic outcomes indexed to several standards, including state standards and district adopted standards, which are often closely related to or elaborations of state standards. In addition, some content is indexed to third-party standards, such as standards issued by non-profits engaged in specific disciplinary areas.
In addition, some educational outcomes in the district are only indexed to Common Core standards. The district needs the ability to define relationships between these outcomes so that assessment and other academic results for individual students can be compared across these different systems.
Major Changes
Major changes proposed are listed below, as changes to the underlying Ed-Fi Unified Data Model. A list of all proposed changes can be found below this section.
Addition of All Assessment Item Responses to Assessment Item (DATASTD-1365)
The assessment domain model currently only captures the correct response to an assessment item, but does not enable the capture of other possible responses (e.g., the incorrect responses on a multiple choice question). This prevents the teacher (or other user) from seeing the range of possible choices the user was choosing from, which can be valuable — and sometimes critical — in the interpretation of results. In particular, this functionality is important if the organization is attempting to capture survey-type data (e.g., Likert responses) in the assessment model.
Note: while the practice of using the assessment domain for survey data is not necessarily recommended (as surveys often have different properties than assessments), community discussion (via the Assessment Work Group (AWG) and Technical Advisory Group) have established that there may be cases where such capture is warranted (such as when a survey instrument is strongly tied to a social-emotional learning (SEL) assessment of the student).
This capability is important to the Social Emotional Learning use cases as put forth by the AWG.
Addition of Equivalence Associations Between Learning Standards (DATASTD-1366)
As identified by the Assessment Work Group, some education agencies seek to allow learning standards to be "mapped" to other learning standards, in relations of equivalence.
This is designed to solve confusion created by the co-existence of several sets of "canonical" overlapping standards at the local level, such as state standards, local standards, and Common Core State Standards. Allowing the assertion of relations of equivalence is important to agencies trying to draw conclusions about student performance by using assessment outcome indicators that are indexed to different standards.
The proposed change adds a LearningStandardEquivalenceAssociation to the model, to indicate a directed association of equivalence. A descriptor is proposed as a means to capture the strength of the mapping (e.g., “Equivalent”, “Partially equivalent”).
Deprecation of Learning Objective (DATASTD-1229)
The Ed-Fi Unifying Data Model currently has 2 abstractions that capture the concept of academic standards: LearningStandards and LearningObjectives. These abstractions were originally created to capture concepts related to scope and granularity.
However, in field work these entities have been used in nearly identical ways, and little value has been seen in having two separate abstractions. In fact, the existence of two separate abstractions has resulted in significant issues:
- It confuses those who govern academic standards as to which entity to choose (e.g., does a technology provider with national reach provide their rubric as objectives or standards?)
- It results in extra work at a local level to generate analytics, as local code must now account for two abstractions
The proposed direction is to deprecate LearningObjective and instead use the namespace to signal ownership. In addition, a “LearningStandardScope” field on LearningStandard will be added to clarify scope, for cases where the namespace itself may not serve as an obvious indication of scope.
Addition and Removal of New Enumeration Values to Standardize Options Sets and Usage (DATASTD-936, DATASTD-1275, DATASTD-1278)
There is ongoing interest in the community collaborating on standardized option sets (enumeration values), particularly from technology providers who see value in being able to consistently map internal values to community-defined and understood values.
Accordingly, a few additions and changes are proposed to existing descriptor sets. In the case of AssessmentItemCategory and AssessmentItemResult a new value is proposed for each respective list, based on current field work.
In the case of AssessmentReportingMethodType, some existing default values are deprecated. This particular descriptor is not one that is anticipated to be standardize-able in all cases, as there are infinite possibilities for provider (or other organization) specific values that represent different algorithmic approaches or definition variations.
In this case, the deprecation of certain values is intended to communicate that technology and solution providers are expected to assert their own values, and so such values should not be in the “ed-fi.org” namespace (as all Ed-Fi default descriptor values are). Accordingly, provider-specific values from the default list are deprecated.
Removal of Redundant Indicator Performance Level Met (DATASTD-1271)
The existence of a PerformanceLevelMet indicator in the assessment model is duplicative (i.e., adds no new semantics) and creates a possibility for the core model to have data that is inconsistent with itself (a record could describe that a student both met and did not meet a particular benchmark). Accordingly, this element is deprecated, both as an entity in the model and in its usage on PerformanceLevel.
All Individual Changes
All individual changes are available in this Tracker report.