2024-08-02 DSWG Meeting #1

Participants

The meeting was held 2024-08-02  12:00Pm -1:15pm CT via WebEx

Meeting Materials

WebEx Recording LINK

Meeting Notes

Work Group page Data Standard Work Group

• Data Standard (DS) v5.1 was released in May with major updates on Student Health, Crisis Event and Student Transportation.

  • DS team would like to get guidance and feedback from all segments of community members for next release (DS v5.2) in November by utilizing

    • The community guidance at the Tech Congress 24,

    • Findings from DS team’s state extension analyses,

    • And through out our community meetings

• The Ed-Fi community has shown strongest interest in Assessment roster and accommodation. Therefore, today we initiate the Data Standard Work Group (DS WG) meetings with a discussion on assessment roster.

• Assessment Registration

  • Current Assessment Domain includes multiple entities and attributes in the model, but all them are focus on the data recording during and after the delivery of assessment. Ed-Fi community members has shown an interest in having the capability in the model for data recording for the interaction between educational organization, student, assessment and assessment administrators before the delivery of assessment.

  • An assessment roster model has been created previously by Wisconsin (WI) as a state extension to the Ed-Fi data model about three years ago based on what is published in the Exchange open source web page. The only difference between the two version was that the WI version have the AssessmentAdministrationParticipation entity branched out from the AssessmentAdministration entity due to over grown collection of information collected under the Contact composite part in the AssessmentAdministration.
    There have been multiple states followed that design and created their extension. In the following parts, we would like to discuss more details about those implementations.

  • The Assessment Roster Model of WI has been adopted in Indiana (IN) and Nebraska (NE), with some modifications. A key change to the base model is a direct reference from the StudentAssessmentRegistration entity to the StudentSchoolAssociation. With that reference the assessment vendor won’t have to figure out the logic about what student enrollment is the right one for the rostering.
    Note: It is asked asked if that change was due to a multi-tenant setup of the ODS, but it was clarified that it was still a single-level ODS in the state

  • South Carolina (SC) is working with a vendor to create their own version of the assessment registration model. After considering different alternatives, they have also decided to follow the design WI has created. SC reported following key differences compared to the use cases other state implementation of the Assessment Rostering Model has shown

    • SC provided a limited data on accommodation to assessment vendors,

      • They added a lot of data to assessment customization

      • They ran into some problem with scale for larger districts

      • They went to production with 1 vendor 2 weeks ago, simulation working well, will have better information in a couple of weeks

    • Another issue was that SC started using ODS/API v5.3 and now using v7.1. Assessment roster is not working well with changed versions. One hold up for production is for assessment vendors to only get delta for change version. This seemed and issue for version changes from v5.3 to v7.1 because another vendor confirmed that a change from v6.1 to v7.1 works.

  • A vendor emphasized that StudentAssessmentAccommodation does not have EducationOrganizationId and that could be something to consider in the new design because in their the vendor needed to add accommodation customization. What they have done was that they got accommodation from SIS vendor to know which students need accommodation and created an accommodation model because the StudentAssessment.Accommodation in the Ed-Fi core model is very assessment-centric.
    WI added that in their early proposal, they had collection of accommodation on student assessment registration, but the version implemented does not have custom accommodation data as they don’t have source for it as a separate process for accommodation get sent, very vendor specific and they don’t have the data to use.
    SC’s experience is that they have the data and are willing to pass them to the assessment vendor as they take namespace to limit access to other parts of student data.
    NE’s case is that they do not use accommodations from the model at the time. They also reminded a reality to the meeting attendees that whatever accommodation we foresee a student will get at the registration, actual accommodation student receives during the delivery of the assessment could be different. Therefore, it would make sense to have an ability to collect data on both type of accommodations. Data on what accommodation was actually used needs to come from assessment vendors.

  • ACT as an assessment vendor shared information about how they use the model and emphasize one opportunity for improvement which is that the current model requires assessment vendors to forward all resources for any changes or queries. Their current system relies on clients pushing registration data to them, which does not scale well. Additionally, the registration table consists of numerous pointers, meaning that if a student's name changes, they must check various entities to ensure consistency. This process is not only time-consuming but also prone to errors, which can lead to significant delays and complications. To address these issues, a more efficient data management system that can handle changes dynamically and reduce the dependency on manual checks is needed. Implementing such a system would improve their ability to manage registration data at scale and enhance overall operational efficiency.
    Affirming thoughts are shared on change query at scale being an issue while a state mention no problem with running control of changes periodically (daily).

  • At this point the discussion evolved to the usage of composite. Ed-Fi wanted to check with the participants if the group sees a benefit of using composite. It is mentioned during the discussion that the usage of the enrollment composite among the community members was near to none, and this could be because of the security related challenges the composite brings. Therefore, a vendor mentioned that going back to the usage of composite for assessment registration could be counterproductive and more prone to problems than benefit.
    On the other hand an SEA mentioned that a smaller and limited composite can be beneficial. The thinking behind the thought is that the Enrollment composite is it’s too huge. A focus rostering composite can be beneficial. Recommendation was that if used have the composite be limited only for things that will help assessment vendor get student list they need such as name, birthday, grade level, gender and race code.

  • It is also suggested by an SEA member that having grade level and collection of subjects references in the model. ACT reminded the audience that they do not have register students at subject level, instead as battery assessment.

• Group discussion & next meeting schedule review

Actions items:

1. EdWise (Britto) to share the MetaEd files for IN’s use case

2. DS Team come up with proposal, share with group before next meeting

Next Meeting Sep 6, 2024