Page Comparison

...

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

...