Eigenschap:Scanbevindingen
Naar navigatie springen
Naar zoeken springen
Type eigenschap
:
Tekst
Geldige waarden
:
Meerdere waarden toegestaan
:
Nee
Weergave op formulieren
:
Tekstvak
Initiële waarde
:
Verplicht veld
:
Nee
Toelichting op formulier
:
Subeigenschap van
:
Geïmporteerd uit
:
Formatteerfunctie externe URI
:
Klik op de button om een nieuwe eigenschap te maken:
A
Een gezamenlijke voorziening die CA mogelijk maakt, dient “eigendom” van de sector te zijn, dit moet in termen van governance geregeld worden +
'''Eenmalige registratie, meervoudig gebruik'''
Voorziening CA maakt (her)gebruik van gegevens uit BRP/BRON, RIO en van centrale voorzieningen (DigiD)
'''Persoonlijke digitale ruimte'''
De studentomgeving binnen CA kan worden opgevat als persoonlijke digitale ruimte ihkv het aanmeldproces. +
Na identificatie worden persoonsgegevens (uit BRP) en vooropleidingsgegevens opgehaald bij BRON/DUO.
Gegevens over opleidingsaanbod worden via RIO naar CA overgebracht
Voorziening CA geeft BSN, Geboortedatum en Geslacht door aan SIS
Introductie van voorziening CA leidt tot harmonisatie van aanmeldinformatie
Gegevenssets worden beschreven in Bijlage 2 PvE. +
Een aspirant-student identificeert zich in de voorziening CA met een eID (DIGID). +
Het transferpunt stuurt alle 1e-jaar mbo-aanmeldingen (uit CA) en aanmeldstatussen (uit VVA) door naar de analyseomgeving meervoudig aanmelden. Daar worden de gegevens geanonimiseerd ten behoeve van analyse en rapportage meervoudig aanmelden.
Uitgangspunt is dat 100% van de aspirant-studentgegevens in/door de voorziening CA gaat i.v.m. inzicht in meervoudige aanmeldingen.
Ten behoeve van statistische analyses kan de ruwe data van aanmeldingen door de beheerder van CA worden geëxporteerd naar Excel.
Voor specificatie van de levering van gegevens CA naar SIS wordt verwezen naar Bijlage 2.. Deze bijlage 2 gaat over het wat, niet over het hoe (+maatregelen) van de levering.
“Zolang wordt gewerkt met geaggregeerde rapportages [...] is er vanuit de AVG geen bezwaar”. +
In het PvE zijn de processtappen van aanmelden door middel van use cases vormgegeven (PvE, p.3). +
Er zijn binnen het mbo reeds activiteiten en werkende voorzieningen gericht op digitaal aanmelden (DaMBO), Digitaal ondertekenen (pilots worden opgeschaald) en de overdracht van leerdossiers (in de regio).
In het kader van nieuwe wetgeving wordt een Voorziening Vroegtijdig Aanmelden (VVA) ingericht (voor wat betreft het mbo ook wel ‘mbo-koppelpunt’ genoemd).
De voorziening CA heeft een directe relatie met de Voorziening Vroegtijdig Aanmelden (VVA) en met de student informatie systemen (SIS) van de instellingen. +
Collectieve (mbo-)voorziening Centraal Aanmelden
Sterke wens vanuit instellingen om inzicht te krijgen in meervoudige aanmeldingen
Informatiebehoefte rondom meervoudig aanmelden speelt op drie niveaus: instelling, regionaal, landelijk (sectoraal). +
Centraal Aanmelden staat ten dienste van alle bekostigde instellingen; 55 instellingen
nemen deel aan het PvE. PvE dient als vertrekpunt voor oplossing door geïnteresseerde (markt)partijen.
Het beheer en eigenaarschap wordt ondergebracht in de coöperatieve vereniging MBO-Voorzieningen, die in handen is van de deelnemende instellingen.
[[DUO]] levert gegevens aan CA, via een soortgelijke koppeling als SIS/BRON. +
Volgens het pitchdocument is beheer en doorontwikkeling belegd bij CvTE in samenwerking met DUO. +
De inhoud van CEVO raakt alleen VO, maar met de toepassing van AMIGO is er ook rekening mee gehouden dat MBO een vergelijkbare aanpak kan implementeren. +
Uit de tekst onder het kopje implementatie blijkt dat CvTE, DUO, CITO en LAS leveranciers binnen het VO met de afspraak te maken krijgen. (Bron: https://www.edustandaard.nl/standaard_afspraken/cevo/schooljaar-2021-2022/ Implementatie) Welke verschillende belangen deze groepen hebben werd niet duidelijk uit de documentatie.
Uit de documentatie werd niet duidelijk hoe alle groepen belanghebbenden bij het beheer van de afspraak betrokken worden.
Op de Edustandaard website wordt onder het kopje “Samenhang” beschreven dat er samenhang is met andere afspraken (Bron: https://www.edustandaard.nl/standaard_afspraken/cevo/schooljaar-2021-2022/ Samenhang) +
Op de Edustandaard webpagina staat dat informatiemodellen zijn ontwikkeld conform de AMIGO methodiek. Te zien is bijvoorbeeld vanaf slide 15 van de CEVO documentatie hoe ROSA informatiemodellen worden omgezet tot een technischer berichtenmodel. Trace relaties worden gebruikt om de semantiek direct traceerbaar te houden naar de ROSA informatiemodellen.
Op de Edustandaard site staat er dat het actuele Edukoppeling REST/SaaS-profiel is toegepast. Om te voldoen aan het Edukoppeling REST/SaaS-profiel zijn de juiste attributen toegevoegd. Bijvoorbeeld het “edu-from”attribuut. (Bron: CEVO definitiedocument) +
Alleen in de uitwisseling van kandidaatgegevens, afnameleiders en planning worden onderwijs identiteiten uitgewisseld. Dit is ook de enige uitwisseling waar dit noodzakelijk is. Ook worden alleen noodzakelijke persoonsgegevens uitgewisseld.
(bron: slide 7 CEVO documentatie)
In CEVO wordt voor de onderwijsdeelnemeridentiteit een pseudoniem gebruikt in de vorm van een verwijzing naar ECKiD. Wanneer een examenkandidaat geen ECKiD heeft kan worden teruggevallen op een LAS key. (Bron: CEVO definitiedocument schema: Onderwijsdeelnemeridentiteit)
Voor uitwisseling van het LAS van de school Identificatie van een school gaat aan de hand van een BRIN code, authenticatie zit in Edukoppeling laag en voor autorisatie wordt het OSR gebruikt. (Bron:CEVO definities document) +
Volgens het pitchdocument wordt veel met persoonsgegevens gewerkt en zijn er bij Centraal examens VO strikte BIV eisen. Ook staat er dat er 2 soorten uitwisselingen zijn:
Openbare informatie, zoals toetscatalogus
Specifieke informatie, zoals scores & resultaten
In de documentatie valt niet terug te vinden welke BIV classificatie een attribuut heeft.
Volgens slide 3 van de CEVO documentatie wordt informatie over afnameleiders opgehaald uit Facet door een LAS. De informatie wordt niet opgeslagen waardoor de integriteit van de gegevens behouden blijft.
Alleen noodzakelijke persoonsgegevens worden uitgewisseld wanneer dit moet. Er worden bijvoorbeeld geen contactgegevens van onderwijsdeelnemers uitgewisseld. De voor en achternaam worden uitgewisseld wanneer een afnamegroep moet worden doorgegeven aan Facet. (Bron: CEVO definitiedocument schema afnamegroep)
Tijdens de afname van een examen worden de weergavekenmerken op het scherm van de examenkandidaat weergegeven zodat een afnameleider de identiteit van de kandidaat kan valideren, (Bron: CEVO definitiedocument schema weergavekenmerken) +
“Afspraken over de implementatie vindt plaats via periodieke overleggen en wordt ondersteund door een digitale projectomgeving (Microsoft Teams) met overlegdocumentatie, specificaties, ondersteunende documentatie, etc. en een discussieforum. Toegang tot deze projectomgeving is alleen voor betrokken partijen en geschiedt op uitnodiging.” (Bron: https://www.edustandaard.nl/standaard_afspraken/cevo/schooljaar-2021-2022/ Implementatie) +
CEVO gaat over de uitwisseling van gegevens met betrekking tot de afname (Bron: https://www.edustandaard.nl/standaard_afspraken/cevo/schooljaar-2021-2022/ Beschrijving) +
Volgens het pitchdocument zijn er nu 3 applicaties/systemen in de keten: Facet (Toetssysteem), Magister (LAS) en Somtoday (LAS)
Er is ook een relatie met het OSR, dit is nog geen Referentiecomponent in de ROSA. +
Volgens de Edustandaard website zijn er verschillende uitwisselingen voorzien binnen het logistieke ketenproces rondom de centrale examens VO (cevo):
* Publicatie van de centrale examens (toetscatalogus)
* Aanleveren van afnameplanningen
* Publicatie van examenvarianten met schaallengte en n-term (variantencatalogus)
* Overdragen van de leerlingscores en -resultaten +
Op basis van de Edustandaardwebsite kan worden vastgesteld dat de afspraak betrekking heeft op uitwisseling van examengegevens tussen een onderwijsinstelling in het VO en overheidspartijen als CvTE en CITO en DUO doet de implementatie. +
Met CEVO worden examens, afnamegroepen, afnameleiders, examenvarianten met daarbij normeringsinformatie en resultaatscores uitgewisseld (Bron: CEVO definitiedocument). Binnen afnamegroepen worden Examenkandidaten opgenomen met een onderwijsidentiteit. +
Paragraaf 1.2 van het PRD geeft een overzicht van interne en externe belanghebbenden en de rollen die zij t.o.v. de (ontwikkeling van de) voorziening hebben. In het Voorstel Governance is in meer detail een governancestructuur uitgewerkt inclusief verantwoordelijkheden en aansluitvoorwaarden. +
De dienst zal gebruik maken van eHerkenning voor toegang en ondertekenen. Daarnaast zal/zullen (delen van?) de dienst toegankelijk zijn via Entree. Beheerders van de dienst maken binnen Kennisnet gebruik van een eigen, interne, SSO-voorziening obv ADFS. +
Het PRD omvat een BIV-classificatie en een beschrijving van de te nemen beheersmaatregelen. +
Afbeelding 7 toont een informatiemodel met gegevensentiteiten voor de Dienst Verwerkersovereenkomsten. Hierin staan o.a. de volgende elementen:
* Onderwijsinstelling
* Leverancier
* Verwerkingsactiviteit
* Digitaal onderwijsmiddel (product/dienst)
* Verwerkersovereenkomst
Definities bij de entiteiten ontbreken. +
Paragraaf 3.2 stelt dat de componenten een mogelijk toekomstbeeld schetsen, maar dat in de huidige opzet het de bedoeling is dat alleen verwerkersovereenkomsten worden geregistreerd.
De mapping op FORA in diezelfde paragraaf is heel breed, en benoemt o.a. invulling van ‘registratie van verwerkingsactiviteiten’ als functie die door de voorziening wordt ondersteund.
Afb. 5 (e.v.) toont verschillende doelen, waaronder ‘Applicatielandschap inzichtelijk maken’.
Afb. 6 toont dat diverse gerelateerde functies die geleverd moeten worden door verschillende voorzieningen (Dienst Verwerkersovereenkomsten, Dienst Product Catalogus, Kennisnet Authenticatiehub, Interne Registers en Kantoorautomatisering) samen invulling geven aan het ‘gesloten domein’.
Afb. 15 toont een fasering voor oplevering van verschillende componenten. +
“De dienst verwerkersovereenkomsten brengt leveranciers en schoolbesturen samen en stelt hen in staat om onderling in een besloten omgeving hun verwerkersovereenkomsten met elkaar af te stemmen en te ondertekenen. Daarnaast biedt het beiden overzicht van alle verwerkersovereenkomsten die zijn afgesloten.” +
Het pitchdocument positioneert de Dienst Verwerkersovereenkomsten als “basisvoorziening voor het funderend onderwijs”. +
[[Id-b269d84e-d15b-4c83-8946-7a69013c288d|'''Koppelen - niet kantelen''']]
“Entree Federatie zorgt ervoor dat digitale identificatie en authenticatie zo min mogelijk het onderwijsproces onderbreken.” Deze doelstelling uit H2 van de Marktverkenning (2), sluit aan bij het ROSA Basisprincipe Koppelen - niet kantelen.
[[Id-72b6fd75-30af-471e-870e-61f115023421|'''Een gezamenlijke basisinfrastructuur:''']]
Het ROSA basisprincipe Koppelen - niet kantelen, wordt verder ingevuld door het leveren van een gezamenlijke basisinfrastructuur. Deze basisinfrastructuur realiseert de Entree Federatie door online authenticatie van gebruikers te centraliseren; “waarbij onderwijsinstellingen en dienstaanbieders met elkaar gekoppeld worden via een centrale voorziening” (Bron: H2 Marktverkenning (2))
'''Samenwerking met SURFconext:'''
SURFConext wordt in §4.3.2 van de Marktverkenning (2) genoemd als vergelijkbare partij met een andere doelgroep. In §6.3.1 van de Marktverkenning wordt OpenConext genoemd als de meest kansrijke optie om de vernieuwde Entree Federatie op te baseren. Dit is dezelfde open source software waar SURFConext op gebaseerd is. Uit de gesprekken met de Entree Federatie (5) bleek dat direct gebruik van SURFConext niet mogelijk is, omdat de Zeggenschappen te veel verschillen. In het bijzonder speelt daarbij de rol van instellingen in het ho als eigen ID-provider ten opzichte van scholen in het po en vo die in de regel het LAS c.q. de LAS-leverancier als ID-provider gebruiken.
De samenwerking tussen Kennisnet en SURF wordt aangemerkt als gemakkelijk te organiseren. Daarnaast, wordt erkend dat wanneer Kennisnet en SURF OpenConext doorontwikkelen, dit ook van waarde is voor een bredere doelgroep. +
Volgens de Pitch (4) blijft het beheer van de Entree Federatie belegd bij Kennisnet.
'''Alle belangen in kaart'''
H4 van de Marktverkenning (2) beschrijft de positie van alle groepen belanghebbende waaronder kennisnet zelf, verschillende groepen gebruikers concurrenten en leveranciers.
'''Betrokken belanghebbenden'''
In H4 van de Marktverkenning (2) worden de groepen belanghebbenden benoemd. Uit de gesprekken met de EF blijkt dat via programma start schooljaar SEM de communicatie verloopt. Scholen worden geïnformeerd via de nieuwsbrief van Kennisnet en later ook via de raden.
'''Bewaak relaties met andere afspraken'''
Het governanceproces rondom de Entree Federatie haakt aan bij bestaande governance- en opverlegstructuren met overlappende doelstellingen. Dit governanceproces is vanuit de Entree Federatie zelf lastig te sturen.
'''Aanvullend'''
Het onderwijsdomein kent geen stelselconformiteit als eis of randvoorwaarde. Hoewel dit strikt genomen buiten de scope van de ROSA-governanceparagraaf valt, onderkennen we dat gebrek aan een overkoepelend stelsel hier wel als risico. De werking van de federatie is uiteindelijk afhankelijk van de op intenties gebaseerde samenwerking tussen ketenpartijen. +
[[Id-8ed6b136-0982-4d5d-aab4-498c22c0e8b8|'''Behoeftegerichte en doelgebonden gegevensuitwisseling''']]
De EF biedt een manier om identiteit van een gebruiker uit te wisselen op het moment dat die gebruiker zich bij een systeem aanmeldt. Daarvoor wordt gebruik gemaakt van het SAML-protocol of OpenID-connect. De Entree Federatie is zelf geen gegevensbron voor identiteitsgegevens. Ook de attributen die via de Entree Federatie kunnen worden meegestuurd worden niet binnen Entree opgeslagen. De registratie en het gebruik van Attribute Release Policies ondersteunt het behoeftegericht en doelgebonden uitwisselen van deze gegevens.
‘Mijn Entree’ biedt een aantal APIs voor metadata en rapportage. Via de Mijn Entree APIs kunnen alleen publieke gegevens worden ontsloten.
Toepassing van de UBV-TLS afspraak wordt als vanzelfsprekend gezien. +
Het huidige Entree Federatie platform loopt tegen grens aan van het aantal authenticaties p.22 technische verkenning (1), daarnaast wil Kennisnet nieuwe technologieën op het gebied van Identity Management kunnen ondersteunen zoals SSO voor mobiele devices. [§2.2.2 van de Marktverkenning (2)]
[[Id-327e11bc-0d95-4d15-a39f-eafaf427e49d|'''Marktpartijen kunnen IAA-diensten leveren''']]
Volgens p.8 vd technische verkenning (1) maakt de Entree Federatie (EF) gebruik van een Hub-and-spoke model. Dit houd in dat de EF erin voorziet dat meerdere Service providers gebruik kunnen maken van identiteiten vanuit verschillende ID providers via een centrale hub.
[[Id-2f6998bd-7079-47a5-b0bc-b8ede6e298d5|'''Meerdere expliciete betrouwbaarheidsniveaus''']]
Op p.24 van de technische verkenning (1) staat de impact omschreven van het ondersteunen van betrouwbaarheidsniveaus op de Entree Federatie. ID providers zijn verantwoordelijk om deze betrouwbaarheidsniveaus in te stellen. Er zijn momenteel geen attributen ingericht om een betrouwbaarheidsniveau uit te wisselen binnen de Entree Federatie. +
'''AVG is drijfveer voor verbeteringen aan Architectuur:'''
In §2.2.2 van de Marktverkenning (2) wordt de AVG genoemd als één van de redenen waarom vernieuwing van de Entree Federatie (EF) nodig is. De AVG biedt gebruikers het recht op meer inzicht in en controle over hun gegevens. Met het huidige platform gaat dit lastig en is innoveren duur, aangezien deze gebaseerd is op verouderde technologie. Daarnaast speelt ook mee dat leerlingen tot 14 jaar zelf niet de verantwoordelijkheid over hun eigen identiteit dragen, waardoor de onderwijsinstelling daarvoor verantwoordelijk is.
[[Id-f4e449df-6504-462a-a23f-d7c6b29dcd2a|'''Duidelijke eisen en verwachtingen:''']]
Op P.11 van de technische verkenning (1) wordt het idee van de Attribute Release Policy service uitgelegd. Uit gesprekken met de EF (5) bleek dat iedere school met iedere service provider een eigen ARP afsluit. De scope van de Attribute Release Policy lijkt te passen bij de scope van Services waarvoor in het OSR mandaten worden vastgelegd. Scholen zullen voor een dienst zowel mandateringen in het OSR als ARPs voor Entree moeten vastleggen.. In de Developer documentatie (3) bestaat een [https://developers.wiki.kennisnet.nl/index.php?title=KNF:Attributen_overzicht_voor_Identity_Providers pagina] waar aanvullende attributen en richtlijnen op te vinden zijn. Uit brondocument (5) blijkt dat in de nieuwe situatie dit anders zal werken. Bij het aansluiten van een service provider kan de attributenset ingericht worden conform, bijvoorbeeld, het Attributenbeleid van Edu-K of andere relevante afspraken.
[[Id-9668c6ac-f646-44ee-b110-416bf1b9e423|'''Continuïteit van de dienstverlening:''']]
De uitgangspunten op p.14 technische verkenning (1) gaan in op een technische implementatie om de continuïteit van de dienstverlening te waarborgen. De maatregelingen om de continuïteit te waarborgen zijn goed uitgewerkt en zouden potentieel van toegevoegde waarde kunnen zijn voor de ROSA om de implicatie binnen het ontwerpkader te verrijken met voorbeelden.
“De Entree Federatie doet dit door online authenticatie van gebruikers te centraliseren, waarbij onderwijsinstellingen en dienstaanbieders met elkaar gekoppeld worden via een centrale voorziening. Dit geeft onderwijsdeelnemers de mogelijkheid om via Single Sign-On met het account van hun onderwijsinstelling in te loggen bij alle dienstaanbieders in het onderwijs. Op deze manier kunnen dienstaanbieders beschikken over betrouwbare onderwijsidentiteiten zonder met elke onderwijsinstelling aparte afspraken of koppelingen te hoeven maken.” [Bron: Context H2 Marktverkenning (2)]
Dienstaanbieders binnen het PO, VO en MBO kunnen zich aansluiten bij de Entree Federatie. De scope van de EF beperkt zich hierbij niet tot diensten ter ondersteuning van een beperkt aantal ketenprocessen. +
'''Gemeenschappelijkheid in informatiehuishouding'''
Binnen het onderwijs zijn al veel ketenpartijen die gebruik maken van RESTful gegevensuitwisseling. Deze maken nu zelfstandige keuzes hoe transport, logistiek en beveiliging ingericht moeten worden. Het profiel beoogt hier meer standaardisatie in door te voeren, waarbij met name invulling gegeven wordt aan het kunnen routeren tussen de rollen die in Edukoppeling t.b.v. SaaS worden onderscheiden. +
'''Relaties met andere standaarden'''
* UBV (zie ook [[AS EK-REST IBP|onderdeel IBP]])
* Voor transparante intermediair, onweerlegbaarheid, en/of uitwisseling obv XML: toepassen Edukoppeling WUS-profiel
* OOAPI: onduidelijk of Edukoppeling-rollen hierin onderkend worden
* Inbedding in nationale (overheidsbrede) standaarden. Basis wordt gevormd door afspraken en voorschriften uit de landelijke API-strategie. Enige mate van ontkoppeling via MoSCoW-classificering.
* Op p.6 wordt XML over REST niet toegestaan, volgens API-24 is het een eigen afweging (COULD). +
Must: Gebruik van openbare internet “Overigens kan Edukoppeling ook toegepast worden in gesloten netwerken.”. Tegenspraak? Hoe ‘must’ te lezen?
'''Foutafhandeling:'''
* Architectuur definieert categorieën A t/m E In 3.1.8 alleen foutmeldingen voor cat. A t.a.v. syntax to/from-routeringskenmerken. → hoe passen de andere categorieën op HTTP statuscodes? +
* Identificatie/authenticatie verwerker obv OIN / PKI-infrastructuur (P2P).
* Eindorganisaties worden geïdentificeerd via routeringskenmerken (TO, FROM)
* Inzet van transparante dienstverleners wordt (nog) niet ondersteund (daarvoor: WUS)
* Verplicht gebruik Onderwijsserviceregister
* Verwijzing naar ontwikkelingen OAuth in bijlage A.
* Gebruik van API-sleutels geen onderdeel van het profiel, maar wel toegestaan
** Voor API-key (geen onderdeel profiel) stroomschema’s en mogelijke 401/403-foutcodes. Zoiets mist voor afhandeling van ‘from-OIN’ en OIN verwerker (P2P) .
+
* TLS (wordt verwezen naar UBV)
Vertrouwelijke gegevens in GET-parameters
* P.13: ‘dienen gepseudonimiseerd te zijn’
* P.18: igv persoonsgegevens ‘kunnen aanvullende beveiligingsmaatregelen toegepast worden, zoals adequaat versleutelen en/of voorkomen ongewenste logging dmv filter’.
+
M2M-gegevensuitwisseling via een beveiligde point-to-pointverbinding waarbij RESTful standaarden voor gesloten (access-restricted en purpose-limited) APIs worden toegepast (zowel pull als push). +
Gehele onderwijsdomein (cf. organisatorisch werkingsgebied zoals beschreven in Edukoppeling architectuur). +
Volgens de Pitch en de Edustandaard website is het beheer van de FDE-set belegd Bij de werkgroep “ECK Distributie en Toegang”. +
EDEXML is de standaard voor de uitwisseling van administratieve gegevens van leerlingen met bijbehorende gegevens over groepen en leerkrachten. (bron: FDE-set v1.1 §1.2) EDEXML sluit qua begrippen niet perfect aansluit bij het VO en MBO en er zijn wensen tot uitbreiding, daarom is de FDE-set ontwikkeld. (Bron: https://www.edustandaard.nl/standaard_afspraken/fijndistributie/fde-set1-0/ alinea 3) +
“In dit profiel zijn om praktische redenen de ontwikkelingen rondom RIO en AMIGO buiten de specificaties gelaten. De gedachte hierbij is dat deze ontwikkelingen nog niet volledig geïmplementeerd zijn en op dit moment nog pending zijn.” (Bron: https://www.edustandaard.nl/standaard_afspraken/fijndistributie/fde-set1-1/ ) Het is onduidelijk uit de documentatie wat de verwachte impact zal zijn van het toepassen van de AMIGO methodiek.
Uit de lijst aanvullende documenten in FDE-set v1.1 §1.4 kan worden opgemaakt dat er relaties bestaan tussen de FDE-set en andere afspraken. Hoe deze bewaakt worden wordt niet duidelijk uit de documentatie.
Volgens p.1 van FDE-set v1.1 is het beheer van de FDE-set belegd bij de werkgroep Distributie en toegang. Of de werkgroep de groepen belanghebbende in kaart heeft gebracht werd niet duidelijk uit de documentatie. +
In FDE-set §2.5 worden aanvullende gegevens in de vorm van werkingsregels en eisen op EDEXML beschreven. Zie ook Bijlage 2 van de ROSA scan voor een overzicht. Ook worden alle gegevens gedefinieerd.
In FDE set §2.2 staat dat de beveiliging van de uitwisseling wordt geboden door de onderwijstransactiestandaard Edukoppeling.
Het is onduidelijk uit de documentatie hoe er wordt omgegaan met internationale adressen. Dit wordt binnen verschillende registraties anders gedaan. RIO sluit bijvoorbeeld aan bij de NEN door het huisnummertoevoegingNEN veld toe te voegen. +
“Distributeur Applicatie (DA) zich gedraagt als de Educatieve Applicatie (EA) in de stap 1 van UWLR scenario 2 waarbij als identifier van de leerling het ECK iD moet worden gebruikt. De DA stuurt een verzoekbericht aan het LAS om leerlinggegevens, het LAS reageert met de gevraagde Leerlinggegevens.” (Bron FDE-set §2.3)
Het ECK iD wordt gebruikt om een leerling mee te identificeren. Wanneer deze niet beschikbaar is kan worden teruggevallen op een LAS-key. Er zit ook een gebruikersnaam bij leerlinggegevens. +
Volgens de Pitch worden veel persoonsgegevens of bijzondere
persoonsgegevens verwerkt met toepassing van de FDE-set. Welke van de attributen dit zijn valt wel te achterhalen in de specificatie, maar is niet direct aangegeven met een BIV classificatie.
“met de komst van het ECK iD is het noodzakelijk om een andere route te kiezen die voldoet aan de eisen die vanuit IBP hieraan worden gesteld.” (bron: FDE-set v1.1 §2.2) De documentatie stelt dat deze eisen worden ingevuld door het ECK-iD toe te voegen aan een EDEXML-profiel in combinatie met het toepassen van Edukoppeling.
De berichtenuitwisseling bouwt voort op UWLR. (Bron: FDE-set v1.1 §1.3) Er zijn 2 varianten mogelijk: alles in 1 of getrapt. (Bron FDE-set §2.3) Deze varianten bieden geen mogelijkheid om het ECK-iD los van de persoonsgegevens uit te wisselen. Beide hebben we een ander doel. ECK iD zit in de FDE-set voor digitale toegang en persoonsgegevens (zoals adressen) voor distributie van fysiek lesmateriaal.
In de specificatie van de FDE-set worden geen richtlijnen gesteld voor afnemers over hoe de traceerbaarheid van het pseudoniem “ECK iD” naar persoonsgebonden gegevens (zoals adresgegevens) kan worden voorkomen. Edukoppeling moet tijdens de uitwisseling voor beveiliging zorgen, maar wanneer de gegevens worden opgeslagen in een registratie, zou dit voor ongewenste traceerbaarheid kunnen zorgen. +
Realisatie wordt ingeschat als gemiddeld in de pitch. Uit de documentatie wordt niet duidelijk wat de onderkende risico’s zijn bij implementatie. Steeds meer uitwisselingen worden in OSR gemandateerd, dus zou voor verwarring kunnen zorgen aangezien OSR niet gebruikt wordt bij de FDE-set. +
De afspraak raakt volgens de Pitch een enkele of slechts een zeer beperkt
aantal ketenprocessen. Op basis van FDE-set v1.1 §2.1 kan worden gesteld dat het hier gaat om een profiel voor het uitwisselen van educatieve content behalve toetsen. +
Leerlingadministratiesysteem (LAS) en Distributeur Applicatie (DA) worden genoemd in §2.4. In ROSA wordt de term [https://rosa.wikixl.nl/index.php/Id-e3c985fa-04dd-4abe-a491-509791e25b7f Distributeursportaal] gebruikt voor Distributeur Applicatie. +
FDE-set is een profiel dat kan worden toegepast voor de uitwisseling van leerlinggegevens die fijndistributie van leermiddelen(behalve toetsen) voor distributeurs mogelijk maakt. Het voegt een profiel toe hiervoor bovenop EDEXML, (bron: FDE-set v1.1 §2.1)
Uit de documentatie werd niet duidelijk waar de afkorting “FDE” voor staat. De naam verliest daarom wat betekenis. +
De FDE-set voor fijndistributie is een profiel voor het VO en MBO op EDEXML gebruikmakend van de UWLR-uitwisseling van leerlinggegevens.
EDEXML is de standaard voor de uitwisseling van administratieve gegevens van leerlingen met bijbehorende gegevens over groepen en leerkrachten. EDEXML is bedoeld voor het primair en voortgezet onderwijs. (bron: https://www.edustandaard.nl/standaard_afspraken/edexml/edexml-2-1/ ) +
Uit de gesprekken met de FDE-set bleek dat zeggenschappen zijn belegd, maar deze zijn niet omschreven in documentatie. Informatieobjecten staan in Bijlage 2 van deze Scan. +
Er wordt een apart ontwikkeltraject opgestart voor verdere aansluiting op ontwikkelingen rondom RIO, AMIGO en ROSA-gegevensmodellen en Edukoppeling-profielen. +
De afspraak is gericht op het op een gestandaardiseerde wijze uitwisselen van leerlinggegevens tussen LAS/SIS van een VO-school en een distributeur. +
De afspraak is gebaseerd op UWLR 2.3 en daarmee inclusief EDEXML 2.1. De afspraak is “verder niet afhankelijk van beide betrokken afspraken” (paragraaf 2.1).
Ten opzichte van v1.1 is een Governance-paragraaf toegevoegd (2.8), waarin de adviezen uit de vorige architectuurscan zijn vewerkt. In het colofon is informatie opgenomen over de betrokken groepen belangjhebbenden en de wijze waarop zij zijn betrokken. +
Paragraaf 2.5 beschrijft de gegevens en werkingsregels binnen het profiel FDE-set. Ten opzichte van v1.1 is een aantal wijzigingen aangebracht, waaronder:
* Toevoeging van DigideliveryID bij School en FDE-vestiging
* Vestigingsinfo hernoemd naar FDE-vestiging
* Samengestelde groep (vak/keuzegroep) hernoemd naar Vakkengroep
* Leerling-/studentnr toegevoegd bij Leerling
* Blok ‘Plaatsing’ toegevoegd
* Blok Adres gespecificeerd.
* Deze wijzigingen zijn niet backwards compatible.
De relatie met RIO is in v1.2 duidelijker beschreven. +
De werkingsregels voor het gebruik van identiteiten van identiteiten van een leerling zijn in deze versie gewijzigd ten opzichte van v1.1. In versie 1.1 was het uitgangspunt het gebruik van ECK-iD om een leerling te identificeren, met mogelijk terugvallen op een LAS-key wanneer ECK-iD niet beschikbaar is.
<br>
In versie 1.2 is het gebruik van LAS-key verplicht gesteld, en moet in aanvulling daarop het ECK-iD worden meegegeven als dat beschikbaar is; in dat geval moet het ECK-iD als identificatie worden gebruikt (paragraaf 2.5.5 Leerlinginfo). Daarnaast is een (verplicht) Leerling-/studentnr aan het gegevensblok Leerling toegevoegd. +
Naar aanleiding van de Architectuurscan op v1.1 van de FDE-set is een paragraaf 2.7 IBP toegevoegd. +
In het project Revisie ROSA is een implementatie-onafhankelijk ketenproces rondom Leermiddelen en Leermateriaal uitgewerkt dat model staat voor de specifieke invulling van het proces in verschillende ketensamenwerkingen.. +
De FDE-set voor VO onderscheid LAS en DA (distributeurapplicatie). +
FDE-set is een profiel op EDEXML voor de uitwisseling van leerlinggegevens ten behoeve van de fijndistributie (FDE) bij het ditributie-/levereingsproces door een distributeur. +
Het profiel is ingeperkt tot werkingsgebied voortgezet onderwijs (vo). Versie 1.1 had als werkingsgebied vo + mbo. Voor mbo zal een apart profiel gemaakt moeten worden.
<br>
Op [https://www.edustandaard.nl/standaard_afspraken/fijndistributie/fde-set1-2/ de Edustandaard website] wordt op dit moment nog zowel vo als mbo aangeduid als werkingsgebied. +
Paragraaf 2.1 (Scope) beschrijft de rol van distributeurs en scholen in het proces, inclusief het beheer/’eigenaarschap’ over leermiddelen. Deze paragraaf laat ook de inforamtiestromen tussen deze rollen zien vanuit LAS (school) naar DA (distributeur) +
De PrSA (3.5) bevat bedrijfsprincipes. Principe BP07 geeft aan dat DUO zich inzet voor transparantie door stakeholders op verschillende momenten in het proces te informeren. Dit omvat voorafgaande informatie, updates tijdens het proces, en achteraf inzage in relevante informatie. DUO informeert stakeholders ook over het procesverloop, de regels, de gebruikte gegevens en het (mogelijke) resultaat van de gevraagde dienst.
Volgens Artikel 23 van de [https://wetten.overheid.nl/jci1.3:c:BWBR0042012&hoofdstuk=2¶graaf=2.3&artikel=23&z=2023-01-01&g=2023-01-01 Wet register onderwijsdeelnemers] kunnen basisgegevens worden verstrekt aan verschillende onderwijsverenigingen, waaronder de Vereniging PO-Raad te Utrecht, de vereniging VO-raad te Utrecht, de vereniging MBO Raad te Woerden, de Vereniging Hogescholen te Den Haag, en de Vereniging Universiteiten van Nederland te Den Haag.
In het PrSA komen de termen “leverancier”, "bronhouder” en “data provider” op meerdere plekken terug. Basisgegevens kunnen worden verstrekt aan verschillende onderwijsverenigingen volgens wet WRO, De PrSA van GABI benoemt deze organen niet. Ze worden alleen kort benoemd in de PSA documenten voor SANE en MDP. +
Het PrSA (5.2) document beschrijft drie afzonderlijke functies die in samenhang ook wel worden aangeduid met Identity and Access Management (IAM): Identificatie, Authenticatie en Autorisatie. Hoewel deze functies duidelijk worden gedefinieerd, is het niet duidelijk hoe ze in de praktijk worden geïmplementeerd en hoe ze met elkaar samenwerken om een veilige en efficiënte toegangscontrole te waarborgen. +
In het Project Start Architectuur (PrSA) document, specifiek in sectie 4.4, wordt het principe van "Gegevens bij de bron" en "Enkelvoudig beheer, meervoudig gebruik" benadrukt. Dit principe is in lijn met Artikel 23 van de Wet register onderwijsdeelnemers (WRO), waarin staat dat persoonsgegevens kunnen worden verwerkt indien dit noodzakelijk is voor de genoemde doelen.
Verder wordt in het PrSA document, onder principe BP05, gesteld dat de stakeholders van DUO erop kunnen vertrouwen dat informatie, en de onderliggende gegevens, goed worden beschermd. Dit omvat bescherming tegen inbreuken op de beschikbaarheid, integriteit, vertrouwelijkheid, duurzame toegankelijkheid en rechtmatig gebruik tijdens de verwerking van informatie en onderliggende gegevens.
De gegevensbeveiliging wordt ingevuld door verschillende services, waaronder de Minimaliseren gegevens service (Enterprise Data Hub), Meta-gegevens service (Metadata Publicatie), Gegevens kwaliteit service (Enterprise Data Hub), en Gebruikersomgeving beheer service (SANE). +
In het Project Start Architectuur (PrSA) document worden twee principes benadrukt: "Gegevens enkelvoudig en uniform beschreven" en "Gegevensbeschrijvingen van de bron" (PrSA, 4.4). Deze principes onderstrepen het belang van het hebben van duidelijke definities voor gegevens. Voorbeelden hiervan zijn de definities voor Access Management (PrSA, 5.2): "Het vaststellen dat een subject (persoon of systeem) de juiste rechten om een object te benaderen" en Identity Management: "Het beheren van de identiteiten van gebruikers, hun rollen, autorisaties en authenticatiegegevens."
Het PrSA document (sectie 1.1) inventariseert de kaders, principes, richtlijnen, standaarden en normen die relevant zijn voor het project en schetst de implicaties van deze kaders voor de oplossing die het project gaat realiseren. Een specifiek principe dat wordt benadrukt is dat DUO standaardiseert processen, gegevens en ondersteunende applicaties en IT technologie, en daarbij open standaarden gebruikt en aansluit op referentiearchitecturen van de overheid, in dit geval specifiek HORA / HOSA (PrSA, 3.6). Ook wordt gezegd dat MIM wordt toegepast. Welke Edustandaard afspraken worden geraakt wordt niet duidelijk uit de documentatie. +
In paragraaf 3.3 van het Project Start Architectuur (PrSA) document is een functiemodel uitgewerkt. Uit dit model blijkt dat het voornamelijk gaat om interne processen van DUO. Dit beeld is consistent met de bedrijfsarchitectuurmodellen die zijn opgenomen in de begeleidende Project Start Architectuur documenten.
Zie bevinding werkingsgebied WRO artikel 23. Een verstrekking van basisgegevens is toegestaan voor zover dit noodzakelijk is voor de ondersteuning van onderwijsinstellingen en samenwerkingsverbanden bij hun verantwoording omtrent de kwaliteit, toegankelijkheid of doelmatigheid van het onderwijs. In WRO artikel 10 staat: “De basisgegevens omvatten, naast de identificerende gegevens, bedoeld in artikel 9, in elk geval gegevens met betrekking tot:
a.de onderwijsinstelling waar de onderwijsdeelnemer is of was ingeschreven;
b.de datum van in- en uitschrijving bij de desbetreffende onderwijsinstelling.” +
In het PrSA document (sectie 4.2) worden drie soorten applicaties onderscheiden, elk met hun specifieke verantwoordelijkheden:
# Bron gegevens platformen: Deze zijn verantwoordelijk voor de extractie van gegevens uit de oorspronkelijke bron en de integratie van deze bronnen met de Data Hub.
# Distributie platformen: Deze zijn verantwoordelijk voor de distributie van gegevens naar de afnemende platformen. Ze voeren ook de benodigde transformaties uit om de gegevens geschikt te maken voor de afnemers, waaronder gegevensharmonisatie (transformatie), mastering en verrijking met metadata.
# Afnemer platformen: Deze zijn verantwoordelijk voor het gebruik van de gegevens uit de distributie platformen. Dit kan bijvoorbeeld een gebruikersinterface zijn voor metadata zoals een begrippencatalogus of een gegevenscatalogus, of een gevirtualiseerde omgeving die wordt gebruikt om gegevens te gebruiken met behulp van visualisatietools of programmeertools. +
Het werkingsgebied van GABI wordt in de Pitch beschreven als het gehele onderwijsdomein. In paragraaf 2.1 van de PrSA document wordt het doel van BI gedefinieerd als het helpen van DUO om informatie-inzichten te verkrijgen die kunnen worden gebruikt om de prestaties te verbeteren en rechtmatigheid aan te tonen. Uit verder onderzoek naar de drijvende factor achter GABI, de wet WRO, blijkt dat alle onderwijsraden worden geraakt door de invoering van de wet en dus ook door invoering van GABI, wat onderdeel gaat worden van de uitvoering van de wet.
GABI lijkt een realisatie van de Onderwijsgegevensplatform ketenarchitectuur die eerder is gescand en behandeld tijdens AR 14 april 2022. In die scan was het werkingsgebied onduidelijk en leek het vooral om een DUO architectuur te gaan. De uitwerking van de architectuur van GABI in de brondocumenten lijkt deze aanname te bevestigen. +
In de brondocumenten van het GABI worden gegevens niet nader gespecificeerd. Echter, door de verwijzing naar de Wet register onderwijsdeelnemers (WRO), kan worden afgeleid dat het waarschijnlijk gaat om de volgende gegevenssoorten: Basisgegevens deelname, Basisgegevens persoon, en Basisgegevens resultaat.
Er bestaat een doorstroommonitor afspraak (https://www.edustandaard.nl/standaard_afspraken/doorstroommonitor/doorstroommonitor-6-0/), beheerd door de Werkgroep Doorstroommonitor. In de doorstroommonitor staat dat gegevens worden aangeleverd door DUO. Dit kan mogelijk geraakt worden door WRO artikel 23, indien het hier gaat om basisgegevens. In de specificatie van de Doorstroommonitor (https://www.edustandaard.nl/app/uploads/2017/05/Specificatie-6.0-van-de-afspraak-Doorstroommonitor.pdf) staat bij de definitie van deelnemerkenmerken dat het om gegevens gaat met betrekking tot de onderwijsinstelling waarbij een onderwijsdeelnemer was ingeschreven en de datum van in- en uitschrijving.
Dit komt overeen met WRO artikel 10, dat stelt dat de basisgegevens, naast de identificerende gegevens, in elk geval gegevens omvatten met betrekking tot de onderwijsinstelling waar de onderwijsdeelnemer is of was ingeschreven, en de datum van in- en uitschrijving bij de desbetreffende onderwijsinstelling. +
De verantwoordelijkheid voor het beheer van de HOVI standaard ligt volgens het Governance document bij de stuurgroep. Momenteel is de opdrachtgever Studiekeuze123, maar dit kan veranderen naar een andere partij volgens het Governance document. Afstemming op andere afspraken binnen de onderwijsketen, zoals RIO, wordt nu gedaan volgens de Hovi website door nauwe samenwerking met het projectleiderschap of wordt, zoals bij de OO-API gedelegeerd naar de softwarebouwer. Hoe deze afstemming tijdens de beheerfase of bij verandering van opdrachtgever gaat verlopen, is nergens in de gescande documenten terug te vinden. +
'''Is er een relatie tussen HOVI en RIO?'''
RIO (Registratie Instellingen en Opleidingen) is het nieuwe CROHO. RIO bevindt zich nog in de ontwerp-fase. Binnen RIO krijgen de instellingen gelegenheid om de eigen onderwijswerkelijkheid weer te geven op een centrale plek, gekoppeld aan de formele registers zoals die nu onderdeel zijn van CROHO. Met de projectleiding van RIO wordt gedurende de ontwikkeling van HOVI intensief afgestemd, zowel inhoudelijk als planmatig.
'''Is er een relatie tussen HOVI en OO-API?'''
De Open Onderwijs API is een open standaard voor het delen van onderwijsdata. Een API (Application Programming Interface) is een set definities waarmee softwareprogramma’s onderling kunnen communiceren. Aansluiting op deze standaard is één van de opdrachten aan de HOVI-ontwikkelaars. (PvE p.21) Uit een vergelijking van de HOVI API en OO-API bleek echter dat deze niet dezelfde begrippen hanteerde.
'''Eenmalige registratie meervoudig gebruik:'''
Uit de HOVI Specificatie (p.3) valt af te leiden dat de HOVI als centrale database voor studiekeuzeinformatie wil fungeren. Onderwijsinstellingen kunnen op HOVI zelf informatie over hun onderwijsaanbod beheren. (Governance p.7) Afnemers kunnen deze informatie van deze centrale plek afnemen. Uit een gesprek met Studiekeuze123 is gebleken dat wanneer RIO voor het HO gaat gelden, de HOVI zich bij RIO aansluit. Hierdoor zal worden voorkomen dat ketenpartijen twee keer moeten aanleveren. +
Informatie met betrekking tot governance van de HOVI valt te halen uit de documenten “Governance HOVI.pdf” en “200805 Afnemers.pdf”.
Alle belangen in kaart & Geclusterde belanghebbenden: In het Afnemers document van de HOVI worden afnemers in kaart gebracht en worden deze ook in een aantal groepen onderverdeeld.
Betrokken belanghebbenden: Met name studiekeuzevoorlichtingpartijen worden door HOVI benaderd over de impact die de verandering van HODEX naar HOVI gaat hebben. (Afnemers p.1) Onder het takenpakket van de HOVI stuurgroep valt het organiseren van de communicatie rondom en vanuit het programma. (Governance p.6)
Bewaak relaties met andere afspraken: Uit het Governance document wordt niet duidelijk hoe relaties worden bewaakt met andere afspraken. Het bewaken van relaties van met andere afspraken binnen de keten (bijvoorbeeld RIO) wordt niet als taak van de stuurgroep genoemd. Wel wordt er in het aanbestedingsdocument (P21) de vraag bij de softwarebouwer neergelegd om met een architectuur te komen die aansluit op lopende ontwikkelingen zoals RIO en OO-API. Het wordt niet duidelijk uit voor ons beschikbare documentatie hoe de aannemer invulling heeft gegeven aan deze vraag. +
Openbare register gegevens worden ontsloten als Linked Open Data:
HOVI is geen openbaar register. Alleen geregistreerde afnemers kunnen met een key via de HOVI API data afnemen, wanneer ze akkoord gaan met de leveringsovereenkomsten. Gegevens worden niet ontsloten als LOD, maar via de HOVI API.
'''Aansluiting op RIO'''
Parallel aan de ontwikkeling van de HOVI loopt ook de ontwikkeling van RIO. In het HOVI datamodel wordt er bij “organization” verwezen naar een BRIN nummer om de koppeling te leggen met het BRIN register. (de voorloper van RIO) De architectuur van de HOVI zal dus moeten kunnen aansluiten op lopende ontwikkelingen bij RIO. In het HOVI aanbestedingsdocument (p.21) wordt aan de inschrijver gevraagd om rekening te houden met aansluiten op ontwikkelingen bij RIO. Ook in de HOVI specificatie (p.6) wordt opgemerkt in een kanttekening dat mogelijk de definitie van een unieke croho code nog kan wijzigen na implementatie van DUO. Hoe deze veranderingen precies gefaciliteerd worden werd niet duidelijk uit de beschikbare brondocumentatie. Onder “veelgestelde vragen” op de HOVI website gesteld dat er intensieve afstemming is met de RIO projectleiding, zowel inhoudelijk als planmatig.
Onderdeel van het project HOVI is “Een synchronisatietool waarmee de opleidingenset synchroon blijft met de CROHO-registratie (later koppeling met RIO).” +
'''Voortbouwen op bestaande federaties:'''
Op pagina 17 van het aanbestedingsdocument punt 65 wordt als eis gesteld dat architectuur aansluiten op SurfConext toestaat. Dit is in lijn met het ROSA ontwerpkader Voortbouwen op bestaande federaties. Hoe de identificatie en autorisatie meer concreet wordt vormgegeven wordt niet duidelijk uit de voor ons beschikbare documentatie.
'''API-sleutel'''
Op https://api.hovi.nl/api-opzet/ is beschreven dat voor autorisatie gebruik gemaakt wordt van API-keys. Afnemers en instellingen (die data kunnen bewerken) gebruiken dezelfde API. Schrijfrechten kunnen per organisatie beperkt worden, maar de API dwingt geen verdere rechtenbeperkingen binnen organisaties af - schrijf- en publicatierechten per opleiding worden in de HOVI Editor zelf geimplementeerd of moeten door de instellingen zelf in hun eigen koppelingen +
'''Vertrouwelijkheid'''
HOVI bevat geen vertrouwelijke informatie. Alle data in de HOVI-database is openbare data die gratis wordt aangeboden na registratie van de afnemer en ondertekening van leveringsovereenkomsten door die afnemer, waarin afspraken zijn vastgelegd over actualiteit, bronvermelding en dergelijke.
Volgens het Pitch document leveren instellingen contactgegevens op verzoek zoveel mogelijk functioneel. Daarnaast worden ook afnemers geregistreerd.
'''Integriteit'''
De onderwijsinstelling ‘als geheel’ krijgt de mogelijkheid om via aansluiting op de API data in HOVI te registreren en te bewerken. Binnen deze aansluiting worden geen rollen onderscheiden of autorisatiematrices gebruikt. Dat betekent dat de instelling zelf verantwoordelijk is voor (het inrichten van) de juiste autorisaties en toewijzingen aan rollen en personen in systemen die op HOVI aansluiten. Ook traceerbaarheid van handelingen zal vanuit die systemen moeten worden ondersteund.
'''Beschikbaarheid'''
Buiten enkele beschikbaarheidseisen voor de HOVI-voorziening (uptime) zijn er geen duidelijk geformuleerde eisen aan de beschikbaarheid van de inhoud van HOVI (juistheid, tijdigheid en volledigheid van data). Juist deze eisen zijn van belang voor het gebruik van data uit de HOVI in de keten. Dat belang is wederzijds; afnemers moeten weten wat ze kunnen verwachten t.a.v. de beschikbare data en instellingen moeten weten wat ze kunnen verwachten t.a.v. het gebruik door afnemers. Het is nu bijvoorbeeld niet duidelijk welke reactietijd van studiekeuzesites verwacht mag worden, nadat er nieuwe informatie over open dagen door een onderwijsinstelling is aangeleverd aan de HOVI. +
Voor zowel de onderwijsinstellingen, als de afnemers zijn er afspraken gemaakt over de implementatie van de HOVI. Deze afspraken zijn te vinden op de HOVI website. Zo is er per onderwijsinstelling een contactpersoon aangewezen die de migratie intern begeleidt en is er een overgangsperiode waarin de studiekeuzedatabase zowel HOVI- als HODEX-data kan bevatten. +
Voorlichten over onderwijsaanbod: HOVI biedt de standaarden en infrastructuur die onderwijsaanbieders kunnen gebruiken om op uniforme manier informatie over onderwijsaanbod aan te bieden. HOVI is de vervanger van HODEX. In “HOVI Artikel HO Informatie 2019-09-16” worden de redenen benoemd voor het vervangen van de HODEX. Genoemd wordt dat dit voornamelijk te maken heeft met dat de infrastructuur van de HODEX verouderd is en dat het register “wildgroei is ontstaan” . dezelfde ketenprocessen als de HODEX. +
HOVI is de opvolger van HODEX en daarom ook een Centrale database opleidingsaanbod, Portaal onderwijsaanbod, Adresboek van databases met opleidingsaanbod en import-tool opleidingsaanbod.
Uit Bijlage 2 van de HOVI Specificatie (p.21) wordt duidelijk welke inhoudelijke wijzigingen er zijn gemaakt ten opzichte van de HODEX. +
Volgens het governance document §6.0 hebben onderwijsinstellingen het recht om data beschikbaar te stellen, te corrigeren en bijwerken, inwinnen, inzien, registreren en vernietigen.
Accorderen uitwisseling: Iedere afnemer die akkoord gaat met de leveringsvoorwaarden mag data afnemen van de HOVI. (Governance p.8)
“De HOVI-informatie komt publiek beschikbaar voor alle zich registrerende afnemers” (Governance p.8) Een onderwijsinstelling kan dus niet zelf bepalen voor welke afnemers data beschikbaar wordt gesteld. +
De implementatie scenario’s zijn een onderdeel van een bredere set aan documenten in kader van Programma Implementatie ECK en van de standaard [[ECK Distributie en toegang]]. In het document worden enkele principes benoemd. Een snelle scan en inzage in de repository die aan de basis ligt van de getoonde views, leert dat er nog andere principes en besluiten zijn die als architecturale randvoorwaarden kunnen worden gezien. +
Doordat [[ECK iD]] gebruik maakt van ketenvoorzieningen ([[nummervoorziening]] en [[UWLR]]/EDEXML) en afhankelijk is van applicaties bij onderwijsinstellingen (m.n. [[Leerlingadministratiesysteem]] en [[Elektronische leeromgeving (ELO)
]]), zal er op ketenniveau afstemming moeten plaatsvinden. n het document is verder niet beschreven hoe [[ECK iD]] beheerd en doorontwikkeld gaat worden. Dit is ook niet de scope van dit document maar wel belangrijke achtergrond informatie. +
Levenslang leren wordt nog niet optimaal ondersteund doordat [[ECK iD]] wettelijk is gekoppeld aan de onderwijssector (conform de bekostiging). Hierdoor wordt er per sector een id gegenereerd. Er is sprake van een trade-off tussen enerzijds de wens om levenslang leren (over sectoren heen) te ondersteunen, en anderzijds data te minimaliseren en compartimentaliseren om traceerbaarheid van individuen te voorkomen +
Er wordt gebruik gemaakt van [[UWLR]] en [[Nummervoorziening]] en wordt gerefereerd aan bestaande referentiecomponenten.
Ook worden een aantal referentiecomponenten benoemd die nog niet bekend zijn binnen de ROSA. +
Er is sprake van gegevensuitwisseling rondom educatieve content. Ook het ECK-iD zelf wordt uiteraard uitgewisseld. +
De implementatiescenario’s lijken vooral architectuur patterns te zijn van bestaande en (nog) ontbrekende architectuur elementen uit de ROSA binnen dit thema. Daarmee geeft het vooral inzicht in de mogelijke invullingen voor (patterns) op basis van de ROSA architectuur (mits aangevuld op ontbrekende elementen).
Er wordt in de scenario’s ook rekening gehouden met instellingen die nog niet op basis van deze bouwstenen werken. Deze scenario’s zijn daarmee niet compliant met ROSA. Onvoldoende duidelijk welke eisen er dan gelden. +
Het [[ECK iD]] zorgt voor een organisatie overstijgende toepassing van authenticatie. Het is echter (nog) niet onderwijsdomeinbreed want enkel van toepassing voor bestellen en gebruik van educatieve content, i.e. een specifiek ketenproces. Het maken van toetsen is hier bijvoorbeeld geen onderdeel van.
Educatieve content zelf is niet vertrouwelijk, voortgang en resultaten vaak wel: die maken de content persoonlijk.
Ten aanzien van onderwijsdeelnemers worden verder beperkt administratieve gegevens uitgewisseld. Enkel het [[ECK iD]] is nodig voor het geven van toegang voor het kunnen bestellen. Aanvullende gegevens zijn t.b.v. personalisatie in de levering van de content. +
Het betreft dat deel van het ketenproces [[Educatieve_contentketen]] dat de ketenfunctie Onderwijsuitvoering ondersteunt. Daarbinnen is er geen 1 op 1 aansluiting van de genoemde processen op pagina op de processen in ROSA maar lijken ze wel goed daarop te mappen.
De 5 processen zijn echter verschillend van aard. Het eerste proces (Voorbereiden identity provisioning) kan gezien worden als een ketenproces binnen de ketenfunctie Toegang en Autorisatie. De processen Bestellen, Leveren en Gebruiken vormen een aaneengeschakeld geheel waarbij Gebruiken een continu karakter heeft terwijl Bestellen en Leveren een in de tijd eenmalig karakter heeft (voor een individuele bestelling). +
Primair zijn de ketenprocessen rondom bestellen en leveren van educatieve content onderdeel van de ketenfunctie onderwijsuitvoering.
Er is echter ook een proces benoemd die betrekking heeft op het inrichten van identity provisioning. Dit ketenproces lijkt vooral onderdeel van de ketenfunctie Identificatie en toegang. +
De implementatiescenario’s beschrijven het toepassen van de [[ECK iD]] in het kader van bestellen, leveren en gebruiken van educatieve content binnen het VO en het MBO. De scenario’s kunnen ook worden toegepast in andere onderwijsvelden maar zijn in het brondocument niet beschreven.
Daarnaast is uiteraard het werkingsgebied Private sector (distributeurs en uitgevers van educatieve content) onderdeel van de implementatiescenario’s. +
Op dit moment loopt er een traject Modularisering [[UWLR]]. Het doel van dit traject is bredere toepassing van [[UWLR]] mogelijk te maken.
* Interactiepatronen Notify/Request.
* Modulaire opzet van uitwisselstandaard.
* Keuze SOAP en REST +
Onderdeel van de specificatie is (door)verwijzing naar de educatieve applicatie waarin detailinformatie over oefenresultaten te raadplegen is. “Detail informatie van een leerling bij een bepaalde oefening is te gedetailleerd om uit te wisselen. Deze informatie is reeds beschikbaar in het domein van de uitgever. Wel is het wenselijk om een gemiddeld resultaat van een leerling in een vakgebied of lesblok binnen een vakgebied te kunnen inzien. Dit biedt een leerkracht de mogelijkheid direct actie te ondernemen bij leerlingen die aanvullende ondersteuning nodig hebben”.
De specificatie wekt de indruk dat gebruik van Basispoort een vereiste is. Dat is een eis vanuit de implementatie van Momento. +
Uitwisseling van oefenresultaten is een voorgestelde uitbreiding op de huidige [[UWLR]]-specificatie.
Aanvullingen op de standaard richten zich met name op de volgende zaken:
* Overzicht op les
* Overzicht op vakgebied
Hiervoor geldt dat er uniformering van begrippen moet komen op terrein van vakgebied. Daarnaast wordt er gesproken over lessen en een hiërarchie in de aanduiding van een les. Het begrip ‘les’ is primair een tijdgerelateerd begrip (een onderwerp dat je binnen ca. een uur kan worden behandeld). De leshiërarchie is gerelateerd aan het onderwijsmateriaal.
Om invulling te kunnen geven aan het concept ‘les’ wordt in de specificatie gewerkt met tijdsperiodes.
Er bestaat een conceptueel onderscheid tussen oefenen (herhaling, ‘inslijpen’) en verwerken (voortgang boeken in de stof). In de specificatie wordt daartussen - bewust - geen onderscheid gemaakt, omdat de overgang tussen verwerking en oefening niet hard is. Zowel oefenings- als verwerkingsresultaten worden als ‘oefenresultaat’ uitgewisseld op basis van de specificatie. Er wordt nagedacht over een een betere duiding van resultaten aan de hand van leerdoelen.
(Near) Realtime uitwisseling van voortgang.
Het begrip ‘voortgang’ heeft hier een specifieke betekenis: het gaat om voortgang in termen van resultaten, niet om - bijvoorbeeld - (gebrek aan) voortgang wegens lesuitval, vergelijkingen met het lesplan, of benchmarking t.o.v. de voortgang van anderen. +
Voor identificatie van leerlingen (in berichten) wordt verplicht Leerlingid (LAS key) en optioneel [[ECK iD]] gebruikt. In requests wordt steeds de LAS key gebruikt.
Voor toegang voor leerlingen wordt door Momento [[Basispoort]] gebruikt.
Voor identificatie van instellingen wordt gebruik gemaakt van Basispoort-id of (indien Basispoort-id leeggelaten wordt) [[BRIN]]. Uit mondelinge toelichting blijkt dat [[Basispoort]]-id geprefereerd wordt vanwege enerzijds de persistentie van die identifier (bijvoorbeeld na fusies), en anderzijds vanwege de granulariteit (onderscheid van eenheden binnen dezelfde [[BRIN]]).
Binnen Momento is een aantal maatregelen genomen om toegang tot API-endpoints af te schermen op basis van client-certificaten. +
De specificatie van de Koppeling Uitwisseling Oefengegevens beschrijft onderdelen van de functionaliteit van een Methodemonitor die gegevens ontvangt op basis van de uitwisselspecificatie. Er wordt echter niet beschreven welke partij wat op welk moment en onder welke voorwaarden met bepaalde gegevens mag doen (zie ook [[Zeggenschappen]]), wat de BIV-classificatie van die gegevens is en/of wat de bijbehorende te hanteren beveiligingsmaatregelen zijn. Het Functioneel Ontwerp omschrijft - specifiek voor de Methodemonitor Momento - wel een drietal rollen die binnen Momento recht hebben om inhoud in te zien of te muteren, of om functioneel beheer uit te voeren (instellingen, foutrapportages). Inhoudelijke rechten en beheerrechten zijn daar van elkaar gescheiden.
Er wordt gebruik gemaakt van REST APIs. In de voorbeelduitwerking van services wordt gesproken over aanroep van URL’s met HTTP en niet HTTPS. +
De Koppeling Uitwisseling Oefenresultaten heeft betrekking op uitwisseling van oefenresultaten tussen Educatieve Applicaties en Momento (als implementatie van een 'Methode Monitor' c.q. [[Dashboard leerresultaten]]) binnen de sector [[PO]].
De use case-beschrijvingen en andere functionele aspecten, zoals business rules en afhankelijkheden naar andere partijen, zijn sterk opgehangen aan de implementatie van Momento. +
De Koppeling Uitwisseling Oefenresultaten heeft betrekking op uitwisseling van oefenresultaten tussen Educatieve Applicaties en Momento (als implementatie van een 'Methode Monitor' c.q. [[Dashboard leerresultaten]]) binnen de sector [[PO]] +
In het projectplan ([1] p.5) is een hoofdstuk opgenomen waar de governance van het OKE project staat beschreven stakeholders worden benoemd. Ook worden afhankelijkheden in kaart gebracht en risico's benoemd. +
Volgens de Technical reference documentation [3] is OKE gebaseerd op de OOAPI v5 en past hiermee OAUTH2 toe. +
Op de pagina over “Authentication and Error Handling” [3] wordt toegelicht dat het OAUTH protocol wordt toegepast.
De OOAPI staat een aantal identifiers toe die mogen worden gebruikt. Uit de documentatie wordt niet duidelijk welke hiervan binnen de OKE mogen worden gebruikt om gegevens over personen mee uit te wisselen. +
OKE maakt gebruik van de OOAPI v5. Uit de ROSA scan op OOAPI v.4 kwamen een aantal adviezen naar voren op dit gebied.
Binnen de scope van OKE valt informatie over toetsdeelnemers ([4] p.11). Dit is een voorbeeld van persoonsgegevens die worden uitgewisseld. “Codering van vertrouwelijke en privacygevoelige informatie is niet nodig gezien de OAuth-beveiliginsmaatregelen.” [6] slide 21.
In geen van de brondocumenten wordt verder ingegaan op de beveiligingseisen van de gegevensuitwisseling van de OKE. +
“De OKE specificatie ondersteunt de ketenprocessen Toetsen en Examineren, inclusief het aanmelden van deelnemers, plannen van de afname, analyseren van afnameresultaten en presenteren toets-/examenresultaat.“ [8] +
De AMIGO aanpak wordt gehanteerd door OKE. [4][6] Nog niet alle stappen van de aanpak zijn op het moment van de scan afgerond.
Alle termen en definities worden toegelicht in zowel de specificatie [4] als het YAML bestand op GitHub [2].
“Bij de samenstelling van dit document zijn de volgende begrippen en definities uit het ROSA-begrippenmodel Gebruikt" [4] Er wordt nog gebruik gemaakt van het ROSA Begrippenkader.
Er wordt niet uitgelegd of Edukoppeling is overwogen. Tijdens de vorige scan van OOAPI kwam naar voren dat edukoppeling niet was toegepast. +
OKE uitwisselingen geven invulling aan de informatiestromen tussen de applicatiefuncties Deelnemerregistratie, Toetsplanning (en logistiek) en Toetsafname ([4] p.6).
“Ten behoeve van de processen “Vaststellen van resultaat” en “Vastleggen van resultaat” (zie Figuur 2.B inHoofdstuk 2) heeft Toetsplanning (& logistiek) behoefte aan informatie over de individuele resultaten van de toets (examen).” ([4] p.21) Dit suggereert dat vaststellen en vastleggen van resultaten worden gedaan binnen een planning systeem.
Een uitwerking van hoe OKE aansluit op de ketenvoorziening Facet ontbreekt in de documentatie. +
Op basis van de verschillende informatiestromen in hoofdstuk 3 van de specificatie [4] kan een beeld worden gevormd om wat voor soort gegevens OKE gaat. Hoe zeggenschappen liggen voor deze gegevens konden we hier niet in vinden. +
“In dit scenario zijn de volgende functionaliteiten betrokken:
* Deelnemerregistratie, waar studenten, diens opleiding met betreffende toetsen zijn geregistreerd,
* Toetsplanning (& logistiek), waar de afnameplanning voor de toets/examen wordt samengesteld, en
* Toetafname, waar de toetsafname van de groep van mbo-studenten plaatsvindt en resultaten ontstaan.” ([4] p.6)
In figuur 2B ([4] p.6) worden processen verdeeld over deze drie functiegebieden. Wat hier opvalt is dat het vastleggen en vaststellen van een resultaat onder de toetsplanning functie valt. Dit veronderstelt dat een toetsplanningssysteem per definitite ook wat met resultaten moet doen. In de uitgangspunten daaronder wordt deze keuze niet verder +
Uit de beschikbare documentatie werd niet duidelijk wat er met adviezen uit de ROSA scan van 2018 is gedaan. +
'''Bewaak relaties met andere afspraken:'''
Uit de beschikbare documentatie wordt niet duidelijk hoe relaties worden bewaakt met andere afspraken zoals RIO en de HOVI.
'''Breng groepen belanghebbende in kaart:'''
In de beschikbare documentatie staat niet omschreven welke groepen belanghebbende er bestaan bij de OOAPI. +
'''Ontwerpkader: Gebruik Edukoppeling voor vertrouwelijke gegevensuitwisseling:'''
Uit de documentatie wordt niet duidelijk of de OO API in lijn is met Edukoppeling. Wel implementeert v4 de API de nederlandse API strategie. (Bron: Change logs op GitHub) Het Edukoppeling REST profiel is een profiel op basis van de Nederlandse API strategie. Het is onduidelijk in hoeverre hierop wordt aangesloten.
'''Ontwerpkader: Semantiek in berichtuitwisseling is traceerbaar:'''
Definities zijn toegevoegd aan v4. van de OOAPI specificatie.
In het artikel over de stimuleringsregeling wordt gesproken over betere aansluiting op ontwikkelingen van RIO voor het HO. Daarnaast zijn er ook raakvlakken met HOVI. Het is onduidelijk in hoeverre de (gegevens)definities onderling zijn afgestemd of (bewust) afwijken. +
'''Ontwerpkader: Voortbouwen op bestaande federaties:'''
Op de OOAPI website ([https://openonderwijsapi.nl/ Bron]) wordt onder ‘Samen werken aan Standaardisatie’ aangegeven dat de OOAPI SURFconext ondersteunt. SURFconext levert authenticatie maar geen autorisatie. Het wordt uit de documentatie niet duidelijk wie de autorisatie verzorgt, en op basis waarvan. +
In de vorige ROSA Scan uit 2018 werden 5 adviezen gegeven op het ontwerpgebied van IBP. Uit de beschikbare documentatie werd niet duidelijk Hoe deze adviezen zijn opgevolgd.
Volgens het artikel “Stimuleringsregeling Uitwisselen van onderwijsaanbod-data weer gestart” is SURF gestart met een pilot voorziening op basis van de OOAPI standaard, de OOAPI-gateway. Deze voorziening kan verzoeken gericht aan meerdere instellingen bundelen.
'''Ontwerpkader: Duidelijke eisen en verwachtingen:'''
In de OOAPI specificatie v4 staan alleen maar GET endpoints, daarom zullen eisen en verwachtingen rondom integriteit van de data weinig raakvlak hebben met de OOAPI. Eisen en verwachtingen die te maken hebben met beschikbaarheid en vertrouwelijkheid zouden wel relevant zijn, want volgens de OOAPI website kan niet alle onderwijsdata publiek toegankelijk zijn (zie https://openonderwijsapi.nl/ kopje “samenwerken aan standaardisatie”). Voor afnemers en onderwijsinstellingen is het belangrijk om te weten welke gegevens publiek toegankelijk zijn. De gescande documenten bevatten geen duidelijke eisen en verwachtingen op het gebied van beschikbaarheid en vertrouwelijkheid van deze gegevens. +
In de ROSA Scan van OOAPI 4 [5] werd advies gegeven om afstemming te zoeken met RIO en HOVI. In OOAPI 5 is een education-specification extensie opgenomen. Wanneer deze extensie is geïmplementeerd, kan een instelling via SURFeduhub informatie aanleveren aan RIO.
[a] https://openonderwijsapi.nl/#/technical/consumers-and-profiles/rio +
In de OOAPI v5 architectuurdocumentatie is een beschrijving opgenomen van IAA-overwegingen en het mogelijke gebruik van standaarden, in het bijzonder OpenID Connect, voor IAA, in aanvulling op de OOAPI OAS specificatie.
https://openonderwijsapi.nl/#/architecture/IAA
Onder de technische informatie is een overzicht opgenomen van identifiers die in een OOAPI resource gebruikt kunnen worden.
https://openonderwijsapi.nl/#/technical/identifiers +
In de vorige scan werden een aantal adviezen gegeven op dit gebied:
# Neem duidelijke BIV-classificatie op in de OOAPI specificatie.
# Maak duidelijke IBP gerelateerde eisen en verwachtingen onderdeel van de OOAPI specificatie. +
Het onderdeel Scope van de OOAPI architectuurdocumentatie [3] positioneert de OOAPI ten opzichte van de domeinen uit HORA en MORA, en plot OOAPI op de HORA informatieobjecten.
OOAPI richt zich specifiek op de HORA-domeinen Onderwijs en Onderwijsondersteuning, en de MORA-domeinen Onderwijs, Onderwijsaanbod, Onderwijsvraag, Onderwijscatalogus en Examinering.
In de vorige scan was toepassingsgebied compliant met de ketenfuncties ketenfuncties: Onderwijsuitvoering; Personeel en organisatie; Onderwijshuisvesting; en Toetsen, examinering en oefening; +
OOAPI v5 is afgestemd op Digikoppeling en de Nederlandse API strategie.
https://openonderwijsapi.nl/#/architecture/interfacing
De ROSA scan op OOAPIv4 gaf als advies:"stem definities/begrippen af op andere begrippenkaders binnen het onderwijs”
Het gegevensmodel van OOAPI is gebaseerd op het 1Edtech (voorheen IMS) EDU-API model (https://openonderwijsapi.nl/specification/v5/eduapi.png). Dit model hanteert een negenvlaksindeling in Education, Education Offerings en Offering Associations vs. Program, Course en Component.
Er leven in de praktijk bij leveranciers wat knelpunten die toepassen van Edukoppeling moeilijker maken. +
De SURFeduhub ketenvoorziening kan gebruikt worden bij de aanlevering van gegevens aan RIO voor instellingen die een OOAPI-implementatie hebben. SURFeduhub is een platform voor het delen van onderwijsgegevens op basis van OOAPI tussen onderwijsinstellingen en diverse afnemers. RIO is één van de afnemers die door SURFeduhub worden ondersteund. +
OOAPI is gericht op ‘data in beweging’ en is bedoeld om informatie te ontsluiten die binnen een onderwijsinstelling beschikbaar is. De belangrijkste focus is huidige data. In het kader van RIO is ook het ontsluiten van historische data mogelijk. +
Het werkingsgebied van OOAPI is van oorsprong het ho. Een bevinding uit de vorige ROSA Scan was dat het nog onbekend of het de ambitie was het werkingsgebied van de OOAPI uit te breiden. Inmiddels wordt in het mbo-programma OKE gewerkt aan toepassing van OOAPI op de koppelvlakken examinering in het mbo. Onder Architecture/Werkingsgebied van de OOAPI architectuurdocumentatie staat het werkingsgebied verder toegelicht. Hierbij wordt onderzoek buiten scope geplaatst. +
Een algemene bevinding is dat de positionering van de KA in verhouding met de andere architecturen binnen de onderwijsketen verduidelijkt moet worden. Hoe verhoudt de architectuur van het onderwijsgegevensplatform zich bijvoorbeeld ten opzichte van de andere architecturen in het onderwijs? (Zie figuur 2 op p.2 v.d. KA) +
In 3.1 en 3.2 van de ketenarchitectuur (1) worden ketendoelen genoemd en bestuurlijke principes. Vanuit de ketendoelen op het gebied van efficiëntie, effectiviteit en digitale veiligheid wordt de waarde van het onderwijsgegevensplatform voor de onderwijsketen beschreven.
<br>
Het onderwijsgegevensplatform maakt het mogelijk om onderzoeksgegevens op één centrale plek te registreren. Vervolgens kunnen partijen die iets met deze gegevens willen doen toegang worden gegeven tot het platform. Dit zal het aantal gegevensuitwisselingen van persoonsgebonden gegevens kunnen minimaliseren. (Zie KA(1) richtende principes 5 en 7)
<br>
Wat opvalt is dat principes in de KA (1) niet expliciet worden toegelicht door middel van een Rationale, Implicaties, een uitspraak en een stelling zoals de ROSA dit doet. +
In 3.2 van de Ketenarchitectuur (1) staan een aantal bestuurlijke principes die raakvlak hebben met governance.
Op Plateau 2 van de plateauplanning p.19 van de KA (1) wordt er gesproken over “de deelnemers” en “de doelstelling”. Uit de documentatie wordt onduidelijk wie precies bedoeld worden met de deelnemers en welke doelstelling precies wordt bedoeld. In de KA wordt in 1.2 alleen de doelstelling van de ketenarchitectuur beschreven, die weer verwijst naar “programmadoelen”. Op pagina 5 wordt het volgende geschreven: “De voorliggende versie van de ketenarchitectuur ‘onderwijsgegevensplatform ’ heeft uitsluitend als doel de dialoog tussen potentiële deelnemers te starten waardoor ze tot een gedragen eindversie kunnen komen.”, mogelijk heeft dit raakvlak met de eerder genoemde programmadoelen.
Binnen de brondocumentatie worden geen relaties met andere Edustandaard Afspraken beschreven. +
Het KA Verrichtende principe “2 . Eenduidige gegevensdefinities.” (KA (1) p.9), de beschrijving van Metadata in plateau 3 (KA p.19) en de benoeming van het thema Gegevensmodellering (p.20 KSA) duiden erop dat het registreren van de betekenis van nieuwe gegevens een belangrijk thema is bij ontwikkeling van het onderwijsgegevensplatform.
<br>
“Het platform betreft het gegevensverkeer tussen de autonome omgevingen van de deelnemers.” (p.14 van de KA (1)) Via het platform zullen vertrouwelijke gegevens moeten worden uitgewisseld. In de KA staat wel (p.14) dat de koppelvlakken volgens actuele (inter)nationale standaarden en wetgeving worden geharmoniseerd, maar noemt niet om welke standaarden het hier gaat. +
Op figuur 11 van de KA (p.21) valt te zien dat federatieve authenticatie onderdeel is van de Integratie-architectuur, maar er wordt niet beschreven hoe dit wordt ingevuld.
<br>
Op p.11 van de KA staat: “Sub processen binnen ‘ beheer ’ zijn onder meer: het pseudonimiseren, anonimiseren...”. Het onderwijsgegevensplatform wil er dus voor zorgen dat onderzoeksgegevens gepseudonimiseerd en geanonimiseerd worden ontsloten. +
In 3.4 van de Ketenarchitectuur (1) worden een aantal principes genoemd voor het inrichten van het onderwijsgegevens platform. Een aantal hiervan raken ontwerpgebied IBP
<br>
“Onderzoekers krijgen op basis van verstrekte autorisaties door middel van transacties toegang tot de gegevens die zij nodig hebben voor het uitvoeren van hun taak. Niet anders dan in de primaire onderwijsprocessen wordt verhinderd dat zij op eenvoudige wijze grootschalig gegevens van het platform kunnen kopiëren naar hun autonome omgeving.” (KA (1) p.15 onder Openstellen) Dit lijkt een maatregel om te voorkomen dat onderzoeksgegevens onrechtmatig worden verspreid. +
Onder Plateau 5 op p.23 van de KA staat: “Dit plateau betreft het op orde brengen van de onderscheiden platformen die beheerd / gebruikt gaan worden in de context van het Onderwijsgegevensplatform. Ook hiervoor geldt dat dit niet één platform is, maar dat dit kan bestaan uit meerdere platformen die specifiek ingericht zijn voor een usecase, bijvoorbeeld een Doorstroommonitor.”. Uit deze tekst kan worden opgemaakt dat doorstroommonitor een toepassing is van het Onderwijsgegevensplatform. Dit sluit ook aan bij de eerder geconstateerde relatie met de WRO en de Usecases (4). Wat voor platformen het verder kan bestaan wordt niet duidelijk uit de brondocumentatie. +
Uit figuur 12 van de KA (p.22) wordt duidelijk dat in ieder geval [[Id-cf45b873-1f18-4be8-bede-52714accb248|BRON]], [[Id-289f862e-68fc-4058-9bc1-1409c1614f44|RIO]] en een onbekend register met de naam “SFS” bronnen zouden kunnen zijn. Figuur 12 is echter maar een voorbeeld, dus er zouden nog meer landelijke voorzieningen geraakt kunnen worden. +
“Een modern gegevensplatform is een (cloud)omgeving waarin samenwerking en overleg tussen verschillende (keten)partijen over het beheer en gebruik van gegevens tot stand gebracht wordt.” (2, dia 3). Op basis van het onderwijsgegevensplatform kunnen onderzoeken worden uitgevoerd die bijdragen aan visievorming en verantwoording van bestuurlijke besluiten.
<br>
Het wordt niet duidelijk uit de KA(1) of andere documenten wat de scope van deze onderzoeksgegevens is. Wanneer we echter in de WRO (Wet register onderwijsdeelnemers) kijken (hier wordt naar gerefereerd in de Pitch (3)), dan wordt het wel duidelijk dat het hier gaat om Basisgegevens zoals bedoeld in artikel 10 van de WRO. Dit zijn gegevens die te maken hebben met instroom, doorstroom en uitstroom van onderwijsdeelnemers. +
Volgens de Pitch (3) bestrijkt de afspraak het gehele onderwijsdomein. Het gaat hier om een onderwijsgegevensplatform waar alle partijen binnen het onderwijs op kunnen aansluiten wanneer aan bepaalde voorwaarden wordt voldaan, maar de usecase (4) en verschillende afbeeldingen in presentaties en andere documenten lijken meer specifiek over DUO te gaan.
<br>
In de Pitch (3) vinden we de volgende tekst terug als beschrijving van het doel van de afspraak: “Rechtmatigheid van onderwijsgegevens t.b.v. onderzoek (artikel 23 WRO); per 1 - 1 - 2023 worden geen bestanden meer geleverd, maar via een platform verstrekt (inclusief pseudonimisering, anonimisering of waar nodig synthetisering)”. Het onderwijsgegevensplatform heeft als wettelijke grond de WRO.
<br>
In figuur 1 van de KA (1) lijkt hier namelijk alsof alle partijen evenveel met het gegevensplatform te maken hebben, terwijl op basis van wat in de WRO staat, de initiële usecase voornamelijk via DUO zal lopen. +
Onderzoeksgegevens worden niet nader gespecificeerd binnen de brondocumenten. Er kan worden afgeleid van de verwijzing naar het WRO dat dit waarschijnlijk (in ieder geval) gaat om de volgende gegevenssoorten:
* [[Id-2ff9e10e-300a-4156-87e3-a5c0624eda12|Basisgegevens deelname]]
* [[Id-3f11acf8-fa9a-4913-9548-fdf4ec93f80b|Basisgegevens persoon]]
* [[Id-17b35757-559e-414f-9c42-c7204f9259ac|Basisgegevens resultaat]]
Daarnaast wordt ook metadata genoemd op Plateau 3 van de KA (p.19) Dit heeft relatie met gegevenssoort:
* [[Id-343801ea-005a-4e66-af40-2a5edc55472f|Metadata onderzoeksmateriaal]]
Het wordt niet duidelijk of het inderdaad om deze gegevenssoorten gaat. Ook wordt niet duidelijk hoe zeggenschappen zijn uitgewerkt voor de onderzoeksgegevens. +
RIO Aanleveren stuurt een asynchrone terugmelding aan de instelling via OutputManagement +
Bij de vormgeving van het register moeten het juridische en onderwijskundige deel als aparte onderdelen worden onderscheiden en gehandhaafd blijven. (PSA)
Uit het governance document (‘Afspraken over bestuur en beheer’) blijkt: Het informatiemodel RIO wordt in beheer gegeven bij Edustandaard; DUO onderhoudt het PvE levering RIO-DUO en voert correctief, adaptief en preventief onderhoud uit aan de registratie; het Ministerie van OCW beslist over (systeemaanpassingen vanwege) wet- en regelgeving en beleidswijzigingen - ‘grote’ wijzigingen worden op de i-agenda geplaatst en in strategisch ketenregieoverleg geagendeerd; het beheer van de overkoepelende (governance)afspraken wordt overgedragen aan de Informatiekamer +
'''Digitaal doen we het zo''': De PSA RIO “inventariseert de voor het project geldende kaders, principes, richtlijnen, standaarden en normen” (p.1), maar geeft geen expliciet overzicht van de (relevante) ROSA-principes en -ontwerpkaders en de wijze waarop het project daar invulling aan geeft.
'''Inspelen op beleidswijzigingen''': RIO beoogt de mogelijkheid te scheppen om kort-cyclisch beleidswijzigingen door te voeren (PSA, p.2)
'''Koppelen - niet kantelen''': RIO beoogt t.o.v. BRIN een betere weerspiegeling te bewerkstelligen van de eigen (onderwijs)organisatie en opleidingsstructuren in ketenperspectief en daarmee bij te dragen aan het Terugdringen van administratieve lasten (PSA p.2).
'''Eenheid in verscheidenheid''': Het RIO-model ondersteunt de variëteit in onderwijskundige werkelijkheid (wie/wat/waar/hoe) tussen de verschillende onderwijssectoren.
'''Eenmalige registratie meervoudig gebruik''': wordt niet in de PSA genoemd, maar het ligt voor de hand dat RIO als register hier bij uitstek invulling aan kan geven.
De inhoud van RIO zal ook richting (de administratieve processen van) de aanleverende onderwijsinstelling zelf ontsloten worden. +
Niet alle in de diagrammen van de PSA genoemde applicatiecomponenten lijken echt applicatiecomponenten te zijn. Bijv. (p.4) ‘voorzieningenplanning’ en ‘behandelen melding’ (proces? Cf. voetnoot p.3). SSG = afdeling?
Het is onduidelijk welke componenten een rol in de keten spelen, en welke componenten DUO-intern zijn.
Bepaalde, elders in de tekst genoemde, componenten ontbreken in de SOLL-architectuur (ZP, NHR, BAG, SBB)
RIO wordt zowel als logisch geheel(referentiecomponent in ROSA-termen) als applicatie gepositioneerd (p.12 PSA) +
De ontsluiting van het register, m.n. de ontsluiting van de onderwijskundige werkelijkheid, is geen onderdeel van het project (p.3). Uit PSA is niet duidelijk waar / wanneer / door wie dat wordt opgepakt.
- Elders in de PSA (p.5) wordt aangegeven dat “PDB RIO richt zich op inwinnen en '''beschikbaar stellen''' van gegevens en het beheer van het register RIO”
Het programma draagt in ieder geval zorg voor het verkennen van de mogelijkheid om middels LOD gegevens te ontsluiten, een sobere samenhangende presentatie op een website te verzorgen van de gegevens uit RIO en de realisatie van technische koppelingen waarmee huidige afnemers van te vervangen systemen (BRIN etc.) kunnen blijven werken zoals nu. (cf. governance document 0.9, 4.2, punt 45)
De tekst op p.5 PSA suggereert dat er alleen M2M-koppelingen voorzien zijn voor uitwisseling met NHR, BAG, SBB. Instellingen werken via ZP. In de structuurschets M2M (par.4.4) wordt wel een M2M-koppeling voor instellingen beschreven.
Voor de M2M-koppelingen wordt Edukoppeling 1.2 als standaard gehanteerd.
'''Classificeer alle gegevens- en domeinobjecten met het KOI''': hierover wordt in het PID LOD gezegd dat “De semantiek van de gepubliceerde gegevens is afkomstig uit het gegevenswoordenboek DUO en gerelateerd aan het kernmodel Onderwijsinformatie”
'''Openbare register gegevens worden ontsloten als Linked Open Data''': Hieraan wordt invulling gegeven middels de pilot Linked Open Data (cf. PID LOD)
De pilot LOD richt zich op “het ontsluiten van de administratieve werkelijkheid en de juridische werkelijkheid uit RIO” (cf. PID LOD). +
Voor de objecten “Onderwijsaanbieder” en “Onderwijslocatie” is met het onderwijsveld overeengekomen om hier centraal betekenisloze identifiers voor uit te geven bij registratie. +
Digitaal doen we het zo: De PSA RIO “inventariseert de voor het project geldende kaders, principes, richtlijnen, standaarden en normen” (p.1), maar geeft geen expliciet overzicht van de (relevante) ROSA-principes en -ontwerpkaders en de wijze waarop het project daar invulling aan geeft.
Inspelen op beleidswijzigingen: RIO beoogt de mogelijkheid te scheppen om kort-cyclisch beleidswijzigingen door te voeren (PSA, p.2)
Koppelen - niet kantelen: RIO beoogt t.o.v. BRIN een betere weerspiegeling te bewerkstelligen van de eigen (onderwijs)organisatie en opleidingsstructuren in ketenperspectief en daarmee bij te dragen aan het Terugdringen van administratieve lasten (PSA p.2).
Eenheid in verscheidenheid Het RIO-model ondersteunt de variëteit in onderwijskundige werkelijkheid (wie/wat/waar/hoe) tussen de verschillende onderwijssectoren.
Eenmalige registratie meervoudig gebruik: wordt niet in de PSA genoemd, maar het ligt voor de hand dat RIO als register hier bij uitstek invulling aan kan geven.
De inhoud van RIO zal ook richting (de administratieve processen van) de aanleverende onderwijsinstelling zelf ontsloten worden.
BIV-aspecten missen in PSA 4.10.2 (security, PSA); B-I-V-classificatie is niet gespecificeerd.
Er wordt nog verhelderd waar instellingen eigenstandig wijzigingen in RIO kunnen doorvoeren en waar een toetsende rol voor DUO is weggelegd. (governance-document)
DUO houdt geen toezicht op vrijwillige registratie, en staat daarmee niet in voor volledigheid of juistheid van de geregistreerde gegevens. (cf. 2.2, governance-document)
De Linked Data omgeving kent in de pilotfase mogelijk lagere (andere) kwaliteitsnormen (cf. PID LOD). +
RIO biedt de mogelijkheid de informatiebehoeftes van de volgende ketenprocessen beter te vervullen (PSA, p.2):
* Handhaving en toezicht
* Processen rondom informatievoorziening/informatieproducten
* BPV-keten (mbo)
* Horizontale verantwoording
* Processen bij gemeenten (handhaving leerplicht) +
Eenduidige registratie van informatie over instellingen en opleidingen +
Gehele onderwijsdomein; registratie vindt plaats vanuit alle sectoren. Gebruikers zijn bijvoorbeeld DUO (in het kader van diverse wet- en regelgeving), de Inspectie van het Onderwijs, uitgevers, de gemeente en studiekeuzewebsites. (cf. www.rio-onderwijs.nl) +
Zie p.9 PSA. Het bevoegd gezag levert aan RIO, een onderwijsaanbieder mag dat niet (cf. 2.2, governancedocument)
In het PvE levering RIO zal, in termen van zeggenschappen, onderscheid worden gemaakt tussen wettelijk verplichte en vrijwillig aan te leveren gegevens. Bij vrijwillige gegevenslevering blijft de instelling gegevensverantwoordelijke voor het beschikbaar stellen, accorderen van de uitwisseling en het corrigeren en bijwerken. (governancedocument, 2.2) +
§ 2.2 PSA: REST API Design Rules (aka Nederlandse API Strategie); Forum Standaardisatie. Daarmee werkt dit project toe naar het publiceren van zogenaamde sectorale registers in lijn met de stelselcatalogus van de overheid, naast de basisregistraties als BPR en BAG.
Externe gebruikers kunnen realtime details ophalen op basis van een vastgehouden (gecachete) webidentiteit/URI (§ 2.4 PSA) -> Eenmalige registratie, meervoudig gebruik; data wordt niet rondgepompt
In de PSA (§2.2) wordt de hoofddoelstelling van RIO LOD benoemd. Deze kan worden samengevat als het verbeteren van de “Developer Experience (DX)”.
“Scholen beschrijven zelf hun eigen wereld” (PSA §2.2) -> eenheid in verscheidenheid
Effecten op (interne) processen van de afnemers van de gegevens zijn niet omschreven in de PSA. (-> koppelen niet kantelen) +
Afnemers en hun belangen zijn nog niet in kaart gebracht. In de memo staat wel als één van de vervolgstappen genoemd “Stakeholders en hun producten en verwachtingen leren kennen”. +
'''Gegeven uit RIO worden via 3 routes ontsloten:'''
# REST-API / LOD (fair use bevragingen; niet voor synchronisatie van gehele register)
# SPARQL-endpoint (directe bevragingen op LOD; kan tijdelijk worden afgekoppeld bij te grote bevragingen)
# Webservice direct op RIO (niet via LOD; specifiek voor één use case met near-realtime operationele eisen)
'''PSA §2.2:'''
Niet alleen de data, ook het logisch model van RIO wordt, in samenhang, gepubliceerd op het web. Allereerst betekent dit dat de data zelfverklarend is. Herinterpretaties en misverstanden van de data worden tot een minimum beperkt. Verder zijn ook de integriteitsregels voor de betreffende data voor iedereen waarneembaar en bruikbaar om de juistheid, volledigheid en actualiteit van de data geautomatiseerd te valideren.
Scholen beschrijven zelf hun eigen wereld (herkenbare namen, daadwerkelijke locaties, opleidingsprofielen e.d.) en leveren dat aan bij RIO. Door middel van deze ontsluiting wordt dat direct zichtbaar op het web of middels een RIO raadplegende applicatie. Hierdoor kan de school zijn eigen werk controleren. En dat kan in feite iedereen. De datakwaliteit verbetert met een feedbackloop.
'''paragraaf 3.3:''' “Gebruikers mogen verwachten dat ze webapplicaties kunnen bouwen” -> alleen webapplicaties? Geen gebruik van RIO-data in andere systemen / datalandschap van school?
Voor specifieke toepassingen die hoge eisen stellen aan actualiteit (met name voorziening VVA) is op dit moment een (tijdelijke?) alternatieve workaround via onderwijsdata.duo.nl.
In §2.4 van de PSA wordt genoemd dat het doel is dat ontsloten data hoogst actueel is. Naamswijzigingen, het sluiten van een fixus opleiding en dergelijke in RIO zijn dan op secondeschaal toegankelijk. Uit toelichtende gesprekken blijkt dit in praktijk lastig te realiseren. Een actualiteit op minuten- in plaats van secondeschaal is realistischer.
De PSA benoemt datakwaliteit als speerpunt (p. 5). De PSA duidt het begrip ‘datakwaliteit’ slechts beperkt,refererend aan een ‘feedback loop’ (p.6) waarmee de datakwaliteit verbetert. Verder wordt daarover opgemerkt dat de integriteitsregels voor de betreffende data voor iedereen waarneembaar en bruikbaar zijn om de juistheid, volledigheid en actualiteit van de data geautomatiseerd te valideren.
IAA speelt niet voor raadplegen, wel voor beheer van RIO-data.
In §3.3 van de PSA wordt gesteld dat data zonder beperkingen door iedereen mag worden gebruikt, maar dat wijzigingen niet gedaan mogen worden door onbevoegden. +
Privacygevoelige of anderszins vertrouwelijke data zijn buiten scope (PSA §2.3)
Data moeten ‘van goede kwaliteit’ zijn. (PSA §2.2). Daaronder valt in ieder geval de integriteit van de gegevens.
Een eis voor de LOD API is een hoge standaard beschikbaarheid. (PSA §2.4) Dit sluit aan bij het ontwerpkader “Continuïteit van de dienstverlening”. +
Er worden pilots met scholen uitgevoerd. De uitvoering, status en resutaten van die pilots zijn in de PSA niet verder beschreven. +
Met het ontsluiten van RIO data als LOD wil DUO de “developer experience” verbeteren voor ontwikkelaars. (PSA §2.2) Aangezien RIO data een ondersteunende rol speelt bij vrijwel alle onderwijsprocessen (PSA §2.1) zal dit vrijwel alle ketenprocessen raken.
In de memo wordt het doel genoemd “optimale ontsluiting voor externe afnemers”, dit doel wordt niet direct genoemd in de PSA. Het wordt niet duidelijk uit de PSA of uit de memo hoe deze twee doelen in relatie met elkaar staan.
Developers zullen niet de enige afnemers zijn, want er is een impact op alle ketenprocessen. Alleen in strikt technische zin zijn de developers de ‘afnemers’, want zij ‘praten’ tegen de API aan. De eindgebruikers zien het resultaat daarvan, maar niet de technische implementatie. +
Zeggenschap over gegevens ligt bij onderwijsinstellingen zelf (PSA §2.2). +
'''§1.2 p.3 PSA'''
Het vervangen van bestaande ontsluitingen op basis van BRIN.
Vanwege de zin “Gebruikers mogen verwachten dat ze webapplicaties kunnen bouwen” (paragraaf 3.3 van de PSA) lijkt de ontsluiting van RIO-gegevens zich te beperken tot webapplicaties. Er zijn echter ook andersoortige systemen binnen het applicatielandschap van een onderwijsinstelling waarvoor RIO-data relevant kan zijn. +
'''Het ontsluiten van RIO-gegevens als Linked Open Data.'''
Doel is tweeledig:
# Min of meer gestandaardiseerde halfproducten bieden zodat willekeurige applicatiebouwers effectief en efficiënt eindproducten kunnen samenstellen voor een veelheid van stakeholders als burgers, onderwijsaanbieders en anderen. (§2.1 PSA) -> developersperspectief
# Optimale ontsluiting voor externe afnemers, op 1 manier aangeboden voor iedereen met een ontsluiting zo dicht mogelijk bij de bron (memo). -> afnemersperspectief
Er wordt wel gehint richting het afnemersperspectief in bijvoorbeeld de beheerarchitectuur (p.28), maar er worden geen specifieke afnemers benoemd en welke interactie die hebben met de linked data.
De vorm is ontsluiting van RIO als Linked Open Data (LOD), waarmee RIO voor iedereen toegankelijk is. +
Het werkingsgebied van RIO-LOD omvat het gehele onderwijsdomein (§2.1, p.4 PSA, § 2.3 Scope PSA). Zie ook de eerder uitgevoerde scan op het RIO register en beheer (https://www.wikixl.nl/wiki/rosa/index.php/Architectuurscan_RIO_register_en_beheer). +
SEM Ecosysteem is gebaseerd op een Event Driven Architectuur, waarbij data uit de bron komt. Het SEM Ecosysteem is decentraal ontworpen. (Aanmeldformulier) +
"Er is een sterke wens voor een herontwerp van de huidige distributieketen. Voor onder meer ditzelfde doel is ook recent een groeifondsaanvraag toegekend en is Edu-V gestart. Dit onderschrijft ook vanuit de publieke kant de wens tot vervanging van de huidige leermiddelenketen." (aanmeldformulier 2.3.2)
"Ter illustratie is er voor het uitwisselen van Results data gekozen voor een eerste minimale variant van SimpleResult. In de toekomst kunnen op dezelfde technische basis meer complexere resultaatberichten worden gedefinieerd en uitgewisseld." (aanmeldformulier 2.3.3)
xAPI CMI5 wordt gebruikt voor de uitwisseling van course details (https://stichtingsem.stoplight.io/docs/ecosystem/f7f0d3968b781-course-api) +
Aanmeldformulier 3.10: Voordat een partij de API kan bevragen moet een token worden aangevraagd. Dit is gebaseerd op OAuth2; Het bevragen van de API wordt vaak gedaan op basis van een request van een school. De school wordt toegevoegd in de claim van het token.
Resource to check if a school (based on schoolid) has given consent to access data. “schoolId(string): SchoolID for which the consent is requested” https://stichtingsem.stoplight.io/docs/ecosystem/5752c2c90a801-get-consents-by-schoolid
Identificatie van leerlingen gebeurt op basis van een open-id connect. Onder meer ook ENTREE +
"Onderwijsinstellingen zijn in staat om hun eigen SEM Ecosysteem samen te stellen uit de partijen met wie ze contractuele afspraken hebben. Op het SEM Ecosysteem is de school in controle van de data en bepaalt de school welke data van de school van de ene naar de andere partij uit het SEM Ecosysteem gaat.” (Aanmeldformulier, 2.6)
"Consent always has to be given in both systems that are involved. For example: both in the SIS and in the MP a user with the access role to allow data sharing (ie. security officer) has to give consent before the SIS can share their data with the MP (or other systems). The consent APi is used to inform the other party of an api about the consent status." (https://stichtingsem.stoplight.io/docs/ecosystem/f6c3daa741b66-consent-api)
"In alle berichten is strikte dataminimalisatie toegepast en wordt gewerkt met het ketenpseudoniem ECK iD. Als fallback is ook nog een tweede userId toegevoegd." (Aanmeldformulier 3.9)
- "ENTREE-federatie wordt onder meer ondersteund tijdens de toegangsketen." (Aanmeldformulier 3.11) +
Aanmeldformulier 2.2:
* Vanuit dataminimalisatie en doelbinding ontvangen partijen die deelnemen aan SEM Ecosysteem de minimale set aan informatie die ze nodig hebben om de gekozen rollen goed te kunnen vervullen.
* Vanuit privacy en concurrentiegevoeligheid ontvangen de partijen alleen data van de scholen die klant van de partij zijn en consent hebben gegeven voor de uitwisseling van data.
"Op de infrastructuur wordt adequate beveiliging (HTTPS, TLS1.2) toegepast."
Persoonsgegevens mogen alleen ingezien worden door die medewerkers die hier vanuit hun rol en functie toe bevoegd zijn. (Aanmeldformulier, 2.2)
Er is een pub-sub mechanisme (Generic Event Stream API) waarin persoonsgegevens worden uitgewisseld. https://stichtingsem.stoplight.io/docs/ecosystem/78b9c77ba05dd-generic-event-stream-api
Naast ECKiD of (fallback) userId wordt ook gewerkt met UUIDs voor personen, e.g. “UUID chosen by the SIS to refer to a student. This identifier is only published by the SIS as part of the url sent in an earlier event about this student. This identifier is only to be used within the context of requestparameter for this resource, not as a broader identifier of the student.”. https://stichtingsem.stoplight.io/docs/ecosystem/04ac6bbdffad6-get-student-by-id +
In het project Revisie ROSA is een implementatie-onafhankelijk ketenproces rondom Leermiddelen en Leermateriaal uitgewerkt dat model staat voor de specifieke invulling van het proces in verschillende ketensamenwerkingen (in het bijzonder SEM Ecosysteem en ECK Distributie & Toegang). In de uitwerking en toetsing van het model is input verwerkt van de Stichting SEM en vanuit de afspraak Distributie & Toegang.
Het ketenprocesmodel toont de samenhang tussen de leermiddelgerelateerde ketenprocessen (ontwikkelen leermateriaal en aanbieden, verwerven, gebruiken en betalen leermiddel) en hun positie ten opzichte van processen van waaruit informatie wordt gebruikt (inschrijven, bepalen onderwijsaanbod) of waaraan informatie wordt geleverd (planning en roostering, monitoren voortgang).
In het model wordt onderscheid gemaakt tussen de inhoud (het leermateriaal) en het product (het leermiddel) dat op basis van die inhoud wordt samengesteld. Hetzelfde leermateriaal kan in verschillende leermiddelen worden (her)gebruikt.
Op basis van (de match tussen) de leermiddelbeschrijving en de educatieve context waarbinnen het leermiddel moet worden toegepast, wordt een selectie gemaakt. Dat kan de selectie van één enkel leermiddel zijn, of bijvoorbeeld een winkelmandje dat gaandeweg gevuld wordt. Een specifieke vorm van selectie is een zogenoemde leermiddelenlijst, waarin op voorhand is vastgelegd welke leermiddelen nodig zijn.
Vanaf het moment van bestellen ontstaat een bepaalde aanspraak - in de vorm van rechten en plichten - op het leermiddel die op basis van levering, gebruik en betaling wordt bijgesteld. Zo kan de eerste keer gebruik van het leermiddel bijvoorbeeld gelden als ‘activatie’, waarna de gebruiker het recht heeft het leermiddel daadwerkelijk te gebruiken, maar bepaalde andere (retour)rechten niet langer gelden. Afhankelijk van het betaalmodel dat voor het leermiddel van toepassing is (bijv. betaling vooraf, betalen naar gebruik, gratis beschikbaar, abonnement, etc.) beïnvloedt de betaalstatus ook de aanspraak die iemand op een leermiddel heeft.
Vanuit het gebruik van het leermiddel ontstaan enerzijds voortgangsgegevens (waar bevindt iemand zich in het leermateriaal) en anderzijds gebruiksgegevens (wanneer en hoe is het leermiddel gebruikt) die elk hun eigen weg vinden naar andere processen. De voortgangs- en gebruiksgegevens zijn relevante input voor de monitoring van de voortgang van een onderwijsvolger, omdat ze iets zeggen over de (mate van) interactie van de onderwijsvolger met het leermiddel en leermateriaal. De gebruiksgegevens zijn ook relevant voor betaling, indien sprake is van betalen naar gebruik. Gebruiksgegevens kunnen ook input zijn voor een nieuwe selectie- en bestelcyclus, waarbij de selecterende partij de selectie afstemt op gebruiksgegevens uit bijvoorbeeld het voorgaande leerjaar.
"Alle organisaties die activiteiten verrichten die zijn te relateren aan de gedefinieerde rollen van Schoolinformatiesysteem, Markplaats, Leerapplicatie en Leermanagementsysteem zijn onderdeel van het werkingsgebied. Dit zijn onder meer leerlingadministratiesystemen, elektronische leeromgevingen, educatieve distributeurs, educatieve uitgeverijen, toetsplatformen, toetsuitgevers, leveranciers van leerdashboards en aanbieders van educatieve (online) leerapplicaties." (Aanmdeldformulier, 2.4) +
"SEM Ecosysteem is een technische standaard (en afsprakenset) voor een veilige, transparante en real-time uitwisseling van alle relevante data gebruikt voor oriënteren, bestellen, leveren en gebruiken van digitale leermiddelen en toetsen door scholen, leraren en leerlingen." (Aanmeldformulier, 2.1) +
"Het werkingsgebied van het SEM Ecosysteem betreft het primair onderwijs, voortgezet onderwijs en middelbaar beroepsonderwijs. " (Aanmeldformulier, 2.4) +
* "In het SEM Ecosysteem kunnen partijen kiezen om één of meerdere rollen te vervullen. De rollen zijn: Studentinformatiesysteem (SIS), Leermanagementsysteem (LMS), Marktplaats (MP) en Leerapplicatie (LA). Voor ieder van de rollen zijn APIs en verantwoordelijkheden gedefinieerd. Partijen zijn vrij in hun keuze voor deze rollen." (Aanmeldformulier 2.6.1)
* Afspraak heeft betrekking op gegevenssoorten (Aanmeldformulier 3.4):
** Leerlingen/Studenten en docenten (SIS API), inclusief persoonsgegevens
** Leermiddelen (catalogue API)
** Leermateriaal (course API)
** Aanspraken op leermiddelen (Entitlement API)
** Gebruiksgegevens van Leermiddelen (Usage API)
** Voortgangsinformatie van leerlingen/studenten over leermaterialen (Progress API)
** Leerresultaten van leerlingen (Results API)
** Consent voor data-uitwisseling namens scholen (Consent API)
* "Via de Consent API is de school in controle over de uitwisseling van data tussen rollen in het Ecosysteem." (Aanmeldformulier 3.6)
+
Op p.10 van de eindrapportage [3] staat dat een modulaire opzet is toegepast om uitbreiding van de afspraak makkelijker te maken. Uitbreiding naar ook een formatieve resultaten uitwisseling gaat echter lastig. Gemaakte technologiekeuzes zijn door te trekken voor andere gegevensuitwisselingen. Via werkgroep Edukoppeling krijgen deze technologiekeuzes een plek binnen het Edustandaard afsprakenstelsel van het onderwijsdomein. +
Het project Summatieve toetsresultaten VO gaat niet over een bovensectorale uitwisseling, maar er is wel naar andere sectoren gekeken (Aanleiding, [1]). Daarnaast wordt de AMIGO aanpak gevolgd. (p.4, [3]) +
In de opdrachtomschrijving [1] wordt onder het kopje Governance genoemd dat Edu-K opdrachtgever is. Kennisnet is projectleider bij uirvoering en belanghebbende zijn in kaart gebracht en worden vertegenwoordigd in de werkgroep. Taken en verantwoordelijkheden worden verdeeld over de betrokken partijen. Ook worden in het aanmeldformulier op p.5 [7] de belanghebbenden genoemd. Alleen worden hier niet specifiek de belangen in kaart gebracht.
Er is gekeken naar hoe een vergelijkbare uitwisseling in het PO is gedaan (Aanleiding, [1]), +
De technische specificatie [5] bevat een invulling voor alle onderdelen van de AMIGO methodiek. Het bevat hiermee ook alle definitites en een overzicht van de ontwerpkeuzes die voor de uitwisseling van summeratieve toetsresultaten zijn gemaakt.
Vanaf p.13 [5] en onder het kopje “modulariteit van de afspraak” (Bijlage 1, [3]) valt terug te vinden wat de samenhang is met andere modellen binnen de AMIGO modellenmatrix.
Bij de technische uitgangspunten op p.26 [5] worden technische keuzes toegelicht. De implementatie van de koppeling gaat gebeuren in REST. Hierbij wordt genoemd dat voor vertouwelijke gegevensuitwisseling Edukoppeling wordt gebruikt. Ook wordt de ROSA genoemd.
Documentatie voor het logische informatiemodel en de berichtenspecificatie worden ontsloten via losse bestanden. +
Op p.7 [3] wordt genoemd dat bij voorkeur het ECK iD van een onderwijsvolger wordt gebruikt, maar dat als backup ook een LAS-key en nlEduPersonRealId kunnen worden gebruikt.
Oauth 2.0 wordt toegepast voor authorisatie (p.7 [3]) deze aanpak wordt nog niet geborgd in de Edukoppeling transactiestandaard. Wel wordt er gesproken met de werkgroep Edukoppeling (p.10 [3]) +
Op p.26 [5] en p.9 [3] wordt genoemd dat voor de onderliggende infrastructuur wordt aangesloten bij de UBV, Edukoppeling, het privacyconvenant en het internationale OAuth2.
Vanaf p. [5] wordt het certificeringsschema gebruikt om een BIV classificatie toe te wijzen aan gegevens die binnen de uitwisseling vallen. +
(uitgaande van de nieuwe versie van de ROSA) Summatieve toetsresultaten worden gemaakt in het ketenproces Toetsen. +
In het interactieschema (p.8 [5]) is te zien dat de uitwisseling summeratieve toetsresultaten PO gaat om een interactie tussen een Toetsapplicatie en Resultatverwerking. “Voorbeelden van Resultaatverwerking zijn LAS, LMS, LVS en Dashboard” (p.3 [5])
“Het opzetten van de koppeling tussen Toetsapplicatieen LAS (Somtoday& Magister) is een gezamenlijk aansluitprocesmet betrokken LAS-leverancier en school waarbij door de school expliciet toestemming wordt gegeven voor de uitwisseling van benoemde gegevens i.h.k.v. deze specifieke koppeling (mandatering).Omdat in dit aansluitproces tevens de betreffende endpoint-URL moet worden ingesteld, is in deze keten geen behoefte aan centraal beheer van endpoints (zoals ondersteund door OSR).” (p.26 [5]) +
In de Eindrapportage (Bijlage 1 probleemoplossing [3]) wordt de behoefte naar meer standaardisatie op het gebied van toetsresultaatuitwisseling in het VO geschetst. Wat buiten scope is: uitwisseling naar methode applicaties, uitwisselingen vanuit Methode applicaties, Uitwisselingen naar en vanuit Toets applicaties. (p.5 [3]) +
“Dit traject richt zich op de uitwisseling van leerresultaten in de sector VO” (Zie: Afbakening [1]) +
De afspraak heeft betrekking op een “leerlingresultaat”, (p.5 [5]), dit is een Resultaat van een leerling (onderwijsdeelnemer) voor een enkele afname van een toets. (p.24 [5])
Op basis van het interactie schema op p.9 [5] kan niet met zekerheid worden bepaald hoe de zeggenschappen liggen. +
Het beheer en de doorontwikkeling van de SURF Security Baseline zijn gestructureerd via twee primaire organen: het 'standaard committee' en de 'regiegroep'. [4]
Daarnaast is er een proces van aankondiging en feedback voor geplande wijzigingen. Dit proces zorgt ervoor dat alle leden van SURF, vertegenwoordigd in verschillende gremia, geïnformeerd zijn over voorgestelde wijzigingen en de gelegenheid hebben om feedback te geven.
Tot slot is de Raad van Bestuur (RvB) van SURF verantwoordelijk voor het nemen van het uiteindelijke besluit over de vaststelling van de baseline. Er is geen intentie of behoefte om de baseline onder te brengen bij een werkgroep binnen Edustandaard. +
Bij de ontwikkeling van de SURF Security Baseline waren verschillende SURF-leden en partners betrokken, zoals vastgesteld in april 2023 [4]. Ook staat er een lijst van instellingen die hebben deelgenomen aan het opstellen van de richtlijnen op de SURF website. [1]
In 2.8 van het aanmeldformulier wordt de samenhang met andere afspraken beschreven. De maatregelen lijken met name gebaseerd te zijn op internationale afspraken zoals de CIS en ISO 27001 en 27002. De relatie met het toetsingskader Certificeringsschema informatiebeveiliging en privacy ROSA wordt erkend, maar niet gespecificeerd. [4]
De doelgroep werd regelmatig geïnformeerd over de baseline via bijeenkomsten van SURF-community's SCIPR en SCIRT, mailings, websites en door collega's die gespecialiseerd zijn in informatiebeveiliging. Er zijn echter geen openbare verslagen of besluitenlijsten die een brede acceptatie van de afspraak aantonen. [4] +
De afspraak zelf is openbaar toegankelijk. Hier is geen IAA voor nodig. Wel gaan een 13 van de maatregelen over dit onderwerp.
'''SB.9.013 Digital Identities:''' Garandeert dat digitale accounts en identificatoren altijd uniek gekoppeld zijn aan een natuurlijk persoon en dat oude accounts en unieke accountinformatie nooit opnieuw worden toegewezen aan andere natuurlijke personen. Dit waarborgt de traceerbaarheid van digitale toegang tot een unieke individu.
'''SB.9.015 Joiner/Mover/Leaver:''' Vereist dat proceseigenaren goedkeuring verlenen aan gebruikers die autorisaties ontvangen voor gegevens binnen het proces. Dit omvat het loggen en bewaren van verzoeken om toegang tot informatie-assets en bijbehorende autorisaties, alsmede het documenteren van intrekkingsverzoeken en wijzigingen in rollen of contractuele relaties.
'''SB.9.016 Authorization Matrix:''' Legt de verantwoordelijkheid bij proceseigenaren voor een autorisatiematrix die vastlegt wie toegang heeft tot welke gegevens en in welke hoedanigheid. De matrix omvat rollen, autorisaties in rollen, individuen en de rollen die aan individuen zijn toegestaan. +
Aangezien de maatregelen in de SURF Security Baseline zijn gerelateerd aan de maatregelen uit het toetsingskader van het certificeringsschema, kon een globale verschillenanalyse worden uitgevoerd. [4] De belangrijkste verschillen op een rij:
* Classificatie: ROSA hanteert de BIV-methodiek, terwijl SURF werkt met securitylevels. Dit resulteert in een verschillende benadering van risicoclassificatie. Hoewel de controls in de baseline risicoschaling aangeven, is het niet altijd duidelijk wat de criteria zijn voor het classificeren van applicaties als 'medium' en 'high'. [3]
* Categorieën: ROSA gebruikt 21 categorieën, terwijl SURF er 18 heeft. De indeling en het aantal categorieën variëren. [3]
* Maatregelen: ROSA heeft meerdere, ongemarkeerde maatregelen per categorie, in tegenstelling tot de duidelijk gemarkeerde maatregelen in SURF. [3]
* Scope: De scope van ROSA is meer technisch en procesmatig, terwijl SURF een bredere scope heeft, inclusief organisatorische maatregelen.
* Taal: Een taalverschil bestaat; ROSA is in het Nederlands en SURF in het Engels. +
De SURF Security Baseline bevat een aantal uniforme beveiligingsmaatregelen voorschrijft en zodoende bijdraagt aan een coherent beveiligingslandschap van onderwijsorganisaties binnen het HO en MBO. Informatiebeveiliging is een fundamenteel aspect dat door alle lagen van de onderwijsinformatievoorziening heen speelt. +
De SURF Security Baseline bevat diverse maatregelen gericht op het verhogen van de beveiliging van informatiesystemen binnen onderwijsinstellingen.Binnen deze maatregelen zijn uitspraken opgenomen over 'assets', een term die binnen de context van informatiebeveiliging breed geïnterpreteerd kan worden. Dit omvat alle vormen van applicaties, zowel hardware als software.
Een specifieke maatregel, SB.1.004 'Asset inventory', benadrukt het belang van het bijhouden van een actuele inventarisatie van alle hardware- en software-assets binnen een organisatie. [3] +
De SURF Security Baseline presenteert een samenstel van maatregelen (controls) gericht op het waarborgen van informatiebeveiliging binnen onderwijsinstellingen. Deze maatregelen zijn ontworpen om zowel nieuwe als bestaande systemen en toepassingen van de SURF-leden (onderwijsinstellingen) te laten voldoen aan een vastgesteld minimumniveau van beveiliging. [4] +
“De SURF Security Baseline is ontworpen door en voor onderwijsinstellingen die lid zijn van SURF, waaronder universiteiten (wo), hogescholen (hbo) en middelbare beroepsscholen (mbo).” (Aanmeldformulier Edustandaard) +
Bestaande standaarden en uitwisseldiensten moeten naar de UBV-voorschriften verwijzen en niet (meer) zelf definiëren. Edukoppeling, UWLR, ECK DT en OSO worden hierbij met name genoemd. +
“Doel van de afspraak is het onderhouden van een eenduidige set van beveiligingsvoorschriften waarmee de veiligheid, interoperabiliteit en efficiëntie in de onderwijsketen wordt bevorderd.” (UBV §1.2). +
Binnen Edustandaard wordt periodiek (minimaal eenmaal per jaar) de opzet en de werking van de voorschriften besproken met alle relevante stakeholders die vertegenwoordigd zijn in de Standaardisatieraad. Hiertoe wordt input verzameld vanuit de Edustandaard werkgroep Uniforme beveiligingsvoorschriften en vanuit Edu-K.
In de Ketenregie-overleggen wordt nu gesproken over de inrichting van de governance van de UBV.
Aangezien het belangrijk is dat alle ROSA ketenorganisaties de UBV gaan volgen wordt het als een belangrijk punt gezien dat alle belanghebbende worden betrokken. Momenteel is nog niet van iedere organisatie binnen de keten vertegenwoordiging binnen deze overleggen. +
Ketenpartijen conformeren zich aan de 'Code voor informatiebeveiliging'
Sommige voorschriften gelden op basis van BIV classificatie, hierbij wordt gebruik gemaakt van het “Certificeringsschema informatiebeveiliging en privacy ROSA”. (UBV §1.4)
Voor de Uniforme beveiligingsvoorschriften wordt waar mogelijk gebruik gemaakt van ‘hoger gelegen’ afspraken. Bij voorkeur internationale afspraken (zoals van INAN), indien nodig nationale afspraken (zoals van
Forum Standaardisatie en NCSC) en alleen als die niet voldoen aanvullende afspraken die in deze werkgroep worden gemaakt. Afwijken van bovenliggende afspraken wordt onderbouwd. +
Er wordt gewerkt met profielen per standaard, waarin bij elke eis is aangeven waarom deze gevolgd moet worden. In de bijlage van het UBV-document is een profiel voor Edukoppeling uitgewerkt.
De profielen worden beheerd door de werkgroep UBV. Wijzigingen kunnen door de desbetreffende werkgroep van het profiel aangemeld worden. Bijvoorbeeld wanneer gerelateerde voorschriften veranderen.
Een nieuw profiel wordt door beide werkgroepen vastgesteld. +
Doel van de afspraak is het onderhouden van een eenduidige set van beveiligingsvoorschriften waarmee de
veiligheid, interoperabiliteit en efficiëntie in de onderwijsketen wordt bevorderd.
De voorschriften gelden voor alle M2M-gegevensuitwisselingen binnen het onderwijs, zowel voor uitwisselingen via Edukoppeling als voor gegevensuitwisselingen die eigen afspraken hebben zoals de Overstap Service Onderwijs (OSO).
De afspraken zijn ook van toepassing voor alle H2M-uitwisselingen via websites en webdiensten die binnen het onderwijs gebruikt worden, aangezien die doorgaans ook een beveiligde verbinding bieden. +
Volgens §1.3 van de Uniforme Beveiligingsvoorschriften, heeft de afspraak betrekking op de gehele onderwijssector. +
'''''Algemeen'''''
Het certificeringsschema (CS) hanteert in het toetsingskader (iets) andere definities voor BIV dan het ROSA-katern IBP
Het aspect ‘Controleerbaarheid’ is niet (apart) opgenomen in het toetsingskader CS. De rapportage, beschreven in het procesdocument, geeft invulling aan controleerbaarheid.
Het ROSA-katern IBP beschrijft risicoanalyse vanuit (keten)processen, het CS vanuit voorziening/ICT-toepassing. In de procesbeschrijving van het CS lopen teksten over het proces van toepassing van CS en het (keten)proces waarbinnen de desbetreffende ict-toepassing wordt gebruikt wat door elkaar. Noodzakelijkerwijs wordt de ict-toepassing als vertrekpunt genomen, maar wel beschouwd in zijn context (waaronder het ketenproces en de eisen die dat proces stelt).
BIV-classificatie in CS (Basis/Standaard/Hoog) wijkt af van ROSA katern IBP (L/M/H)
'''''Principes en ontwerpkaders'''''
“Harmonisatie van de te nemen maatregelen” (ROSA) - naast het certificeringsschema bestaan er normenkaders specifiek voor ho (SURF) en mbo (taskforce IBP). Zij zijn alle geïnspireerd op ISO 2700X. Het certificeringsschema is een eerste onderwijsnormenkader waarin operationale maatregelen zijn vastgesteld. Een eerdere versie van het certificeringsschema was gebaseerd op de Cloud Control Matrix van de CSA, en stond daarmee verder af van de andere (ISO-gebaseerde) onderwijsnormenkaders.
“Ketenpartijen conformeren aan CvIB” (ROSA) - het CS is gebaseerd op ISO 27002. Een mapping van CS-maatregelen op doelstellingen uit ISO 2700X ontbreekt.
“Sectorbrede frameworks” (ROSA) - CS is hier een invulling van
“Incident response” (ROSA) - Het CS toetsingskader besteed geen expliciete aandacht aan de organisatie van Incident Response (*). Het beschreven proces rondom nieuw te nemen maatregelen (buiten het reguliere standaardisatieproces om) biedt de mogelijkheid om ‘kortcyclisch’ te werken.
“Juiste gegevens op het juiste moment op de juiste plaats” (ROSA) - dit ontwerpkader heeft een bredere scope dan individuele voorzieningen / ICT-toepassingen. Wordt door CS tot op zekere hoogte invulling aan gegeven via B-maatregelen.
“Continuiteit vd dienstverlening” (ROSA) - is een aparte kolom (business continuity) in het CS toetsingskader.
“Duidelijke eisen en verwachtingen” (ROSA) - CS geeft invulling aan eisen en verwachtingen op een specifiek toepassingsgebied (nl. ICT-toepassingen)
“Voldoende meet- en controlepunten” (ROSA) - hoewel het toetsingskaders enige gekwantificeerde kenmerken beschrijft (voor B, niet voor IV) wordt aan de monitoring van de mate waarin aan die kenmerken en/of maatregelen wordt voldaan geen aandacht besteed.
“Afspraken over te realiseren ambitieniveaus” (ROSA) - dit is duidelijk aanwezig in het Toezicht-deel (niveaus van toezicht) en het Toetsingskader (niveaus van maatregelen) van het CS
“Transparantie over maatregelen” (ROSA) - het CS maakt de te nemen maatregelen transparant, de auditverklaring de genomen maatregelen.
“Valideer persoonsgebonden gegevens” (ROSA) - dit ontwerpkader kent vooral een procesaspect, het CS gaat over voorzieningen c.q. Ict-toepassingen.
“Voorkom ongewenste traceerbaarheid en vindbaarheid” (ROSA) - dit ontwerpkader heeft procesaspecten, maar gaat ook over de organisatie van data binnen de toepassing. Zie bijvoorbeeld ook de (aanvullende) ‘maatregelen om vermenging van gegevens te voorkomen’ die op de auditverklaring staan.
“Proactief technisch beheer” (ROSA) - dit komt in het CS terug onder B: patchen en updates van firmware en software zijn ingeregeld en worden periodiek uitgevoerd. In het CS wordt dit beheer niet gerelateerd aan aan I en V.
“Technieken voor veilig programmeren” (ROSA) - komen niet expliciet terug in het CS.
“Voorkom onrechtmatige toegang” (ROSA) - komt in het CS terug via I/V maatregelen
“Handelingen zijn herleidbaar” (ROSA) - komt terug in de kolommen logging en onweerlegbaarheid in BIV
“Niet langer bewaren dan strikt noodzakelijk” -
Heeft een duidelijk procesaspect, maar de ict-toepassing moet het wel *mogelijk* maken dat oude data wordt vernietigd.
“Voorkom aantasting van integriteit” (ROSA) - komt in het CS terug in de I-maatregelen
Het certificeringsschema kan gebruikt worden voor een ict-toepassing die als bouwsteen dient voor één of meer ketenprocessen.
Het certificeringschema valt binnen de ketenfunctie Informatielevering en (indirect) mogelijk alle andere ketenfuncties, wanneer daar sprake is van informatielevering middels systemen binnen scope van het CS. +
Alle ict-toepassingen in het onderwijsdomein
Het begrip "ict-toepassing" is belangrijk voor de duiding van de scope van het certificeringsschema, maar is binnen het certificeringsschema niet nader gedefinieerd. +
Onderwijsdomein - het certificeringsschema is van toepassing op het gehele onderwijsdomein.
Implementatie vindt op dit moment voornamelijk plaats in de sectoren po, vo, mbo. Daarnaast is het certificeringsschema onlosmakelijk verbonden aan implementaties van de Edukoppeling Transactiestandaard. +
Het certificeringsschema heeft betrekking op alle soorten gegevens die bewerkt worden door de desbetreffende ict-toepassing.
In de procesbeschrijving van het certificeringsschema wordt, waar het gaat over de te betrekken partijen, gesproken over “de eigenaar van de data”. +
Het lerarenregister bestaat uit verschillende onderdelen, in beheer bij CIBG en DUO.
CIBG:
* Lerarenregister
* Registervoorportaal
* Professionaliseringssysteem
DUO
* Benoemingen Onderwijzend Personeel (BOP) +
'''Eenmalige registratie, meervoudig gebruik'''
Het lerarenregister is één register bestaande uit verschillende authentieke bronnen:
* BOP is de authentieke registratie voor benoemingen
* LR authentieke registratie voor professionalisering
* BRIN authentieke registratie voor instellingen
De leraar als centraal informatie object
* LR geeft een volledig beeld van bevoegde en onbevoegde inzet bij een of meer onderwijsinstellingen
* LR en RVP zijn bereikbaar op dezelfde URL
* LR en RVP zijn een gezamenlijke registratie i.p.v. aparte silo’
Life cycle van informatie in de verschillende deelsystemen is afgestemd
* De bewaartermijnen van BOP en LR lopen gelijk
* Het professionaliseringsdeel kan los van het bevoegdheidsdeel bestaan
Registratie van diplomagegevens:
''“Bij vrijwillige registratie zonder benoeming, worden de diplomagegevens van de leraar opgehaald bij DUO. Bij ontbreken van deze, wordt aan de leraar gevraagd om een gewaarmerkte kopie van getuigschrift te verstrekken waaruit zijn bevoegdheid blijkt.” ''
Wie controleert de bewijzen CIBG of DUO? Eventueel ook uit buitenland? (beslispunt 3)
'''Terugdringen van administratieve lasten'''
Beschikbaarheid professionaliseringsdossier voor werkgever
“Onderwijsinstellingen worden ontlast van verantwoordelijkheid voor het bijhouden van professionaliseringsdossiers van leraren die ze in dienst hebben.” Dit vergt dat het dossier uit het LR wel beschikbaar kan zijn voor bijvoorbeeld HR-cyclus.
Voorlopig is dit proces nog niet geautomatiseerd, maar leraren kunnen de informatie uit hun eigen dossier exporteren en verstrekken aan de school +
'''Gebruik Edukoppeling voor vertrouwelijke (m2m) gegevensuitwisseling'''
Voor de aanlevering van benoemingsgegevens door bevoegd gezagen wordt Edukoppeling gebruikt.
Voor eventuele handmatige aanlevering is het Zakelijk portaal beschikbaar
De benoemingsgegevens worden met Edukoppeling aan het Lerarenregister (door)geleverd.
Het bevoegd gezag mag inzicht hebben in de voortgang van de herregistratie (%), definitie moet nog plaatsvinden
Als dit geautomatiseerd gaat worden dan loopt het via DUO waardoor scholen één contactpunt hebben met het LR
DUO gaat BRIN informatie in de vorm van RIO publiceren als LOD. Daarmee is deze informatie toegankelijk voor CIBG en andere deelnemers in de keten.
'''Gegevensstromen zijn in de programmastartarchitectuur beschreven vanuit de ‘happy flow’, maar:'''
* Wat als leraar de berichtenbox niet heeft geactiveerd?
* Wat als de leraar de benoemingsgegevens niet accordeert?
* Wat als gegevens niet geverifieerd kunnen worden tegenover BRP?
* Wat als onderwijsinstelling lagere aanleverfrequentie dan 1x per maand hanteert?
* Hoe zien de terugmeld procedures eruit?
* Binnen het programma zijn/worden oplossingen bedacht, echter zijn deze niet expliciet opgenomen in de programmastartarchitectuur.
'''Classificeer alle gegevens- en domeinobjecten met het Kernmodel Onderwijsinformatie'''
Begrippen die nu niet in het KOI zitten maar n.a.v. LR mogelijk toegevoegd zouden kunnen worden:
* Bevoegd Gezag
* Leerkracht (i.p.v. of als verbijzondering van ‘Medewerker’; overkoepelend voor ‘Docent’ en ‘Leraar’)
* Benoeming, verbindt Leerkracht en Bevoegd Gezag. Heeft betrekking op Leereenheid en Onderwijsinstelling +
Er loopt een traject om het Lerarennummer te introduceren. Het idee is om een de leraar middels een unieke nummer te identificeren (een soort BIG-nummer). Dat betekent het LR op termijn een IAA-voorziening zou kunnen worden +
'''Privacy by design'''
De leraar moet toestemming geven om inzage te geven in zijn gegevens. Per default staat deze optie uit.
'''Valideer persoonsgebonden gegevens'''
Leraar is nu ‘in de loop’ voordat gegevens worden gepubliceerd. Mooie vernieuwing t.o.v. vorige versie!
'''De juiste gegevens op het juiste moment op de juiste plaats'''
Bij overschrijding van wettelijke termijn onbevoegde inzet worden de leraar en het BG (achteraf) in kennis gesteld. Het is verantwoordelijkheid van leraar en BG om dit termijn in de gaten te houden. +
Het Lerarenregister bestrijkt (administratieve) processen die niet nader in ROSA zijn beschreven. +
Administratieve processen en gegevens t.b.v. de verplichte registratie van leraren/docenten, bekwaamheidsonderhoud door de leraren/docenten en de beoordeling i.h.k.v. herregistratie +
Bekostigd en niet-bekostigd erkend primair onderwijs (po) en voortgezet onderwijs (vo) en bekostigd middelbaar beroepsonderwijs (mbo) +
De zeggenschappen bij gegevenssoorten zijn beschreven in de projectstartarchitectuur.
Benoemingen vinden plaats op instellingsniveau, hierdoor is de vindbaarheid op vestigingsniveau lastig.
Er is kennelijk nog verwarring over BRIN4 / BRIN6
* “Er wordt gebouwd op basis van BRIN4”, maar het informatiemodel heeft het over BRINvolgnummer (= BRIN6)
* De relatie in het model heet ‘vestiging’ (wijst op BRIN6)
* “Met komst RIO wordt BRIN6 nummer geïntroduceerd”. Dit is onjuist -> BRIN6 bestaat al maar RIO gaat meer het instellingsbegrip vanuit de onderwijskundige werkelijkheid representeren i.p.v. alleen vanuit de bekostiging werkelijkheid zoals dat nu bij BRIN het geval is.
* Bij “Instellingsgegevens” (3.3.2.2, A.2) worden school, instelling en vestiging op een hoop geveegd
RIO wordt genoemd als een ontwikkeling om rekening mee te houden, dat is een mooie toevoeging t.o.v. vorige versie!
In programmastartarchitectuur is ‘Benoeming’ synoniem voor ‘Tewerkstelling zonder benoeming’. Dat klinkt vreemd. Kennelijk is dit een wettelijke term, waarbij de intentie van de wet is om geen groepen te vergeten
Personeel niet in loondienst is een aandachtspunt:
* Flexpools kunnen geen lerarengegevens opleveren
* Leraren zitten niet in de schooladministraties
* Leraren kunnen zich vrijwillig registreren in LR
* Leraren zijn niet vindbaar via vestiging +
Het lerarenregister bestaat uit verschillende onderdelen, in beheer bij CIBG en DUO.
CIBG:
* Lerarenregister
* Registervoorportaal
* Professionaliseringssysteem
DUO:
* Benoemingen Onderwijzend Personeel (BOP) +
'''Eenmalige registratie, meervoudig gebruik'''
Gegevens over benoemingen worden geregistreerd in zowel de BOP als (via de BOP) in het Lerarenregister. Beide voeren validaties uit tegen de BRP. In het LR worden de leraargegevens gekoppeld aan schoolgegevens afkomstig uit BRIN.
De BOP is in de PSA BOP gepositioneerd als een ‘basisregistratie’. In de PSA LR worden de wettelijke gegevens in het LR en het RVP als ‘authentiek’ aangemerkt. Hierdoor ontstaan verschillende registraties die gepositioneerd worden als (authentieke) bron voor dezelfde gegevens (benoemingsgrondslag, schoolnamen en -adressen)
Kan een persoon zowel in het Lerarenregister als in het Registervoorportaal staan? Hoe wordt omgegaan met dubbele registraties in/vanuit BOP, vanwege meerdere benoemingen op meerdere scholen, of op een en dezelfde school? +
'''Gebruik Edukoppeling voor vertrouwelijke (m2m) gegevensuitwisseling'''
Voor de aanlevering van benoemingsgegevens door bevoegd gezagen wordt Edukoppeling gebruikt. Voor eventuele handmatige aanlevering is het Zakelijk portaal beschikbaar (PSA DUO). De gegevens worden met Edukoppeling aan het Lerarenregister (door)geleverd.
Voor het raadplegen van het leraardossier door het bevoegd gezag wordt eHerkenning gebruikt (RQ09 PSA LR) In de PSA LR wordt tevens - in kennelijke tegenspraak met o.a. RQ09 - gemeld dat gegevensteruglevering vanuit het LR via DUO verloopt, maar dat daarover nog een besluit genomen moet worden.
In het LR zijn leraargegevens gekoppeld aan BRIN-gegevens. Het gebruik van eHerkenning vereist dat door het LR het verband gelegd kan worden tussen het OIN/NHR-nummer van het bevoegd gezag en de BRINs van onderwijsinstellingen die onder dat BG vallen. Het is onduidelijk of / hoe het LR die koppeling kan maken.
'''Classificeer alle gegevens- en domeinobjecten met het Kernmodel Onderwijsinformatie'''
Begrippen die nu niet in het KOI zitten maar n.a.v. LR mogelijk toegevoegd zouden kunnen worden:
* Bevoegd Gezag
* Leerkracht (i.p.v. of als verbijzondering van ‘Medewerker’; overkoepelend voor ‘Docent’ en ‘Leraar’)
* Benoeming, verbindt Leerkracht en Bevoegd Gezag. Heeft betrekking op Leereenheid en Onderwijsinstelling +
'''Voorkom onrechtmatige toegang of verspreiding'''
Het bevoegd gezag zal mogelijk leraardossiers ter beschikking willen stellen aan bevoegde functionarissen verbonden aan (een instelling onder) dat bevoegd gezag. Wanneer sprake is van (online) inzage op het niveau van het bevoegd gezag is het lastig (onmogelijk?) onderscheid te maken tussen de leraardossiers die horen bij c.q. inzichtelijk mogen zijn voor een functionaris van een bepaalde onderwijsinstelling en alle andere onder dat BG vallende onderwijsinstellingen. Het gevolg zou kunnen zijn dat een functionaris inzage heeft in te veel leraardossiers.
Wanneer in plaats van inzage sprake is van teruglevering, kan deze ‘routering’ van het leraardossier door het systeem van de school afgehandeld worden. Daarvoor moeten dan wel voldoende identificerende kenmerken (zoals BSN van de leraar) teruggeleverd worden, opdat de schooladministratie het dossier aan de juiste medewerker kan koppelen.
'''Valideer persoonsgebonden gegevens'''
Het lerarenregister bevat (publieke) gegevens over de leraar, die negatieve consequenties kan ervaren wanneer die gegevens niet kloppen.
Wanneer er bijvoorbeeld verkeerde gegevens worden aangeleverd vanuit de onderwijsinstelling (of diens administrateur) t.a.v. de benoemingsgrondslag, heeft de leraar pas de gelegenheid daar kennis van te nemen zodra die gegevens in het register verwerkt en gepubliceerd zijn. De leraar is vooraf niet betrokken bij de validatie van ‘zijn’ gegevens +
Het Lerarenregister bestrijkt (administratieve) processen die niet nader in ROSA zijn beschreven. +
Administratieve processen en gegevens t.b.v. de verplichte registratie van leraren/docenten, bekwaamheidsonderhoud door de leraren/docenten en de beoordeling i.h.k.v. herregistratie +
Bekostigd en niet-bekostigd erkend primair onderwijs (po) en voortgezet onderwijs (vo) en bekostigd middelbaar beroepsonderwijs (mbo) +
De informatieprocessen zijn beschreven in de projectstartarchitectuur. +
Het is niet vastgelegd welke referentiecomponenten en/of applicaties via de OO API ontsloten (moeten) kunnen worden.
In de website wordt er gerefereerd aan een ‘API Manager’. Dit lijkt een referentiecomponent (bouwblok) dat bij de OO API hoort. Over deze referentiecomponent is echter maar weinig vastgelegd. +
De OO API beperkt zich tot de ho-sector +
'''Ketenpartijen bieden wederzijdse services''' - De OO API is weliswaar geen webservicespecificatie, maar biedt desalniettemin een (REST) endpoint voor data consumers om gegevens uit de bron op te halen. Op die manier geeft de OO API een goede invulling hieraan.
'''Registreer de betekenis van nieuwe gegevens''' - Het is niet duidelijk welke OO API begrippen nieuw zijn. Sommige begrippen zijn niet scherp gedefinieerd
'''Serviceinformatie wordt samenhangend openbaar gemaakt''' - Het is niet duidelijk hoe een gebruiker of ontwikkelaar weet dat er een endpoint bestaat
'''Classificeer alle gegevens- en domeinobjecten met het Kernmodel Onderwijsinformatie''' - Het is onbekend hoe de semantiek van de OO API zich tot de semantiek van het KOI verhoudt.
Sommige gegevens, attributen en relaties zijn niet scherp gedefinieerd
Voorbeelden:
"Educational departments" = The educational departments of an organization.
Faculty = The organizational parts of an organization.
Wat is het verschil tussen educational departments en faculty?
Waarom is Organization niet gedefinieerd?
Hoe weet je over welke organisatie het gaat?
"Affiiation"
The affiliations of how this person is associated with the organization
Student/Employee/Staff/Member/Affiliate/Organization
Het verschil tussen employee, staff en member is onduidelijk. Er lijkt ook een, verder niet beschreven, relatie te zijn met filters en autorisatie (Zie ook de bevindingen over filters bij IBP)
"Building"
Dit gegeven staat los van de rest.
Building is een attribuut van “Schedule”, maar de verwijzing ontbreekt. Wat is de ontwerpbeslissing hierachter?
'''Behoeftegerichte en doelgebonden gegevensuitwisseling''' - Het is niet duidelijk hoe de OO API borgt dat er niet meer (maar ook niet minder) informatie dan nodig uitgewisseld wordt. +
'''Gebruik onderwijsidentiteit waar nodig''' - Over het gebruik van identiteiten zijn geen besluiten of richtlijnen vastgelegd +
'''Voorkom onrechtmatige toegang of verspreiding''' - Uit de website blijkt dat de OO API onderstaande data beschikbaarheidsniveaus kent:
#“Data wat beschikbaar is voor iedereen, zoals nieuwsberichten of een overzicht van de verschillende studies.”
#“Data wat voor een bepaalde doelgroep beschikbaar is, zoals rooster data wat alleen beschikbaar is voor studenten van een bepaalde instelling of van een bepaalde studierichting. Voordat deze data kan worden vrijgegeven dient het systeem (veelal de API manager) de identiteit van de gebruiker te achterhalen om te kunnen bepalen ‘Is dit een student van deze instelling of van deze studierichting?’. De gebruiker zal deze gegevens middels een inlog moeten vrijgeven.”
#“Data wat bedoeld is voor een bepaalde gebruiker. Denk hier bijvoorbeeld aan tentamen/examen cijfers. Voordat deze data kan worden vrijgegeven dient het systeem de identiteit van de gebruiker te achterhalen. De gebruiker zal hiervoor moeten inloggen”
Zie: https://openonderwijsapi.nl/community/faq/
In de website van de OO API staat dat de OO API de OAuth 2.0 protocol ondersteunt. De specificatie zelf geeft niet aan hoe OAuth 2.0 precies gebruikt/geïmplementeerd moet worden. Er is een PoC waarin informatie hierover is opgenomen.
'''Transparantie over maatregelen''' - In het HO is gekozen voor het vastleggen van afspraken ten aanzien van privacy en security middels het SURF juridisch normenkader.
'''De juiste gegevens op het juiste moment op de juiste plaats''' - De OO API geeft een goede invulling hieraan Maakt het mogelijk om gegevens op een laagdrempelige manier op te vragen bij de bronnen. Welke gegevens de ‘juiste’ zijn, kan worden aangegeven via filters (zie hierover de opmerkingen bij Voorkom onrechtmatige toegang of verspreiding)
'''Handelingen zijn herleidbaar''' - Over de traceerbaarheid van opvragingen via de OO API zijn geen besluiten of richtlijnen vastgelegd
'''Voorkom ongewenste traceerbaarheid en vindbaarheid''' - Over het gebruik van persoonsgegevens (zoals geslacht, tel.nummer, foto,..) zijn geen besluiten of richtlijnen vastgelegd
De ketenprocessen zijn niet gedefinieerd in de OO API specificatie +
De OO API ondersteunt administratieve- en onderwijsprocessen, door informatie van
onderwijsinstellingen beschikbaar te stellen over: onderwijsafdelingen, onderwijsplannen,
cursusgroepen, cursussen, cursusresultaten, toetsresultaten, gebouwen, ruimtes, roostergegevens, nieuwskanalen en nieuwsitems. +
Hoger onderwijs (ho) +
De zeggenschappen bij de gegevenssoorten (wat wel en wat niet door welke partij mag worden uitgewisseld, opgeslagen, ingezien, bewerkt) zijn niet gedefinieerd in de OO API specificatie. Deze zouden wel gedefinieerd moeten worden worden, mede als opmaat naar verdere uitwerking van security-aspecten als autorisatie en filtering (cf. IBP) +
Uitbreiding Internationaal roept de vraag op of hier een rol is weggelegd voor het serviceregister, of dat een knooppunt bij bijv. DUO, dat door internationale partijen is te bevragen, volstaat. Gaan / kunnen / willen internationale partijen op NL serviceregister aansluiten? Wat betekent dat voor PKI e.d.? +
Kenmerken voor routering worden bekend verondersteld (bijvoorbeeld ‘uit eerdere communicatie’). Dat betekent dat het OSR geen koppeltabel levert of bijhoudt tussen bijv. onderwijsvolger en endpoint. In plaats daarvan wordt bij een aanleverpunt een kenmerk opgenomen waarop kan worden gezocht. Dat is een goed uitgangspunt (geen persoonsgegevens in OSR), maar vereist mogelijk wel aanpassingen in bestaande pakketten die nu adresseren op basis van individuele onderwijsvolgers. +
Het ontwerp van het serviceregister gaat onder andere uit van het doel '''Terugdringen administratieve lasten''' en geeft daar invulling aan door de ontwerpkeuzes OK1 Geen extra administratieve complexiteit en OK2 Geen nieuwe koppelvlakken.
Het serviceregister maakt '''Eenmalige registratie, meervoudig gebruik''' van serviceinformatie mogelijk. Nu wordt die informatie nog bijgehouden in toepassingsspecifieke “silo’s”. +
Het serviceregister geeft invulling aan het ontwerpkader '''Serviceinformatie samenhangend openbaar'''.
Het ontwerp gaat in op de beschrijving van services in termen van ‘waar’ (aanleverpunt/afleveradres) en ‘wie’ (mandateringsrelatie onderwijsaanbieder/dienstaanbieder). Het bestaan en bekend zijn van een service is het uitgangspunt voor gebruik van het serviceregister. Er vindt dus geen registratie plaats van ‘wat’ een service doet.
Gegevens in het OSR zullen worden ontsloten middels een SOAP service, c.q. Edukoppeling. Bij voldoende belangstelling is een uitbreiding naar REST en JSON denkbaar. +
Het ontwerp van het serviceregister doet nog geen uitspraken over het te gebruiken IAA-middel voor toegang door een ‘bevoegde medewerker van een onderwijsinstellig’ en daaraan gerelateerde onderwerpen (e.g., Wie bepaalt bevoegdheid? Hoe wordt dat vastgelegd?)
Het serviceregister is ‘neutraal’ ten opzichte van de te gebruiken PKI-infrastructuur voor publieke sleutels die in het serviceregister worden opgenomen. +
Het serviceregister stelt kwaliteitseisen aan de geregistreerde informatie in verband met de vertrouwelijkheid van sommige services en de vereiste integriteit van gegevens in het register. RIO is een mogelijke bron voor informatie over onderwijsaanbieders die in het serviceregister aan diensten en aanleverpunten worden gekoppeld. De kwaliteitseisen die het serviceregister stelt zijn daarom relevant voor (de kwaliteit van) de informatie die in RIO is ondergebracht. +
Werken bevragingen op het OSR altijd real-time, of wordt de mogelijkheid van een vorm van client-side caching voorzien? Vereist wellicht aanvullende functionaliteiten voor cache-invalidatie (subscription op OSR-events ten gevolge van beheer van serviceinformatie) +
Het onderwijsserviceregister is een administratieve, technische component die in principe voor alle soortern processen gebruikt kan worden.
Er wordt in het ontwerp een hard onderscheid gesuggereerd tussen ‘binnen’ en ‘buiten’ een onderwijsinstelling. Dat onderscheid is niet (altijd) te maken. F.3 is beschreven als ‘routering naar de onderwijsinstelling’, maar zou juist ook kunnen worden gebruikt voor routering binnen de onderwijsinstelling. +
Ondersteuning van berichtuitwisseling tussen ketenpartijen +
Hele onderwijsdomein. In de eerste fase ligt de nadruk op onderwijsinstellingen en SAAS-leveranciers. +
Figuren 1 en 2 in het PvE vertegenwoordigen een andere view (gebruik in H2M2M-keten resp. beheer van de inhoud van het register), maar tonen beide de rol ‘onderwijsprofessional’. De betekenis van die rol is hierdoor onduidelijk.
Zeggenschap in kaart
Het serviceregister kent verschillende soorten gegevens: (a) het bestaan van een dienst, (b) het gebruik van een dienst (mandateringsrelatie) en (c) de locatie van een dienst (afleveradres). De zeggenschappen over deze gegevens komen nu vooral in de functionele wensen tot uitdrukking.
Het ontwerp gaat sterk uit van de beoogde situatie in fase 1. Daardoor is bijvoorbeeld nog niet duidelijk wat de impact is op de uit het serviceregister herleidbare mandateringsrelatie tussen onderwijsinstelling en dienstaanbieder wanneer bijvoorbeeld DUO of een andere partij ook aanleverpunten zou gaan registreren. +
Het informatiemodel komt voort uit ervaren beperkingen bij het toepassen van informatie uit het huidige [[BRIN]] in andere dan bekostiging-gerelateerde ketenprocessen.
Het project spreekt bewust over een 'registratie' en niet een 'register' als het gaat over de implementatie van het model. Er is namelijk nog geen uitspraak gedaan over de vorm die zo’n registratie zou moeten hebben: een centraal register of een verzameling decentrale (onderling verbonden) registratievoorzieningen behoren beide tot de mogelijkheden. +
Er wordt niet expliciet gerefereerd aan principes en ontwerpkaders voor [[Bovensectorale samenwerking]] uit ROSA.
[[Inspelen op beleidswijzigingen]] gebeurt nu bijvoorbeeld m.b.t. Samenwerkingsscholen: RIO wordt hierin expliciet meegenomen. Hierbij worden personen die vanuit OCW met wetgeving bezig zijn gekoppeld aan leden van de RIO-projectgroep die met het begrippenkader bezig zijn. +
Het ingebrachte betreft een informatiemodel waarvan de eerste implementaties nog moeten gaan plaatsvinden. Die implementaties zullen waarschijnlijk ook nog leiden tot wijzigingen in het model.
''"Niettemin achten OCW en de Projectgroep RIO het van belang dat de ontwikkeling en het beheer van het model in nauwe samenhang geschiedt met de brede onderwijssemantiek (waaronder het [[Kernmodel Onderwijsinformatie]], KOI), zich daaraan conformeert dan wel leidt tot voorstellen voor aanvullingen/aanpassingen in die onderwijssemantiek. De registratie moet dit proces borgen."''
Inhoudelijke scope van het model is: scholen c.q. onderwijsinstellingen in relatie tot wat ze aanbieden en waar ze dat aanbieden. Het WIE (onderwijsaanbieder), WAT/HOE (aangeboden opleiding), WAAR (onderwijslocatie) gekoppeld aan het formele WAT (formele opleidingsaanbod) en het daarbij horende HOE (opleidingsprogrammakader).
Onderwijssemantiek en het KOI vallen het meest onder het ROSA-thema [[Gegevensuitwisseling in de keten]]. Om deze reden is dit thema een van de belangrijkste voor deze architectuurscan. +
RIO kan een basis vormen voor identificatie van onderwijsinstellingen. Het thema [[IAA]] houdt zich vooralsnog bezig met identificatie van personen c.q. onderwijsvolgers. +
Voor de informatie die aan de hand van het RIO-Informatiemodel zal worden vastgelegd is het uitgangspunt dat dit 'open' data is of zou kunnen zijn. Dit betekent dat er geen persoonsgegevens in het model worden vastgelegd. Het impliceert ook dat principes en ontwerpkaders op het gebied van vertrouwelijkheid en privacybescherming niet op het model van toepassing zijn.
Er is een discussie gaande in een werkgroep die vanuit de Inspectie is gestart omdat die
ook namen van contactpersonen wil hebben. Als het model hiermee uitgebreid wordt dan krijg je wel met vertrouwelijkheid en privacybescherming te maken.
De RIO-projectgroep is overigens van mening dat dit eigenlijk niet in het model thuishoort, maar de discussie loopt. De verwachting is dat hooguit afdelingen een communicatiecontext krijgen.
Vanuit de instellingen is het wenselijk dat contactgegevens losgekoppeld worden van individuen +
De ambitie is dat RIO uiteindelijk werkt voor alle ketenprocessen in het onderwijs. De volgende processen zijn reeds getoetst:
;Toezicht:Definiëren van objecten van toezicht en objecten van onderzoek in termen van wie/waar/wat
;Erkenning/Bekostiging: De processen vinden reeds plaats en blijven bestaan, de registratie van het resultaat zal worden aangepast op het nieuwe informatiemodel OA
* Onderwijslicenties
* Examenlicenties
* Bekostigingslicenties
* Bekostigingseenheden relateren aan onderwijsinstelling, onderwijslocatie(s) en opleidingen
;Processen rondom informatievoorziening en -producten: rekening houden met de mogelijkheden van meer en verbeterde gegevens bij beleidsinformatie.
;BPV-keten:
* Bereikbaarheidsgegevens van stagecoördinatoren bij instellingen (t.b.v. leerbedrijven)
* Arbeidsmarktonderzoek/ doelmatigheid
* Afsluiten van SLA's voor gegevenslevering.
;Horizontale verantwoording: MBO Transparant
;Processen bij gemeenten: Handhaving leerplicht
:De processen Handhaving veiligheid (brandveiligheid, etc.) bij gemeenten en Verstrekken leermiddelen (digitale en fysieke levering) bij uitgeverijen zijn verkend +
Het gaat om begrippen die toegepast kunnen worden in alle domeinen waar identificatie van instellingen en opleidingen een rol speelt. +
'''[[Onderwijsdomein]]''' - De begrippen gelden voor instellingen in alle onderwijssectoren, voor het Ministerie van OCW (in het bijzonder DUO en de Inspectie) en ook voor private partijen zoals uitgeverijen, hoewel de processen die nu in beeld zijn vooral uitwisseling tussen instellingen en
overheid betreffen. +
In een sessie met de RIO-implementatiegroep bleek dat het lastig was om de [[zeggenschappen]] zoals ROSA die beschrijft te verbinden aan het RIO-informatiemodel. De nu in de wiki beschikbare
beschrijvingen/definities van de zeggenschappen werden daarbij niet als eenduidig ervaren.
Een andere vraag die rees is: wie bepaalt de (invulling van) zeggenschappen? +
PvE introduceert een aantal ‘Koppelpunten’ die berichtroutering tussen administratiesystemen verzorgen +
'''Inspelen op beleidswijzigingen'''
Business logica voor routering en filtering van aanmeldingen wordt gecentraliseerd in mbo-koppelpunt. +
'''Behoeftegerichte en doelgebonden gegevensuitwisseling'''
Business logica voor routering en filtering van aanmeldingen wordt gecentraliseerd in mbo-koppelpunt. Hiervoor worden alle aanmeldingen vanuit MBO-instellingen aan het mbo-koppelpunt aangeleverd. Het koppelpunt moet worden beschouwd als een verlengstuk van het administratiesysteem van de mbo-instelling (zoals in het PvE aangegeven).
'''Serviceinformatie wordt samenhangend openbaar gemaakt'''
* Elke partij realiseert het eigen deel van een digitaal adressenregister
* vo maakt gebruik van onderwijsserviceregister (basisinfrastructuur), gemeenten van eigen register; mbo heeft ihkv dit PvE (nog) niet te maken met gegevensleveringen aan eigen services
'''Gebruik Edukoppeling voor vertrouwelijke gegevensuitwisseling'''
* Er vindt (fig. 2) geen end-to-end messaging en validatie plaats; er is geen ‘spontaan’ (event) berichtenverkeer terug mogelijk.
* Berichten worden geadresseerd met het OIN van de volgende schakel (van koppelpunt naar koppelpunt).
* Er wordt gewerkt met signaalcodes obv technische validatie door de ontvanger van een bericht. +
'''Transparantie over maatregelen'''
* Er is een BIV-classificatie
* In het PvE wordt gesteld dat “additionele eisen op het gebied van betrouwbaarheid, integriteit en beveiliging zullen worden bepaald” op basis van die classificatie. +
Het PvE beschrijft het ketenproces van het volgen van verwachte aanmelding en daadwerkelijke aanmeldingen en aanmeldstatus van vo-leerlingen naar mbo. +
Het beschikbaar zijn van een serviceregister wordt verondersteld. +
Berichtroutering tussen vo-scholen, mbo-instellingen en gemeenten in het kader van vroegtijdig aanmelden +
VO-instellingen, MBO-instellingen, gemeenten +
Informatieobjecten:
* Potentiële MBO-gangers
* Aanmeldstatussen mbo-instellingen
Koppelpunt ontvangt, bevestigt, en stuurt door.
Koppelpunt extraheert daarnaast ‘stuurinformatie’. Stuurinformatie wordt gebaseerd op de metadata van het bericht en bevat (in deze versie) geen informatie uit de berichtinhoud.
Het begrip ‘stuurinformatie’ wordt in het PvE niet verder geduid. Is, blijkt uit gesprek, vooral een placeholder voor in de toekomst nader in te vullen functionaliteit op basis van nog nader te analyseren informatiebehoefte. +
S
Het beheer van de afspraak ligt bij het Ketenoverleg Eindtoets, maar de afspraak is conceptueel onderdeel van de set aan UWLR-profielen. +
'''Inspelen op beleidswijzigingen'''
De afspraak kent een nauwe relatie met (landelijk) beleid t.a.v. eindtoets PO. De relatie tussen (inhoud van) berichten aan DUO en (inhoud van) berichten tussen LAS en toetssysteem is nader beschreven in de Toelichting processen en berichten Eindtoets PO (hfdst. 2). De eisen aan het resultaatbericht inz. latere verstrekking met BRON komen voort uit het PvE van DUO voor BRON-aanlevering. +
LAS, Digitaal toetssysteem, BRON +
'''Behoeftegerichte en doelgebonden uitwisseling'''
Er worden twee soorten gegevens uitgewisseld: (1) Leerlinggegevens (via EDEXML) van LAS naar Toetsleverancier, en (2) Resultaatgegevens van Toetsleverancier naar LAS. Aansluitend worden gegevens over leerlingen en resultaten verstrekt aan BRON.
Het gaat specifiek om de aanlevering van leerlinggegevens aan de toetser zodat de juiste leerling van de juiste school de juiste toets gaat doen, en van het resultaat van de juiste leerling aan de juiste school. Dit wordt nadrukkelijk toegelicht op basis van deze stelling.
In de beschrijving van het profiel EindtoetsLeerlingen op het UWLR Leerlingenbericht (''Toelichting processen en berichten Eindtoets PO, p.11'') wordt een blok met leerkrachtgegevens benoemd (elders wordt dit niet benoemd). De behoefte voor en doelbinding van uitwisseling van leerkrachtgegevens in het kader van Eindtoets PO wordt niet nader toegelicht.
'''Classificeer alle gegevens- en domeinobjecten met het KOI'''
Het betreft een toepassing van een beschreven standaard (UWLR) waarvoor binnen de ROSA de relatie met KOI reeds beschreven staat. De logische structuur uit ''Toelichting implementatie UWLR Resultaatbericht Eindtoets'' omvat begrippen (nl. Onderdeel, Domein, Subdomein) die een specifieke betekenis hebben binnen de context Eindtoets PO, waarvoor de relatie met KOI niet is gelegd.
'''Gebruik Edukoppeling'''
Er wordt nog geen gebruik gemaakt van Edukoppeling.
'''Gebruik Gegevenswoordenboek DUO'''
Er wordt nergens verwezen naar het DUO gegevenswoordenboek. Echter, er is in het proces wel degelijk een relatie omdat de resultaatgegevens uiteindelijk wel worden gerapporteerd aan DUO. Er zal dus interferentie zijn tussen de gegevensspecificatie die hier van toepassing is en de gegevensspecificatie bij de hier beschreven berichten. +
De benodigde autorisaties (en bijbehorende identificatie- en authenticatiemechanismen) om bestanden te uploaden, te downloaden, en/of handmatig gegevens op te voeren via een portal maken geen deel uit van de specificatie. +
Zowel de heen als de terugberichten hebben betrekking op leerlinggegevens en zijn dus privacy gevoelig. Op dit moment en voor de korte termijn blijft de mogelijkheid om via downloadbare bestanden (ZIP) de gegevens uit te wisselen. Hoewel het via een beveiligde portal gebeurt, is dit per definitie minder veilig dan directe M2M-uitwisseling, want er is geen volledige controle mogelijk op waar de bestanden terecht kunnen komen.
In het geval van aanvullende privacygevoelige informatie (o.a. handicap) kan het alleen via bestandsoverdracht (ook in de toekomstige situatie. Voor aanvullende en/of gewijzigde gegevens omtrent leerlingen kan dit ook nog handmatig worden aangeleverd.
Bij M2M koppelingen wordt nadrukkelijk verwezen naar de Edukoppelingen transactiestandaard en de daarbij geldende beveiligingseisen.
In afspraken rondom het ''Profiel “Eindtoetsleerlingen” op UWLR Leerlingenbericht'' is de aanlevering van eindtoetsleerlingen beperkt tot slechts die leerlingen die (potentieel) de eindtoets zullen maken (leerjaren 8 en 7). LAS-leveranciers sluiten het genereren van bestanden met leerlinggegevens uit andere leerjaren zo veel mogelijk uit, toetsleveranciers mogen een bestand dat gegevens bevat over leerlingen uit leerjaren 6 of lager direct weigeren. +
Er is een wens om naar M2M-uitwisseling mbv Edukoppeling over te stappen. Dit leidt tot druk op betrokken partijen om de benodigde aanpassingen aan hun systemen door te voeren. +
De processtappen zijn uitgewerkt in Hoofdstuk 2 van ''Toelichting processen en berichten Eindtoets PO'' en schematisch weergegeven in Hoofdstuk 3. +
Gestandaardiseerde uitwisseling van deelnemende leerlingen aan en de geboekte resultaten van de Eindtoets PO. +
Het werkingsgebied van de afspraak is primair onderwijs (po), in het bijzonder po-onderwijsinstellingen en leveranciers van een po-eindtoets.. +
Verantwoordelijkheden van ketenpartijen in de diverse processtappen zijn uitgewerkt in Hoofdstuk 2 van ''Toelichting processen en berichten Eindtoets PO''. Zeggenschappen en gegevenssoorten worden daarbij niet expliciet benoemd. +