Page Comparison

...

• 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

    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

    • 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

  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,

      • We

        They added a lot of data to assessment customization

      • We

        They ran into some problem with scale for larger districts

      • Went

        They 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

    • 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

    • 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 . 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

    Created

    and created an accommodation model

    Student accommodation in Core

    because the StudentAssessment.Accommodation in the Ed-Fi core model 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

  .
  WI added that in their early proposal, they had collection of accommodation on student assessment registration

  Version we implementation

  , but the version implemented does not have custom accommodation data as

  we

  they don’t have source for

  Always

  it as a separate process for accommodation get sent, very vendor specific

  Don’t

  and they don’t have the data to use.
  Sayee - What is SC’s experience like?

  SC - SC has

  is that they have the data and

  want

  are willing to pass them to the assessment vendor

  Take

  as they 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

  .
  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

  on what accommodation was actually used

  .

  • ACT

    As

    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

  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.

    Limit to just the thing they need for student listName, birthdate

    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

  • 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

  .

  • 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

...