Meeting 3 - 2018-01-17

Notes

The meeting summarized conclusions from previous meetings and also considered the question of inefficiency in "Level 2" validation (i.e. validations that run after acceptance of the data by the APIs).

At a high level, the conclusions seemed to be:

• Problem: For the "Level 1" issues at the API endpoints, the problem seems to be that many vendors are not following best practices for API usage, including:
• Low understanding of authorization in the APIs, and particularly that a client may not have access to a resource it has written unless there is a relationship/role based claim in place (e.g. after POSTing a /student, the student cannot be edited unless the student has been enrolled in a school to which the API client has permissions)
• Clients are not taking action after repeated failures, but just continuing to send more requests which will fail
• Excessive synching: some clients seem to re-sync daily, which also increases failures
• Solution: change behavior of API clients through awareness, training and best practices documentation
  
  
• Problem: a considerable amount of inefficiency in the resolution of "Level 2" validations comes from the disconnected nature of the user experience for LEA data stewards / SIS users. The theory is that the fact that error messages are surfaced in a separate SEA user interfaces and reports disconnected from the SIS itself means that special effort and attention are necessary to resolve data quality problems.
  • In the current experience, the LEA staff must consult an external validation portal report published by the SEA, and then make corrections in the vendor system. This process of using 2 systems can be awkward for users, and also requires multiple logins.
  • Further, vendors have no visibility into these data quality errors identified by the state. They can neither see the errors or get any aggregate or other metadata on them (e.g. "there were 1000 errors relating to student attendance records - looks like something is wrong there")
• Solution: the SIG supported the concept of adding ODS / API functionality for managing  “Level 2” validation errors. Such a system would accept errors from a validation system and surface them back to vendor systems via an API, with the goal of creating a “unified UX” for district user (provide a path such that errors can surface in SIS systems and reduce the need for multiple interfaces for end users)
  
  • It is recognized that such a system would need to run alongside to current systems, at least for a period of time. I.e. vendors are not in a position to be able to consume an error API and such readiness would take time. There was also concern voiced over if such an effort would be worth it - i.e. add enough efficiency.
  • It was noted that such a system would provide vendors more visibility into Level 2 errors (which they don’t have now - districts must manually relay errors from state validation reports to vendors), and promises greater ease of use for SIS users over time.