Avoidance of 'data thrashing' on key /student resource data elements

Eric.Jansson this was the issue I brought up in the 2.1 Data Standards at the conference on the last day.

ISSUE: Some students will be enrolled in different LEAs during the school year and many SIS vendors have full re-sync processes. If a student enrolls in District A and values for Econ Disadvantage, School Food Service, LEP are recorded, but then change when they are in District B (enrolled in B after exiting A), a full re-sync of the SIS used in District A will overwrite the key demographic data points typically used for federal and or state reporting.

OUR TEMP SOLUTION: We had to implement an L1 rule which blocks the update of /student when the LEA is no longer the 'current' SSA. We go thru some hoops to do this.

IDEAS: one idea, make the volatile properties an array like studentAddress which has a begin/end date and perhaps it would need an edorgid ref. This gets complicated (data migration, SIS vendor change...) OR ???

cc: WiDpiTom retzel017