TAG Meeting 2019-01-16

Owned by Eric Jansson
Last updated: Jan 24, 2019
4 min read

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

Addendum - additional use case submitted

This scenario was sent in via email - the original text was edited to make all parties anonymous by replacing names with generic identifiers.

When accounts were provisioned in the career planning product, the id often used is one of two ids, a SIS system id or the LEA local student id. This caused an issue with the career planning product when trying to get data via the state data system. Ultimately they utilized the enrollment composite to get all the student state IDs from the career planning product. Once this was done they had to use the state IDs to do an Identity API look up to get email, local person id (a.k.a. LEA local student id…hopefully, it could be the SIS system id). When LEAs submit the state IDs file to the state, one of the columns is for entering a local person id for the student.

From this exercise the career planning product could load the state IDs into the career planning product matching on email and local person id (if what was in the local person id is what was in the career planning product as an identifier). We ran into an issues with SIS systems where there were up to two ids in addition to state IDs. Not all the systems trying to pull in roster data, like the career planning product, have state IDs in their system so this makes interoperability challenging. The state ID application does allow for one or more local person ids but it doesn’t identify which id is what and we have no idea which of those ids is used as an identifier in other vendor systems.

Materials