Thursday, April 10, 2019

Original Google Docs Notes from Session

Source Systems Dual Connections (1)

• Maybe a little misleading, should be more lines there. Like 50 calls going to LEA and to SEA or collaborative. For example when collaborative is hosting a single ODS for the collaborative, but also individual ODS’s for the districts in the collaborative.
• As a CIO, I want control over data that goes to the state. So want to feed all transactional data to an owned ODS before doing state reporting.
• Nebraska: our states are becoming appreciative of the level of validation that we’re able to provide to the districts through the ODS, especially the smaller ones. They’re being forced to clean up data in their local SIS.
• Concern - generally, the data going to LEA and SEA ODS would be different, so dual connections would put onus on the vendor to create different payloads.
• INSite: SIS vendors are limiting the payloads to what the state wants [editor: did I hear that correctly?]. State is taking a subset of the core elements. Thus the LEAs / collaborative is getting less than they want.
• Counterpoint - state doesn’t want all of the data because of discoverability problems.
• School partnerships can trigger need to go from school to school.
• Grade levels may look different (descriptors) between what the LEA and SEA need, even if same data is going to both.
• Some larger districts may want more detail about race/ethnicity than what the state collects. If state adds those descriptors then that could be burdensome to smaller districts. So larger districts are asked to roll-up to a less granular definition of race/ethnicity when sending data to the state ODS. In some cases SEA’s are legislatively mandated to limit that data.
• If LEA tries to send something that the SEA won’t accept, errors will be generated and the LEA will have to parse out the reason for the error and decide how to respond. → But if you use API Profiles are used then the data could be accepted but not processed in stored. → Might not be good enough, LEA sending data that they’re not supposed to communicate might still be sued. (like special education data).
• Is there potential for conflicting signals? I.e. an LEA accepts the data but the SEA doesn’t. Seems like LEA should do first round of cleansing before the data goes to the State. Example: LEA does headcount on Kindergarten and 4 year olds are included, but state will only count 5 year olds.
• SIS vendors support this today.

LEA API Push to Collaborative or SEA API (2)

• An “LEA Sync Agent” intercepts message between Vendor and LEA API, does some work, and pushes data to the Collaborative / SEA ODS/API.
• Would like for such a sync agent to be able to pull a resource ID from the ODS.
• Shouldn’t this be the vendor’s responsibility?
• Back to the validation problem - sync agent wouldn’t benefit from the validation performed by the LEA ODS. And again the sync agent pushing to collaborative/state ODS might encounter validation errors.
• This isn’t necessarily limiting complexity for the vendor overall - because one district might have the sync agent, and another one might not and may ask the vendor to send directly to the state.
• What if you want to send data to more than 2 ODS’s?

Collaborative or SEA API Pulls from LEA API (3)

• Sync agent at the SEA level pulls from the LEA’s ODS’s
• Everyone dislikes it ;-)

LEA ODS Connector to Collaborative or SEA ODS (4)

• Something built into the ODS  to forward requests to the collaborative/SEA ODS.
• Additional field “ReportTo” that instructs the API where to forward data to.
• Rosh talked about MI Data Hub… editor didn’t quite follow.
• What about the webhook concept, where the webhook is “if accepted, then call this API”? →  Yes, that could work, and the MI Data Hub example worked on by Double Line is similar. Not just forwarding the original request but re-pulling from the database so that you have the resource ID.
• This concept seems ideal for collaboratives that will help small LEA’s get up-and-running quickly with forwarding data to the SEA.
• Has this lost the proper security at the state level?

API Gateway (installed at LEA) (5)

• Re-routing API call to both LEA and collaborative/state, without business logic.
• Isn’t this the same as option 2? No, because this is fully intercepting the request and may or may not route the to the LEA.

API Sync Agent (6)

Other Models?

• What about something built into the API itself? Slide 4 was coming from the ODS, not the API. We were expecting from the API.
• Need to be able to apply different profiles, filter data, and handle different descriptors for the different operational context. And it must be able to get actual data from the LEA’s ODS, not just from the source request (resource ID). Web hook gets the last part, but doesn’t automatically solve the other three problems.
• What about subscription? A little different than a webhook, as the SEA is asking for the data instead of the vendor telling the LEA when to push data via a webhook in the POST request.
• Which one is the closest? Option 4. But modify to have additional functionality in the ODS/API itself, with some kind of profile created by the district to control the data that will flow back out to the SEA. Is there any mechanism that the API could expose for the district to manage this easily? Not necessarily. Responsibility is the district’s, although might need a system integrator. To make it easy, need an administrative interface (GUI) that will define profiles and descriptor mappings (Ed Comer). Don’t make the LEA create XML files.
• Business rules should be applied at the back end on granular data. Local mapping to state mapping….
  
  

Closing notes… need to be careful to avoid making Ed-Fi even more complex that it already is.

Additional ideas? Send to Silvia Brunet-Jones at MSDF.