Ed-Fi Request for Comment 27 Part C: Assessment Model Changes
Product: Ed-Fi-Sponsored Standard
Affects: Ed-Fi Resources API
Obsoletes: --
Obsoleted By: --
Status: done

Ed-Fi Alliance
September 12, 2025;

Synopsis

This Request for Comments (RFC) includes materials that describe proposed additions and revisions to the Ed-Fi Data Standard. This draft material is intended to support review and comment as well as support early usage; users of this material are advised that this work is still under development.

RFC 27 Part C describes updates to the Assessment data model that will normalize practices across vendors and reduce ambiguity for integrations with the Ed-Fi Data Standard. These enhancements incorporate the following changes:

1. Assessment domain entity

   1. AcademicSubject is now a single descriptor instead of a collection

2. ObjectiveAssessment domain entity

   1. ParentObjectiveAssessment is now a collection instead of a single field

3. StudentAssessment domain entity

   1. SchoolYear is now required, not optional

   2. WhenAssessedGradeLevel, new field

   3. StudentAssessmentIndicator, new collection

Contents

Overview/General Discussion

These improvements are based on a proposal from Education Analytics, rooted in their work to integrate thirty assessments into the South Carolina state data collection. The Ed-Fi Alliance evaluated that proposal, compared to existing normative best practices, and (a) developed a small set of proposed changes to the Ed-Fi Data Standard and (b) identified opportunities for improving documentation and guidance on use of the Assessment domain. Before adopting the proposed changes, they were shared with the new Assessment Working Group and with national Assessment vendors in individual conversations. The final set of changes seeks to balance the sometimes-conflicting demands for clean data input and ease of use with data read back from the Ed-Fi API, for example to provide analytic insights.

Use Cases

Assessment Entity having multiple academic subjects

In the Ed-Fi Data Standard, the top-level assessment entity has a collection of academic subjects (required) instead of a single subject. This disrupts core analytics functions like filtering by subject, comparing vendor products by subjects, and analyzing trends. Subject-specific analysis is crucial for assessment data. Not including the academic subject in the key forces vendors to create a unique key structure for Ed-Fi Data Standard integrations. 

Proposed DS 6.0 change

• Require exactly one Academic Subject on each Assessment and make it part of the primary key.

• For cross‑subject composites (e.g., SAT/ACT composite), set the assessment’s subject to Composite (descriptor), with subject‑specific results captured as ObjectiveAssessments (each with its own AcademicSubject).

• Validation rule: Every StudentAssessment must be inferably linked to exactly one subject via its Assessment reference (and any objective results are subject‑scoped beneath it).

Rationale

• Allows consistent, tool-agnostic subject filtering and cross vendor comparisons by academic subject. 

• Eliminates per vendor mapping of assessment scores -> subjects. 

• Removes ambiguity and divergence.

Design Option 1 – No key change, make Academic Subject as a single attribute - ACCEPTED

Design Option 2 – Key change, make Academic Subject as part of identity - REJECTED

The following diagrams provide a visual aid to understanding the scope of the problem:

Open

Open

Problem 2 – StudentAssessment.SchoolYear should be REQUIRED

Optional School Year allows inconsistent population, complicating longitudinal analysis, cohort inclusion, accountability snapshots and CCR and CCMR pipelines. 

Proposed DS 6.0 change

• Make SchoolYear a required property on StudentAssessment (or on StudentAssessmentEducationOrganizationAssociation if that’s the canonical ownership point), with a clear definition: the academic year of record for the assessment administration.

Rationale

• Ensures consistent data for analysis and reporting. 

• Where summer administrations straddle years, guidance clarifies alignment (e.g., associate to the year containing the majority of the academic term of record or per state policy).

Design - ACCEPTED

Problem 3 – Link an objective assessment to many parent objective assessments

Some assessments compute composite domains that legitimately belong under multiple parents (e.g., language domains that roll up into both Literacy and Oral Language). Current 1‑parent modeling forces duplication or loss of relationships.

Proposed DS 6.0 change

• Make ObjectiveAssessment.ParentObjectiveAssessment from Optional to Optional Collection

• This is a non-breaking change. 

Rationale

• Ensures accurate roll-up logic and UI grouping. 

• Faithfully represents vendor scorebooks (ACCESS and CogAT) without denormalized duplication. 

Design - ACCEPTED

Problem 4 – Rename WhenAssessedGradeLevel -> AssessedGradeLevel in StudentAssessment

The current name whenAssessedGradeLevel causes confusion between enrolled and tested grades, leading to misclassified records and broken trend lines. Renaming it to assessedGradeLevel clarifies that it refers to the grade level for which the test was designed and administered. The enrolled grade will still be available through roster data.

Proposed DS 6.0 change

• Rename the property to assessedGradeLevel with the definition: ‘The grade level for which the test form was assessed for the student on this administration’ - REJECTED

Rationale

• Improves semantic clarity and aligns to analysis needs; enrolled grade remains available via roster.

• Certain vendors need to maintain WhenAssessedGradeLevel at the StudentAssessment level.

New Design - ACCEPTED

• Revised based on community feedback: add the new field without removing the old one. Supports reporting both fields

Problem 5 – Add StudentAssessmentIndicator[] to StudentAssessment

Vendors deliver non-score attributes without a proper place to store them in the current Assessment model. This leads to the misuse of non-score flags as scores or packed into descriptor lists that were not intended for reporting methods. 

Examples – At Risk

Proposed DS 6.0 change

• StudentAssessment.StudentAssessmentIndicator - new optional collection

Rationale

• This cleanly separates scores from vendor-specific context and removes the need to misuse assessmentReportingMethodDescriptors or scoreResults for non-score flags.

Design - ACCEPTED

The following shows the item-level definition of an indicator:

Feedback

Please contact @Maria Ragone via e-mail or using Ed-Fi’s Slack subscription to provide feedback on this RFC.