Agenda

• Tech Congress Wrap-up: Follow-up on the Tech Congress session last month

• 6.0 Preview 1: Highlight the RFC contents for the Data Standard 6.0 preview 1

• Person Model etc.: Evolution of the “person model” and flattening of identifiers, demographics, etc.

• CTE: CTE mapping work from Vermont, by Doug Quinton (Education Analytics)

• SEDM: Special Education Data Model evolution, by Greg Nadeau (PCG)

Participants

Meeting Materials

Open

Summary

• Ed is retiring at the end of May. Please join the Ed-Fi Alliance in extending our best wishes to Ed and thanking him for his contributions to the field. We’ll miss him greatly.

• The Person entity will remain as is (optional entity and no modifications).

• Data Standard 6.0 will also be available for ODS/API 7.4 in Q1 2026. Please review the attached slides and the RFC for DS 6.0 Preview 1, and direct any questions to Maria.Ragone@ed-fi.org.

• Ed presented a solution to handle multiple identifiers by creating separate identity entities, which would deprecate the IdentificationCodes .

  • There was strong support for introducing new role identities—9 out of 13 votes in Poll 1—with a request to include EdOrg ID in the key and to evaluate the key’s components (see details below)

  • Many members also requested considerations for handling multiple identifiers for EducationOrganization.

• A proposal was presented to remove common attributes from SEOA.

  • Most responders supported breaking out common attributes sets for SEOA, Staff, Contact and Candidate (8 out of 11 votes).  The remaining 3 votes preferred breaking out SEOA only.

• Doug shared a new mapping for CTE for Vermont, and Indiana and South Carolina expressed interest in participating in further CTE discussions .E

• There was no time to discuss the CEDS-SEDM model, however, details of the program can be accessed at CEDS-SEDM.org . Please review and send any questions to Greg before June 2nd.

Detailed Discussions

Update on Person Model:

• Summary: A proposal was presented at Tech Congress to modify the Person entity’s key with an added sourcenamespace. This change was intended as an approach to handle multiple people’s id. However, the community indicated that the implementation costs and implications outweighed any potential benefit. As a result, a decision was made to maintain the Person entity as-is.

Handling Multiple Identifiers

• Overview: students, staff or contacts may have several different identification codes, which are currently stored in the IdentificationCode multi-valued common. These identificationCodes are not easily searched prior to ODS/API 7.3, and updating multi-valued commons requires rewriting all records.

• Proposal:

  • Extract alternative identifiers from the xyzIdentificationCode multi-valued commons into separate xyzIdentity entities (StudentIdentity, Staff Identity, etc.)

    • Create new identity entities for each of the four person roles (Student, Staff, Contact, and Candidate) to replace the existing identification code arrays where they exist.

    • For example, the proposed structure for StudentIDentity would include: studentReference (key), identificationCode string (key), studentIdentificationSystem descriptor (key), assigningOrganizationIdentificationCode string (optional).

• Resolution:

  • The community supported the creation of these new identities (see poll 1 results) with the following considerations:

• Feedback:

  • The community requested the inclusion of Ed ORg Id in the Student Identity, This helps downstream systems manage overlapping or conflicting IDs, especially for student in multiple districts.

  • There was a tie (5 votes vs. 5 votes) on whether to deprecate or delete IdentificationCodes upon adoption of v6. Thus, we’ll maintain the more conservative approach to just deprecate IdentificationCodes.

  • We are asked to evaluate if the key should have UniqueId, IdentificationCode and StudentIdentificationSystem in the Identity Entity key. Some preferred the key to be the student reference and identification system to prevent recording multiple IDs for the same system, while others preferred including the IdentificationCode to cover erroneous duplicates or IDs from different source systems within the same organization (e.g., SIS vs. FINHR). There were differing views on whether this helps manage erroneous duplicates or creates data integrity issues better solved by governance and claim sets.

  • Poll Results: Slido - {Virtual} Data Standard Workgroup Meeting #9 - Note, the link will be available for 60 days

  • Open

    
    Open

    

     

Breaking the SEOA

Overview: ·Currently, the SEOA contains 31 separate attributes, which creates an update load. For example, Assessment vendors require demographic information, but any change to the large SEOA entity triggers analysis of the entire large payload. Demographics change over time, but the current structure doesn't easily support tracking this with dates. Additionally, the current model is not easily searchable and requires transmitting a large payload for minor updates.

Proposal: to separate demographics and contact information from the SEOA to reduce the burden of updating just a few records. A vote was requested to determine whether to break out SEOA alone, or also break Staff, Contact and Candidate.

Resolution:

• Most responders favored breaking out common attributes sets for SEOA, Staff, Contact and Candidate (8 out of 11 votes).  The remaining 3 votes preferred breaking out SEOA only.

Other Feedback:

• There was discussion about how small the resulting entities might be if common elements are separated.

• The idea of breaking out Student Characteristics and Student Indicators into additional separate entities was raised. For example, South Carolina reported significant overhead associated with indicators, which created challenges when integrating with third-party special education vendors.

• Participants expressed interest in optionally tracking effective dates for the new breakout elements to support historical data tracking for specific codes.

• Poll results at the meeting:

Open

CTE - by Douglas Quinton

Overview: There is a significant interest in discussing and expanding the Ed-Fi data model for CTE. Several states have begun working with CTE data within the Ed-Fi standard; however, the current standard lacks sufficient coverage, requiring extensions.

Proposal:

Feedback:

• It would be beneficial to capture key fields such as cooperative education placement, earned credentials and licensures.

• CTE has variations in implementation and issues with terminology. Standardization would be a great benefit to tracking information for the program.

• Indiana, and South Carolina expressed interest in adding CTE data in Ed-Fi and participating in future discussions.

• Post meeting: GaDOE (Georgia) has implemented a customer resource that adds 2 Boolean values, see image. Doug can provide Georgia’s own descriptor values for specialEducationEventTypeDescriptor to anyone interested.

• Open

  

   

NEXT STEPS:

• Please indicate via email/slack to @Maria Ragone or @Stephen Fuqua if you plan to upgrade to DS 6.0 for the 2026-2027 school year.

• We are seeking additional feedback on the topics of breaking the SEOA and handling multiple identifiers. After reviewing the presentation, you can provide your vote to the poll questions here, use passcode: h3agme

• Evaluate the key components for new studentidentification entities (whether to include EdOrg, and the identificationCodeDescriptor)

• Maria and Stephen to review the deprecated CTE elements (based on Jira tickets) indicated by Doug Quinton which have been marked for deprecation between versions 7.2 and 7.3.

• Review the possibility of adding optional effective dates (start and stop dates) to track the history of changes.

• Greg is scheduled to present first on the Special Education Data Model at the next DSWG meeting.