Page Comparison

...

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 

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

...