Contents

Overview

Data Standard v5.0 is targeted at deployment starting in the 2024-25 school year. This final release version (v5.0.0) introduces important updates that impact multiple domains of the Ed-Fi data model. The domains impacted include:

• Alternative and Supplemental Services Domain with Federal Programs Subdomain
• Discipline Domain
• Enrollment Domain
• Graduation Domain
• Intervention Domain
• Student Academic Record Domain
• Student Attendance Domain
• Student Cohort Domain
• Student Identification and Demographics Domain
• Survey Domain
• Teaching and Learning Domain

These changes come from field feedback and are designed to help drive the community and community innovation forward. There are breaking changes in these domains, so implementers are advised to review the changes carefully.

Other areas of the model have received minor, non-breaking updates, and API bindings and implementations in those areas should continue to function as before. 

Major Changes

Adding Special Education Program Eligibility Association

State Education Agencies (SEA's) need to evaluate their efforts to implement the requirements of the Individuals with Disabilities Education Act of 2004 (IDEA 2004) and to include updates of their continuous improvement of the implementation through their Annual Performance Report submitted every year. In alignment with IDEA, states need to meet the two monitoring priorities identified by the US Department of Education/Office of Special Education Programs (ED/OSEP).

An Ed-Fi Special Interest Group (SIG) that focuses on Special Education (SpEd) discussed how to to capture the evaluation information. SEAs in this group agreed that they need to collect this information at a granular level and ruled out the option of extending the existing StudentSpecialEducationProgramAssociation entity. Both the Wisconsin Department of Public Instruction and the Texas Education Agency had created extensions to handle this type of data and that lead to the design of a new entity StudentSpecialEducationProgramEligibilityAssociation in Ed-Fi core model as presented with this release. 

This addition to the model allows states to collect data required for improvement and monitoring activities communicated to the Office of Special Education Program. The details about the entity and the elements that are included in this new association is as shown below.

More details can be found in the related ticket and the ED-FI WORKING DRAFT 8.

Updates on Special Education Program Association

Ed-Fi Alliance's collaborative work with the SEAs through and after the SpEd SIG has yielded a decision for adding three new optional attributes to the Student Special Education Program Association to allow the community members collect data for the program exit date of the student and the short and long explanation for the reason(s) of this exit. The additional attributes are listed below.

The SpecialEducationExitExplained attribute is designed to be used for data collection where the long explanation of reason(s) of student's exit from the Special Education program where SpecialEducationExitReason is designed as a descriptor to capture the short explanation/categorization of the exit reason. Ed-Fi Alliance listed seven predetermined categories for this descriptor and - as usual feature of descriptors in the model - left the adjustments of these categories to the community members for more specific and suitable usage of each educational agents. 

Adding Student Program Evaluation

A new model for the Student Program Evaluation data domain in the Ed-Fi data standard has been created to address multiple state agencies' needs to keep track of student program evaluation data. These needs mainly stems from the Early Child education program performance tracking of states Wisconsin, Minnesota and Indiana as well as the 21st CCLC programs implemented in Arizona. For these programs Ed-Fi community member states indicated that a student program evaluation model would provide them benefits in

• Demonstrating program effectiveness: Program evaluation data can be used to demonstrate the effectiveness of educational programs to stakeholders, including funders, accrediting bodies, and policymakers. The data can be used to show the impact of the program on student outcomes, such as graduation rates, academic performance, and career success.

• Improving student engagement and satisfaction: Student program evaluation data can provide insights into student engagement and satisfaction with the program. By using this data, educators can make changes to improve the student experience and increase engagement and satisfaction.

• Identifying areas of improvement: Student program evaluation data provides valuable insights into areas where programs are succeeding and where they need improvement. By analyzing the data, educators and administrators can identify specific areas that require attention and make changes to better serve their students.

• Ensuring accountability: Tracking program evaluation data can help ensure accountability for educational institutions and programs. By regularly collecting and analyzing data, educators and administrators can identify areas where they may not be meeting their goals and take action to address these issues.

The proposed domain model for the Student Program Evaluation data domain aims to capture the child outcomes indicator for early childhood evaluations as well as students' performance in programs. The model includes entities such as StudentProgramEvaluation, ProgramEvaluation, ProgramEvaluationObjective, ProgramEvaluationElement, EvaluationRubricDimension. These entities are related to each other to provide insights into the effectiveness of programs and help in making data-driven decisions. This model can also accommodate other evaluation types and can be extended to accommodate additional entities and relationships as needed.

More details can be found in the related ticket and the ED-FI WORKING DRAFT 12.

Section Model Updates

Section in the current model combines the aspects of scheduling of instruction in a course offering for students and teacher and students' attempted credits, grades and the responsible teacher/instructor they work with for that course offering.    

Diversity, Equity and Inclusion Related Updates

In 2022, Data Standard team along with some other members of the Ed-Fi technology team have received requests from the Ed-Fi community members for a discussion on a possible implementation of diversity, equity and inclusion (DEI) related topics and data collection. Following the prevalence assessment of the request, the Data Standard team established a DEI SIG based on Ed-Fi Governance policies so that the community members could guide the team through discussions in these group meetings on topics that are predetermined by Ed-Fi community members earlier or at these group meetings.

A group of Ed-Fi community members were invited to participate, including local and state education agencies as well as members of some research institutes and other organizations that have shown a previous interest on the topic. The Ed-Fi DEI SIG was initiated with its first meeting in February. The group has completed three meetings with an achievement of fruitful discussions and completion of all topics that were pointed before and during the existence of the group. It is decided that the group will give the Ed-Fi Data Standard a time to internally discuss the guidance provided at these meetings and have a meeting or two later based on this internal process and for the possible additional topics during that time.

Main topics discussed during DEI SIG meetings are as follow:

• Renaming the Parent domain entity in the Ed-Fi model to have more inclusive approach,
• Adding Preferred First Name and Preferred Last Name in Name common,
• Correcting the vocabulary confusions in the definition of Sex descriptor,
• Considering adding a Gender Identity attribute to the model,
• Considering to add Pronouns string in the model,
• Keeping up with the developments on Race and Ethnicity Standards by U.S. Office of Management and Budget Interagency Technical Working Group.

Data standard team have taken these recommendations from the DEI SIG members and made necessary model changes to reflect these recommendations on to the Data Standard model after another serious discussions internally and other members of the Ed-Fi community. Ed-Fi is proud to report that the DEI SIG has been a grate success with its reflections on the model.

Renaming Parent Domain Entity to Contact

The topic was discussed by the DEI SIG at its first meeting based on the Ed-Fi community members' recommendation at the Technical Congress of 2022. The group had the consensus at the meeting which suggested that the term Parent that is used for this domain entity is not inclusive despite the fact that in the field of education the term Parent can be used very liberally. Group discussed if responsible adult, caregiver or another alternative will be a better fit. After this discussion responsible adult was ruled out since it is not inclusive either and data standard team was given the option to have an internal discussion to choose between contact or caregiver. Considering the currently available ContactType descriptor, the Data Standard team rename the Parent domain entity as Contact and downstream that change by updating the name and definition of StudentParentAssociation, SurveyResponce domain entity and StudentIdentificationAndDemographics domain.

Adding Preferred First Name and Preferred Last Name to the Name Common

Another topic the Data Standard team picked up from the DEI SIG discussion and had a conclusion on was the adding the Preferred First Name and Preferred Last Name. The DEI SIG discussed multiple use cases from the safety concerns of the persona subject to the use of different first and/or last name to the personal preference of using an English version or alternative names because of the pronunciation difficulties of none English names. Data Standard team found the recommended addition trivial and the argument with use cases convincing and followed group's recommendation by adding these two field in the Name common.

Sex Descriptor Updates and Adding Gender Identity 

One of the longest conversations Data Standard team had with the community members with the guidance of the DEI SIG members was about the Sex descriptor and Gender Identity. As the result of theses conversation, Ed-Fi definition of the Sex descriptor and where it is collected has been updated and a new string variable to allow the community members to collect data on Gender Identity when they needed added to the core model with this release. More details about the issue can be tracked in the tickets attached here.

Removal of Previously Deprecated Elements

The Data Standard team has the tradition of marking an element that is subject to removal form the Ed-Fi model as "Deprecated" once an element of the model becomes obsolete based on newly introduce updates in the model. Deprecation notices are visible in handbooks and UML diagrams.

The purpose of the deprecation note is to inform the community members of intent to remove the element from the core model after giving the community members time for preparation. With this intend there has been numerous elements of the Ed-Fi model that have been marked as deprecated, but not removed.

The Data Standard team conducted an assessment to find these elements in the model where their removal was recommended and formulated, but has not been performed yet. The assessment has shown that there are more than two dozens of such cases (from a Common to Domain Entity, Boolean to Shared Decimal) all of which were marked since the system upgrade from Suite 2 to Suite 3. The assessment has shown that most of the domains listed in the overview section has some of these elements.

Based on this assessment results, the Data Standard team worked with other Ed-Fi technology team members not only to perform the removal of these elements but also to create a policy in guiding future removal. By doing so, Data Standard hopes to give the community members a better predictable updates in the model in this regard.

The decision is to have these fields or other elements of the model to be removed at the second year of breaking changes following the version when the deprecation note would be introduced. It is also decided that the sample data for the element which is the subject of the removal will be removed from the data standard system at the same time when removal will be performed. These two practices of removal will be performed in consideration with the Break-Rest policy of data standard team (or data standard release cadence).

Considering the current data standard release cadence (Break-Break-Rest) that started implementation with Data Standard v4.0 if an element is marked as deprecated in a Data Standard model that is introduced with the first breaking year of the cadence, the removal of that element will be performed in the first breaking year of the next cycle of the cadence. Similarly, if the deprecation mark was introduced in the second break year, the removal will be in the second breaking year of the next cycle. In this way, Ed-Fi community members will have three years to adopt their system for the removal of obsolete model elements assuming the continuity of the current release policy.

Changes on Student School Association

As a part of state assessment of school funding process for the upcoming school it was reported by an Ed-Fi community member that some additional fields are needed as an optional data collection in the Ed-Fi model. Same community member also shared an extended use of SchoolChoice. Based on these recommendations Data Standard team implemented following updates on the StudentSchoolAssociation.

• Adding
  • NextYearSchool number,
  • NextYearGradeLevel descriptor,
  • SchoolChoice boolean,
  • SchoolChoiceBasis descriptor,
  • EnrollmentType descriptor,
• Marking SchoolChoiceTransfer as deprecated to be removed from the model on Data Standard v7.0 as suggested by the deprecated element removal policy aligned with the Data Standard release cadence mentioned earlier. 

Minor Changes

Adding Grading Period Name

It was brought to Ed-Fi Alliance's attention by some Student Information System (SIS) providers that GradingPeriod descriptor is not fulling their need in some use cases, specifically for those when SIS vendors need to create a unique grading period to match their data representation which is also better align with practices at the local level compared to the pre-defined grading periods by SEAs. To provide ease to the implementers and local educational agencies in their accurate data collection and a freedom that fits in their practices, Ed-Fi created GradingPeriodName as a required attribute in Grading Period entity. With this addition the definition of the GradingPeriod descriptor in the same entity has been updated to reflect that it is the naming pre-defined by the SEA and PeriodSequence attribute made optional instead of required.  

Minor Changes

Updates on EventDuration Field

The documentation of the field in the Ed-Fi system has been updated to reflect that EventDuration is the amount of time as a decimal fraction for the event as recognized by the school. Minimum and Maximum value constraint are also added to the field.

Updates on LetterGradeEarned

Definition for the LetterGradeEarned has been updated and the Maximum length value is redefined as 64 instead of 20.

Updating EarnedCredit as optional on CourseTranscript

The cardinality of the EarnedCredit on the CourseTranscript domain entity has updated from required to optional based on the feedback collected from Ed-Fi community members.

Update on BeginDate in StaffSectionAssociation

The BeginDate attribute is made an identity field for the StaffSectionAssociation to have parallel with the decision made for the same attribute in the StudentSectionAssociation as introduced by the new Section model updates. 

Update on the Definition of Term and Session

We have realized that there has been a confusion among the Ed-Fi community members about Ed-Fi's definition of Session and Term. To prevent these confusions and any misusage of them, the definition of these terms are updated in this version.  

Adding AnnualWage

Upon a report that indicate the misusage of the HourlyWage field in the core model because of the lack of attribute for the annual wage of staff in the StaffEducationOrganizationEmploymentAssociation and an extension created by another state, the AnnualWage attribute is added to the core model as an optional data for the association.

Adding SupporterMilitaryConnection

After reviewing multiple states' use case for data collection practices on the military connection of people who are responsible for students, SupporterMilitaryConnection descriptor is added as optional attribute to the StudentEducationOrganizationAssociation. Predefined values for this descriptor are; Active Duty, Reserve, Veteran, DoD Civilian, Not Military Connected and Unknown. 

List of All Changes

View all: