Agenda

• Authorization Linked to New Identities

• Special Education Data Model - Presented by Nick Munce (Public Consulting Group) and Rosh Dhanawade (Education Analytics)

• Multiple Identities and Student Education Organization Association Split

• Review RFC 27

• Review New RFC 28 (draft)

• Q&A

Participants

Meeting Materials

Detailed Discussions

Authorization Linked To New Entities:

• Summary: The proposed data model changes are anticipated to impact both existing authorization mechanisms and data consistency across systems, largely stemming from the separation of elements from the StudentEducationOrganizationAssociation into more granular identity, demographic, and contact information. These complexities need to be further explored in terms of how student data updates are performed and whether or not additional fields such as BeginDate should be included as part of the natural keys going forward.

• Proposal:

  • Create a link authorization directly to identities instead of the students school association instead of the current method which involves going through Student > School > StudentSchoolAssociation > Ed Org.

  • A dedicated authorization entity could potentially reduce reliance on custom authorization strategies, and allow for a more consistent dedicated authorization mechanism that does not require an enrollment record and improve flexibility.

  • Consider adding BeginDate to the natural key of the StudentIdentities

• Resolution:

  • Pending review and discussion at the next TAG meeting

• Feedback:

• Currently the system has some authorization which can create awkwardness, when begin dates for student changes. Deleting and adding student school associations can lead to a brief period where one is technically unauthorized to modify student data, making the process complex for vendors who need to ensure data is sent in the correct order to avoid errors.

• If the update of records is currently done in the wrong order vendors may have to create “fake enrollment” records in order to facilitate deletion of the remaining records.

• Community has requested that some guidance be provided on the BeginDate both in terms of how it should be used, but also for those vendors or entities who may not specifically be tracking this information.

Special Education Data Mode

• Summary: Presented by Nick Munce (Public Consulting Group) and Rosh Dhanawade (Education Analytics). Indicated they’re currently working with the state of South Carolina and its statewide special education system which is currently downstream from the rest of the Ed-Fi infrastructure. The Special Education domain has an increased need to capture plans for each student, the changes to those plans, and the goals over time for those students. The existing Ed-Fi model forces organizations to collapse much of the existing data that is used for Special Education which results in a loss of granularity, holes in the tracking of events supporting the individual education plan (IEP) of the student. This creates challenges for those organizations looking to simply address Federal and State compliance and reporting requirements. One of the current and immediate focuses is looking to identify the common data elements used in reporting with Special Education. As a result, while the proposed changes represent some of the improvements this is still a work in progress and feedback is both welcomed and solicited from the community.

• Proposal:

  • Initial proposal is for the baseline requirements for reporting to provide a foundation for future iteration and enhancement.

  • All changes proposed would be additive to the existing model to avoid breaking any existing functionality or relationships.

  • The proposal seeks to better represent the changes over time, individual student needs, and services provided/received.

  • Proposal involves creating new domain entities and relationships that would capture:

    • StudentIEPAssociation

      • Given a unique ID for each IEP associated and linked to a student

      • Records a date the plan was finalized

      • Allows for better tracking for required annual review

      • Establishes the relationship to the child events which create the overall IEP (see below)

    • IEPServicePerscription

      • Details the service that should be provided to the student (i.e. Reading Intervention/Speech Therapy

      • Used to track toward an IEP Goal

    • IEPServiceDelivery

      • Details if the above prescriptions are being successfully provided as outlined

      • May be related to a supporting Event

    • IDEAEvent

      • General event structured to support the related data

      • Relate to the overall IEP

      • Track things such as Parent Consent or general updates

    • IEPGoals

      • Used to track if an IEP was completed successfully (i.e. if the prescribed speech therapy achieved its overall articulation goal for the student)

      • Often an IEP Goal may be structured to become or result in a new IEP for a student

      • Goals are somewhat fuzzy/open to interpretation from district to district, state to state, and organization to organization

      • Current proposed format is fairly open/simplified to allow for the more flexible implementation and use.

• Resolution:

  • Provided two links to google documents (attached above)

    • Conceptual Model Diagram and related information

    • Document showing the current mapping as it relates to Special Education Data Model and the current Ed-Fi Data Model

  • Obtain additional feedback from the community and review

Multiple Identities and Student Education Organization Association Split

• Summary: Reviewed the changes outlined by Ed Comer from DSWG-9 to simplify the StudentEducationOrganizationAssociation and similar entities by breaking out key attributes from Staff, Student, and Candidate into separate entities for their corresponding Contact and Demographic information. In addition, a corresponding identity entity would be created for each previously mentioned entity along with Contact. This would reduce the overall complexity of the SEOA and allow for increased flexibility in managing the supporting data for each organization.

• Proposal:

  • Reduce/Slim the StudentEducationOrganizationAssociation by removing specific identification and demographic information into their own tables

  • Apply a similar pattern to other entities and domains which have similar attributes and needs

  • Create IdentityEntities for:

    • Candidate

    • Contact

    • EducationOrganization

    • Staff

    • Student

  • Create Contact Entities for:

    • Candidate

    • Staff

    • Student

  • Create Demographic Entities for:

    • Candidate

    • Staff

    • Student

• Resolution:

  • Community to review Request for Comment #27 - here

    • Final date for feedback is July 30, 2025

  • Review additional impact to other associations such as StaffEducationOrganizationContactAssociation

  • TAG will evaluate the best possible path for adoption of these changes between:

    • Deprecation (until Data Standard 8.0)

      • Allows existing entities to ease their burden of transition

      • Creates and opportunity for confusion/ambiguity of collected data

      • Does not require migration at time of adoption

    • Deletion

      • Major concern is that demographic or contact data sent to the SEOA via the API’s will be lost and currently, no error will be produced.

      • Increased burden of transition due to forcing immediate adoption

      • Reduces confusion/ambiguity, and was a preferred approach from some SIS vendors and states.

      • Requires migration at time of adoption

• Feedback:

  • Community to provide feedback under Request for Comment #27 - here

  • The TAG team will indicate whether we deprecate or delete elements in the SEOA.

NEXT STEPS:

• Follow up on the authorization issues discussed in the meeting and bring them to the next TAG meeting.

• Review the overlap between the new StaffContactInformation entity and the existing StaffEducationOrganizationContactAssociation. Keep only one of them if there is significant overlap.

• Please see attached the Special Education Data Model visio diagram courtesy of EA (Rosh)

• Community to provide feedback based on the proposed changes to the SEOA and separation of attributes into their own specific entities