Uitwisseling leerlinggegevens en resultaatgegevens
Keteninrichtingsscenario[bewerken]
Dit keteninrichtingsscenario omvat de uitwisseling van leerlinggegevens en resultaatgegevens in de context van de afname en verwerking van toetsen en examineren. In functioneel opzicht zijn er drie belangrijke soorten systemen te onderscheiden:
- Administratiesysteem onderwijsdeelnemer: het leerling- of studentadministratiesysteem dat de bron is voor leerlinggegevens en dat resultaatgegevens nodig heeft ten behoeve van verdere verwerking
- Resultaatcreërend systeem: het toetsafnemende systeem dat de bron is voor resultaatgegevens, en dat leerlinggegevens nodig heeft ten behoeve van de afname
- Resultaattonend systeem: een systeem dat resultaat- en leerlinggegevens ontvangt met als doel deze gegevens te presenteren.
De uitwisselingen die in dit kader plaatsvinden kunnen diverse vormen aannemen, maar deze vormen kunnen allemaal worden teruggebracht naar een uitwisseling tussen twee of tussen drie partijen. De meest eenvoudige uitwisseling is die tussen een LAS en een aanbieder van een resultaatcreërend systeem. De interactie die tussen deze partijen plaatsvindt is
- Informatie over leerlingen en klas- of groepsstructuur gaat van LAS naar aanbieder.
- Resultaatgegevens gaan van aanbieder naar LAS.
Deze uitwisseling kan worden uitgebreid met een derde partij, die de voortgang- en resultaatgegevens ontvangt en deze namens de onderwijsinstelling verwerkt tot overzichten en rapportages. De interactie die plaatsvindt is
- Informatie over leerlingen en klas- of groepsstructuur gaat van LAS naar aanbieder van het resultaatcreërend systeem
- Informatie over leerlingen en klas- of groepsstructuur gaat van LAS naar aanbieder van het resultaattonend systeem.
- Resultaatgegevens gaan van aanbieder van het resultaatcreërend systeem naar het LAS.
- Resultaatgegevens gaan van aanbieder van het resultaatcreërend systeem naar de aanbieder van het resultaattonend systeem.
Er is een variant van bovenstaande interactie mogelijk, waarbij de informatie over resultaten niet vanuit de aanbieder van het resultaatcreërend systeem, maar vanuit het LAS verloopt. Voor een derde partij die analyses maakt is over het algemeen echter meer en gedetailleerdere informatie nodig dan dat het LAS zelf ontvangt. In bovenstaande figuur zijn de gegevensstromen die samenhangen met toegang niet weergegeven. Ook gelijkaardige gegevensstromen buiten het domein van Toetsen en examineren - zoals uitwisseling van gegevens van LAS naar LAS in het kader van overstap van een leerling naar een andere school, of aanlevering van gegevens aan BRON in het kader van bekostiging - zijn niet in scope van het toepassingsgebied en derhalve niet in het diagram opgenomen.
Een belangrijke verantwoordelijkheid van de onderwijsinstelling is het vanuit de Leerlingadministratie (LAS) c.q. het Studentinformatiesysteem (SIS) beschikbaar maken of verspreiden van gegevens over leerlingen, leerkrachten en groepen, voorzien van ECK IDs voor unieke identificatie van de leerlingen. Bovenstaande figuur geeft (bewust) niet de finesses weer die in beeld komen binnen specifieke uitwisselscenario’s. Afhankelijk van de scope van een dergelijk scenario, zal een verdere invulling van en aanvulling op de begrippen uit bovenstaande diagram kunnen worden gegeven, en zullen begrippen als bijvoorbeeld dashboards, LVSen, educatieve applicaties of methodetoetsen en de onderlinge gegevensstromen een plek krijgen.
De in dit hoofdstuk beschreven gegevensstructuren en interactiepatronen zijn toepasbaar voor die situaties waarin (a) resultaten in termen van de voortgang in ontwikkeling worden uitgewisseld, en (b) die uitwisseling niet (near) real-time is. Toepassingen die daarmee buiten de reikwijdte vallen van de hier beschreven structuren zijn het uitwisselen van voortgang in het leermateriaal, en realtime analyses zoals die bijvoorbeeld worden uitgevoerd gedurende de afname van een adaptieve toets. De uitkomsten van een dergelijke toets lenen zich echter wel voor uitwisseling met de beschreven structuren.
Tijdens de inventarisatie van use cases en het ontwerp van het gegevensmodel is meermaals gebleken dat er behoefte is aan het verbinden van planningsgegevens aan de hier beschreven gegevens die betrekking hebben op de toetsafname. Pogingen deze gegevens beter in kaart te krijgen zijn echter bij gebrek aan concrete input gestrand. Daarom is besloten dit type gegevens vooralsnog niet in het ontwerp op te nemen. Vanuit concrete uitwisselscenario’s waarin deze gegevens een rol spelen, in het bijzonder rondom centraal examineren / Facet, zullen oorstellen worden gedaan om de gegevensstructuren hierop uit te breiden.
Generieke interacties[bewerken]
Interacties worden beschreven in termen van aanbieder en afnemer van informatie, en in een interactiepatroon wordt expliciet gemaakt welke partij het initiatief neemt tot de uitwisseling. De vorige paragraaf laat zien dat zowel leerlingadministratiesystemen als resultaatcreërende systemen zowel aanbieder als afnemer van informatie zijn.
Alle uitwisselingen van deelnemer- en resultaatgegevens in het toepassingsgebied Toetsen en examineren kunnen worden ondersteund met een beperkt aantal interactiepatronen, opgebouwd uit de Edukoppeling transactiepatronen uit paragraaf 7.1. Deze interactiepatronen zijn:
- Request-Response
- Notify-Request-Response
- Push
Hieronder worden deze interacties toegelicht; de transactiepatronen uit Edukoppeling zijn terug te zien in de stereotyperingen (tussen guillemets) bij de pijlen in de diagrammen.
- Request-Reponse
.png)
In het diagram Uitwisseling deelnemergegevens (Request-Response) is weergegeven hoe de uitwisseling van deelnemergegevens kan worden ingericht. Een resultaatcreërend systeem vraagt de betreffende service die het LAS hiervoor beschikbaar heeft gesteld om deelnemer- en groepgegevens. Het resultaatcreërend systeem kan hierbij optionele argumenten voor filtering en versie opgeven. De service van het LAS valideert het verzoek en antwoordt met de gewenste gegevens. Partijen kunnen deze uitwisseling periodiek (bijvoorbeeld dagelijks) herhalen.
- Notify-Request-Response
Een variant op bovenstaande uitwisseling is weergegeven in het diagram Uitwisseling deelnemergegevens (Notify-Request-Response). Hier stuurt het LAS een notificatie aan de service van de aanbieder van het resultaatcreërend systeem dat er wijzigingen zijn. De notificatie kan een url en een korte tekst bevatten. Als de notificatie een url bevat, kan de afnemer deze gebruiken om de gegevensset direct op te halen. De aanbieder kan een korte tekst in de notificatie opnemen. De ontvanger gebruikt deze tekst en/of een filter in zijn verzoek voor informatie (bijv in de URL of in het SOAP request).
.png)
.png)
In de uitwisseling van resultaten van een oefening of toets, weergegeven in het diagram Uitwisseling resultaatgegevens (Notify-Request-Response), zijn de rollen van aanbieder en afnemer van informatie omgekeerd. Het LAS is afnemer en het resultaatcreërende systeem is de aanbieder van informatie.
Deze uitwisseling kan alleen zinvol plaatsvinden als het resultaatcreërende systeem een notificatie stuurt naar de onderwijsinstelling, met informatie dat resultaatgegevens beschikbaar zijn. Het LAS weet immers niet wanneer de toets is afgenomen en de resultaten geanalyseerd zijn. (Het alternatief van Polling, waarbij het LAS het resultaatcreërend systeem blijft bevragen tot er resultaten zijn, wordt in de Edukoppeling Architectuur een antipatroon genoemd en afgeraden).
- Push
.png)
Een alternatief voor een Notify-Request-Reponse-interactie is een Push-interactie, waarbij niet de melding niet een notificatie betreft, maar de te verwerken dataset. In bovenstaand voorbeeld stuurt het resultaatcreërend systeem een set van resultaatgegevens aan het LAS. Het LAS bevestigt vervolgens de verwerking ervan, Omdat dit een synchrone transactie betreft, is de toepasbaarheid van deze push-interactie sterk afhankelijk van de (mogelijke) grootte van de dataset, en de bijbehorende verwerkingstijd die het LAS nodig heeft. Als die verwerkingstijd te groot wordt, treden timeouts op.
Afweging[bewerken]
Uitwisselen op basis van een notificatie is voordelig in twee situaties. Zoals getoond in het voorbeeld van deelnemergegevens, is het gebruik van een notificatie interessant als het voor de aanbieder van de informatie minder complex is om wijzigingen in de gegevensset bij te houden en afnemers hierover te signaleren dan het verwerken van verzoeken van afnemers voor (potentieel ongewijzigde) informatie. Een tweede situatie waarbij notificaties kunnen worden gebruikt is als afnemers niet weten op welk moment informatie beschikbaar is en de aanbieder het wel weet. Een aanbieder kan met behulp van een notificatie een afnemer inlichten zodat deze niet hoeft te pollen, en kan met behulp van informatie in het notificatiebericht de afnemer helpen om de juiste gegevensset op te vragen.
Partijen kunnen bijvoorbeeld afspreken dat er notificaties worden gestuurd naar afnemers zodra leerlinggegevens zijn gewijzigd. Afnemers kunnen gegevens ophalen naar aanleiding van deze notificatie. Het notificatiebericht bevat een tekstveld waar de afzender een kenmerk in kan plaatsen, dat de afnemer van de gegevens opgeeft bij het ophalen van de referentiegegevens. Op deze manier kunnen partijen op maat gemaakte gegevenssets uitwisselen.
Behalve ophalen van gegevens na notificatie kunnen partijen opteren voor het periodiek ophalen van gegevens. Het verzoek ondersteunt het ophalen van gewijzigde gegevens sinds het opgegeven versienummer of versiedatum; als deze argumenten niet zijn opgegeven worden alle gegevens opgehaald. Met filterargumenten (specifiek voor de uitwisselcontext) kunnen partijen hierin nog een selectie in aanbrengen.
Notificaties[bewerken]
Het doel van een notificatie is een afnemende partij op de hoogte te brengen van het ontstaan van of beschikbaar komen van (mogelijk) relevante gegevens bij de aanbiedende partij. Denk voor afnemers van deelnemergegevens aan situaties als: een nieuwe leerling schrijft zich gedurende het jaar in, een leerling verlaat de school, er ontstaat een nieuwe klas of groep, een leerling verhuist naar een andere klas of groep, etc. Voor resultaatgegevens zijn situaties denkbaar als: het beschikbaar komen van resultaten en scores na afronding van een toets, het beschikbaar komen van gewijzigde scoregegevens na neutralisatie van items, het wijzigen van resultaten naar aanleiding van normering, etc.
Onderstaande diagram beschrijft de generieke structuur van een notificatiebericht.
In een notificatie wordt in ieder geval meegegeven op welk type gegevens de notificatie betrekking heeft. Zo weet de afnemende partij welke gegevens bevraagd moeten worden. Naar aanleiding van een notificatie kan een afnemende partij (een delta van) de complete gegevensset opvragen, maar het is ook mogelijk om middels een notificatie een fijnmaziger gegevensuitwisseling op te zetten. Zo kan de afnemer aan de hand van de typering van de notificatie beslissen of en met welke urgentie de nieuwe of gewijzigde gegevens opgehaald moeten worden. De typering is vocabulairegebonden, zodat de invulling en betekenis per context bepaald kan worden. Een bijgevoegde sleutel kan door de aanbiedende partij gebruikt worden in de verwerking van het eventuele vraagverzoek.
Over het gebruik, de betekenis en de afhandeling van meegegeven sleutels zullen per context – en waarschijnlijk per type notificatie – nadere afspraken gemaakt worden. Wanneer het bijvoorbeeld voor bepaalde typen notificaties absoluut noodzakelijk is dat de afnemende partij aan de notificatie opvolging geeft - denk aan gewijzigde resultaatgegevens naar aanleiding van normering - kan de sleutel gebruikt worden als ‘ontvangstbewijs’ en weet de aanbiedende partij, wanneer een verzoek met de destbetreffende sleutel binnenkomt, dat de afnemende partij de notificatie heeft ontvangen en verwerkt. Voor andere typen notificaties - zoals een notific#figur_leerlinggegevensatie die betrekking heeft op een specifieke leerling of groep - kan de sleutel gebruikt worden om naar aanleiding van het vraagverzoek alleen die gegevens terug te geven waarop de notificatie betrekking heeft. Zo wordt het onnodig versturen van (grote hoeveelheden) data voorkomen.
ROSA Gegevensmodellen[bewerken]
Dit keteninrichtingsscenario maakt gebruik van de volgende ROSA gegevensmodellen: