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.

  • An assessment vendor shared information about how they use the model and emphasize one opportunity for improvement the model in its current design has. It is maybe to have education organizations to push assessment registrations to assessment vendors. In the current design, assessment vendor is required to periodically pull from client’s ODS for updates. This proved to be a scaling issue for the assessment vendor.
    
    
    

  • One of the challenges working with WI on the proposed model, is our need to forward all the resources to for all changes queries

  • Our current system is client push registration data to us

  • Direction does not work well for ACT at scale

  • Registration table is a bunch of pointers; if student name changes, we have to check different tables

  • EW - change query at scale is an issue

  • SC

    • In SC, there is a schedule

    • Because we have a lot of customization, it eliminates the need for vendor consuming data

  • Can’t studentassessmentregiration include all the information, so it’s just one place the assessment vendor need to go for data

  • WI has their own descriptors, namespace and value specific to WI, that needed to be mapped

  • How to map school identifier to our organization

• Sayee

  • Does the group think a composite is better?

  • EA - security becomes more challenging with composite

  • WE - a smaller composite can be beneficial. One problem with enrollment composite is it’s too huge. A focus rostering composite can be beneficial. Limit to just the thing they need for student list

    • Name, birthdate, grade level, gender, race code

  • ACT- agree with Audrey, keep it simple

  • EA - if we require composite, that’s additional maintenance

  • WI - composite will make it easier for assessment vendors to get started, may not need be a long term solution

• Skyward

  • Depending on state, data put on SCOA need updating more frequently than we like to see

• WI

  • Our current model is missing

    • Grade level

    • Various subjects - collection of subjects

      • Administration rostering for parts taking

      • Sayee - 

        • Could be academic subject collection

        • People get confused if they need to create 4 separate assessment if ACT has 4 parts

        • ACT - ACT creates subject underneath, don’t have registration at subject level

• Curriculum Associates

  • Unless you have overall score across all

    • ACT- yes, ACT has composite score in the model

• EA - Is it the subject you're describing or actually something more like "assessment form"?

  • ACT - then we have to push multiple definition through the composite

• Sayee - will take input for internal analysis

• EA - NWEA

  • Forms not tied to a subject

• WI

  • Most important is which option under the administration we are registering the student for

• Sayee

  • If a student is taking ACT with writing or just ACT, then 2 forms and 2 administrations?

  • WI - No. 1 administration, 2 forms

    • Administration with options (academic subjects) for each grade level

• 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