Longitudinal Indicators In the EdFi standards and technology

Example Case • An agency has a Education. Organization metric called “Graduation Rate” and

Begin State Desired State Indicator (key) “Graduation Rate” Indicator Value 0. 93 Indicator. Level

Solution 1 Indicator (key) “Graduation Rate” Begin. Date (key) 08 -01 -2019 End. Date

Solution 2 Indicator. Identifier 464465522 Indicator (key) “Graduation Rate” Begin. Date 08 -01 -2019

Solution 3 Indicator (key) “Graduation Rate” Indicator Value 0. 85 Indicator. Level “Failing” Period

Indicator “Graduation Rate” Indicator Value 0. 93 Indicator. Level “Acceptable” Period Begin. Date 08

Slides: 7

Download presentation

Longitudinal Indicators • In the Ed-Fi standards and technology have a few places where metric values can be stored, such as Education. Organization. Indicator or Student. Indicator. • The current Ed-Fi design assumed that these would store only current values. • In the API therefore, the key for these entities is the Indicator. Name, which means that multiple indicators of the same name cannot be stored. This means that historical values cannot be stored alongside current values. • Field work has revealed the need to store historical values. • Note that it is unclear if the field work has shown the need to source historical values via API (there are several queries in Tracker on this point) • Tracker tickets: DATASTD-1554, DATASTD-1561, DATASTD-1464

Example Case • An agency has a Education. Organization metric called “Graduation Rate” and wants to store historical values for that metric along with the time periods that apply to that value. • In the current case, the past value is 0. 93, but they want to store that the new value is 0. 85 • It is unknown is the data will be sourced from the source system directly via API or not

Begin State Desired State Indicator (key) “Graduation Rate” Indicator Value 0. 93 Indicator. Level “Acceptable” Period Begin. Date 08 -01 -2019 End. Date 05 -29 -2020 Can’t add this record due to a unique key conflict on Indicator Original TPDM design: https: //tracker. ed-fi. org/browse/DATASTD-1464 Indicator (key) “Graduation Rate” Indicator Value 0. 85 Indicator. Level “Failing” Period Begin. Date 08 -07 -2020 End. Date 06 -06 -2021 e b/c th d o i r e use P has Can’t ator. Value Indic anged ch

Solution 1 Indicator (key) “Graduation Rate” Begin. Date (key) 08 -01 -2019 End. Date 05 -29 -2020 Indicator Value 0. 93 Indicator. Level “Acceptable” Period (deprecated) Begin. Date 08 -01 -2019 End. Date 05 -29 -2020 Indicator (key) “Graduation Rate” Begin. Date (key) 08 -07 -2020 End. Date 06 -06 -2021 Indicator Value 0. 85 Indicator. Level “Failing” Period (deprecated) Begin. Date 08 -07 -2020 End. Date 06 -06 -2021 • • • add a Begin. Date to Ed. Org. Indicator key add an End. Date deprecate Period PROs • Ed. Org. Indicator is now a longitudinal entity CONs • Breaking change for ecosystem • In many use cases, a source system has no Begin. Date, and clients will be forced to invent one. If another client reads that record, they now see data that is not from the source system i. e. , data that was invented or conventional • User-entered dates and strings have been found over time to be poor key fields, as they are frequently misentered.

Solution 2 Indicator. Identifier 464465522 Indicator (key) “Graduation Rate” Begin. Date 08 -01 -2019 End. Date 05 -29 -2020 Indicator Value 0. 93 Indicator. Level “Acceptable” Period (deprecated) Begin. Date 08 -01 -2019 End. Date 05 -29 -2020 Indicator. Identifier 46446595 Indicator (key) “Graduation Rate” Begin. Date 08 -07 -2020 End. Date 06 -06 -2021 Indicator Value 0. 85 Indicator. Level “Failing” Period (deprecated) Begin. Date 08 -07 -2020 End. Date 06 -06 -2021 • • add an Indicator. Identifier to the key add a Begin. Date and End. Date deprecate Period (optional) plan for removal of Indicator from key at later date PROs • Ed. Org. Indicator is now a longitudinal entity CONs • Breaking change for ecosystem • Identity of entity now uses a source system surrogate for a very minor entity – i. e. , that identifier likely has no value outside of the source system. OBSERVATION • If this is the solution, it is unclear if there is value from having identity at all. The Indicator. Identifier supplied by the client may not be stable, i. e. , not suitable for clients to store if they wish to lookup this value. See Solution 4)

Solution 3 Indicator (key) “Graduation Rate” Indicator Value 0. 85 Indicator. Level “Failing” Period Begin. Date 08 -07 -2020 End. Date 06 -06 -2021 PROs • Ed. Org. Indicator is now a longitudinal entity • Non-breaking change for ecosystem CONs • Historical data is not being sourced from the source system. This solution is only appropriate if the ODS / API is the place where changes are being tracked • Alliance has no canonical solution, so an implementation has to define and implement this • If a source system has historical data, it now has no means of sending that data (potentially serious limitation!) Longitudinal tables/store Id 7925 c 72 a-1 d 5 c-4 be 3 -8 c 0 c -6 d 04 f 95 b 6447 Indicator “Graduation Rate” Begin. Date 08 -01 -2019 End. Date 05 -29 -2020 Indicator Value 0. 93 Indicator. Level “Acceptable” • • Move historical data out into some longitudinal store Could use change data capture, DB triggers, etc.

Indicator “Graduation Rate” Indicator Value 0. 93 Indicator. Level “Acceptable” Period Begin. Date 08 -01 -2019 End. Date 05 -29 -2020 Indicator “Graduation Rate” Indicator Value 0. 85 Indicator. Level “Failing” Period Begin. Date 08 -07 -2020 End. Date 06 -06 -2021 Original TPDM design: https: //tracker. ed-fi. org/browse/DATASTD-1464 Remove Indicator as a key field (key is only the identity of the host entity) PROs • Ed. Org. Indicator is now a longitudinal entity • Non-breaking change for ecosystem • Aligns with Ed-Fi formal specifications CONs • Unclear if the Ed-Fi platform can support this without technical work • Possible reduction in data quality (likely similar to Solution 2)