Participants
- Jen Downey
- Ben Meyers
- Audrey Shay
- Jill Aurand
- Laura Keith
- Sherod Keen
- Tarun Verma
- Veronica
- Jon Hickam
- Mike Discenza
- Eric Jansson
- Chris Moffatt
- Sayee Srinivasan
Notes
1.Tech Roadmap – Alliance presented that the larger annual update will occur in April at the Tech Congress to allow for the increased community complexity and use cases (assessment results over API, increased LEA activity, etc.). The TAG will be consulted for input in February and March.
Current roadmap was reviewed briefly, and it was note that the removal of Data Flow release does not communicate a lack of community interest or activity, just that the exact release vehicles are not yet clear.
2. Student ID rostering issue. The problem (see agenda materials below) and options were presented.
The main feedback from the TAG was that it was unclear why this problem occurs. Consistent with the Assumptions slide, why is it not possible for a school district to be consistent in its rostering, such that in each case the district uses the same student identifier. The best solution was seen as addressing this via the district exerting a consistent rostering strategy.
- Action: Eric took the action to go back to field projects and understand why this problem occurs.
Other comments:
- On Option #1, it was noted that as the Identification Codes were moves to the StudentEdOrgAssociation under 3.x, this lookup may be a bit more complex in some cases.
- On option #1, it was noted that the design of lookups in the JSON, the lookup element would likely be inside the Student reference, and not as outside (as depicted). One TAG member also contributed that it should probably be an either/or and not in addition to the use of StudentUniqueID
- It was noted that the Option 2 “ID lookup” may in fact be the current Identities API of the Ed-Fi ODS.
- As a global comment, it was noted that rostering can be segment-facing, such as in cases where the “student number” is used (as in parent portals, etc.)
3. Tech Congress Program. Sessions were briefly reviewed (see materials below). One comment was to add a session on course transcripts domain model, given current limitations (as documented in Tracker) on the model.
Addendum made on 1/21 - Eric's action from item #2 above
From consulting with the details of those involved in field projects, it seems that there are several cases where districts struggle to control rostering such that rostering can provide a consistent student identifier within the district ecosystem.
- State assessments are one case: in this case, the state only has the state-assigned student ID, which does not match the district student ID in usage. Yet districts would like to see the state assessments transferred via API into a local district context. One option would be to have the state also manage the local district IDs, but this was seen as a likely a fairly big lift.
- In some cases, districts are essentially dealing with systems with no formal rostering. In these cases, students often enter their "student number" into an application and may even in some cases self-roster. This student number may not match the SIS/district student identifier, creating a problem where two IDs can be resolved (and resolved prior to an API transaction).
- In some cases, vendors have pre-defined roster solutions and specifications, sometimes even without a student ID or with one that matches the wrong student identifier (e.g the state assessment use case above). There was no feedback on if the vendors would change their specs to accommodate IDs or multiple IDs, but it was regarded by those I consulted that there was likely a fair amount of inertia in this system, as those making the change would not be direct beneficiaries (i.e. they don't feel the current pain).
Based on this feedback, and looking at the Clever data specifications, it seemed that there were 3 main identifiers in the Ed-Fi ecosystem today (a SIS/district ID, a state ID, and a local student number), and that clarifying these was important. Also, it seems that the ability of a SIS to provide all 3 so that they can be resolved seems equally important. Based on this I raised DATASTD-1295 - Getting issue details... STATUS