2024-09-06 DSWG Meeting #2

Participants

Number of Attendees: 27

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

Meeting Agenda

1. Presentation of proposed Assessment Registration domain

2. Alternative API Interfaces

3. Introductory conversation for Section 504 related updates needed

Meeting Materials

• Presentation Deck:

Open

• Webex meeting recording: Data Standard Work Group-20240906 1820-2
  Recording link: https://edfi.webex.com/edfi/ldr.php?RCID=529dd86a4bb8bd1127febf48841d2428

Meeting Notes

• The draft design proposal of the Assessment Registration Domain has been presented to the participants to collect their feedback for further development of the model.

  • Assessment Registration Domain entities AssessmentAdministration, AssessmentBatteryPart, AssessmentAdministrationParticipation, StudentAssessmentRegistration and StudentEducationOrganizationAssessmentAccommodation have been introduced to the audience with references and attributes they have.

  • A vendor has asked if the AssessmentBattery part in assessment domain and

  • A discussion on whether or not StudentEducationOrganizationAssociation (SEOA) is needed as presented in the draft has taken a place upon a community members' question and it is clarified that due to the need for access to student's demographics as well as student’s state identifier the reference to the SEOA is needed in the model. It is noted during the discussion that the required references to SEOA and SSA are causing issues with the SIS vendor's API, which blocks deletion. They considered removing the delete cascade or making the reference optional. However, even with an optional reference, the issue persists, though the assessment vendor would understand the absence of the student. A workaround was mentioned, involving breaking the enforced foreign key reference and making it logical in code generation. This approach ensures that even if vendors delete and repopulate base data, identifiers would temporarily be zero.

  • It is reminded by a community member that the model design should consider the need that all EducationOrganization can be independent.

  • The group had a discussion on the AssessmentBatterPart. Specific cases where ObjectiveAssessment is different from AssessmentBatteryPart is covered in the discussion and differences between the two have been emphasized. It is clarified that related subjects can be grouped under an assessment battery, such as English, Reading, Writing, Science, and Math as ACT has. Composite scores and specific groupings like ELA and STEM were also mentioned.
    An issue was raised about establishing assessment registration before assessment details are reported. It was noted that assessment registration (a shell without all details) does not map with assessment scores. When pulling rostering from the SIS, the exact assessment titles the student will take are unknown, and the assessment reference in the administration is just a placeholder.

    The team keeps the assessment identifier consistent for the ACT and discussed the metadata nature of assessments. There was a question about registering students for multiple subjects, but it was noted that the specific assessments students will take are not sorted at the time of registration.

    Concerns were raised about using assessments for participation and the need to set up logic to associate with all assessment identifiers. The use case based on assessment family was discussed, and it was suggested that a suite of pre-ACT programs could indicate student eligibility for one of the family assessments.

    The possibility of having one assessment administration that includes multiple assessments was considered, and it was noted that some states want to see the jurisdiction under which the assessment is taken (state, district, or national level). It was suggested that allowing this distinction would be beneficial.

  • Four alternative API interfaces (ODS/API composites, using API Publisher, using a stand-alone API for security and database model and using specialized API with custom ETL as an extension) have been mentioned, resources for further reference have been shared. The audience has shown interest in discussing further about what using a specialized API with custom ETL would mean and what parallels it has with the current practices of some of the community members. The option of using the API Publisher has been also extended during the conversation and community members has suggested that they are not sure if vendors would be using the API Publisher.
    The audience reminded that a detailed information can be found in the following TechDoc page Backend Development Patterns for Specialized Ed-Fi API Applications | Real time API Interaction.

• Section 504 has been discussed as the topic for the next meeting.

  • During the discussion it was mentioned that Section 504 has parallels to the Special Education however it has different process and requirements, therefore needs to be separated from the Special Educations.

  • It is mentioned during the discussion that there have been multiple states interested adding this as an extension to their Ed-Fi model. Therefore, Section 504 is elected as a topic for the next meeting to be discussed by the group.

Actions items:

• DS Team will discuss feedback and update the design to share during the Summit for further conversation; propose to bring into the 5.2 model.

Next Meeting Oct 11, 2024