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.

  • Previously discussed Assessment (Roster) Model are used by multiple states in designing their model, implemented directly to state extension or with some tweaks. IN worked on their assessment model and getting into production, so is NE.

    • Model is pretty close to the original design inspired by WI’s use case except for 1 change to make direct reference to StudentSchoolAssociation, so assessment vendor won’t have to figure out the logic

      • EA- is it because you are multi-tenant

      • EW - still a single level ODS, vendor need to look at regular school association, not summer school

      • EW - will share model back

  • Looking for proposal to make rostering model available to all Ed-Fi users based on user experience, difference to the model, best practices

  • EA

    • Doing implementation for SC

    • There were a couple different versions available at the Ed-Fi resources for EA to start working on SC case, one on the Exchange open source which is slightly different than the WI’s extension. We ended up using WI version and not make any changes

    • WI

      • Administration participation only have contacts, too big as a collection

      • Took that off so each school is separately identified

    • SC

      • Key piece of information we provide doesn’t seem to be a use case for other states

        • Provide limited data on accommodation to assessment vendors

        • We added a lot of data to assessment customization

        • We ran into some problem with scale for larger districts

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

      • EA - another issue

        • Started using DS 5.3, now using 7.2

        • One hold up for production is for assessment vendors to only get delta for change version

      • EW - changed version works for our vendors

  • EW - Student assessment accommodation does not have edorg id, we needed to add customization. Will be good to add this.

    • Get accommodation from SIS vendor to know which students need accommodation

    • Created accommodation model

    • Student accommodation in Core Ed-Fi is very assessment-centric

    • Sayee

      • Only capture accommodation from SIS

    • EA - not want to add additional name-space to SIS vendors?

      • EW - yes

  • Sayee - What is  WI’s experience like? 

    • WI - in our early proposal, we had collection of accommodation on student assessment registration

      • Version we implementation does not have custom accommodation data as we don’t have source for

      • Always a separate process for accommodation get sent, very vendor specific

      • Don’t have the data to use

  • Sayee - What is SC’s experience like?

    • SC - SC has the data and want to pass to assessment vendor

    • Take namespace to limit access to other parts of student data

  • Sayee

    • We can look at MetaEd files to see IN model from Britto

  • NE

    • NE not using the model right now; NE not familiar with Ed-Fi accommodation side of data

    • May need to be 2 sets of data

    • Data needs to come from assessment vendors on what accommodation was actually used

  • ACT

    • As an assessment vendor our current model is for education organizations to push us assessment registrations. In the Ed-fi model, we were required to periodically pull from client ods for updates. This proved to be a scaling issue for us. 

    • 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