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
Het afsprakenstelsel heeft als doel om een gelijk speelveld te bieden aan alle betrokken leveranciers van producten, diensten en applicaties. In het architectuurkader is daarom expliciet het volgende architectuurprincipe opgenomen: ‘Het ecosysteem bevat gedefinieerde referentiecomponenten en is interoperabel’. Een referentiecomponent hangt samen met een rol die een leverancier met een applicatie kan vervullen in het ecosysteem.
“referentiecomponenten geven het recht of de plicht om gegevensdiensten aan te bieden of te consumeren.” [1] Een gegevensdienst volgens Edu-V is een set van afspraken binnen het Edu-V afsprakenstelsel die betrekking hebben op: gegevenssoorten en attributen en koppelvlakspecificatie (APIs) en referentiecomponenten. Er wordt op de pagina “Verplichte en optionele gegevensdiensten per referentiecomponent”, precies bijgehouden welke gegevensdiensten verplicht zijn per referentiecomponent.
De referentiecomponenten in het architectuurkader zijn afgestemd op de ROSA en onderverdeeld in de domeinen van het architectuurkader [1]. Echter, een aantal referentiecomponenten zijn specifiek voor het Edu-V afsprakenstelsel en niet voor onderwijsorganisaties die zich baseren op de ROSA.
Edu-V stelt zelf dat er een aantal acties nog nodig zijn om de referentiecomponenten verder te verifiëren en aan te vullen. Bij het referentiecomponent "Onderwijsleeromgeving", wordt bijvoorbeeld net een andere definitie gebruikt dan in het “adviesdocument leermiddelen” van de adviesgroep samenhang, maar ook in de ROSA wordt hier nog van afgeweken. +
In het Edu-V afsprakenstelsel zijn verschillende praktijksituaties opgenomen [1]. De praktijksituaties zijn onderverdeeld bij verschillende werkgroepen. Op dit moment zijn er vier praktijksituaties uitgewerkt:
* Combineren en arrangeren (digitale) leermiddelen
* Verwerven en in gebruik nemen van (digitale) leermiddelen
* Toetsen en examineren
* Evalueren leervoortgang en -resultaten
De detailuitwerkingen van de praktijksituaties bevatten de volgende onderdelen:
# Scenariobeschrijvingen, soms aangevuld met een conceptueel model ter verduidelijking;
# Randvoorwaarden voor de praktijksituatie;
# Functionele specificatie
# Technische specificatie;
# Relevante APIs. +
Het Edu-V architectuurkader is een belangrijk onderdeel van het Edu-V afsprakenstelsel. Volgens de pitch [2] richt het Edu-V afsprakenstelsel zich op de onderwijsdomeinen po, so, vso, vo en mbo. In de documentatie op Confluence [1] staat dat het Edu-V afsprakenstelsel zich richt op het primair, voortgezet, speciaal en middelbaar beroepsonderwijs. +
Het ontwerpgebied governance van de gescande gegevensdiensten is onveranderd ten opzichte van de vorige ROSA scan. Voor een meer uitgebreide analyse van dit scanonderdeel verwijzen we naar: Architectuurscan Edu-V Architectuurkader - ROSA Wiki +
Het ontwerpgebied H2M Interactie van de gescande gegevensdiensten is onveranderd ten opzichte van de vorige ROSA scan. Voor een meer uitgebreide analyse van dit scanonderdeel verwijzen we naar: [[Architectuurscan Edu-V Architectuurkader]] +
Er worden een aantal aanvullende IBP gerelateerde ontwerpeisen genoemd voor het scenario Administratiesystemen onderwijsdeelnemer en medewerker [1]:
* Dataminimalisatie in de objecten: Dit principe houdt in dat alleen de strikt noodzakelijke gegevens worden verzameld en opgeslagen.
* Scheiding van persoonsgegevens: Persoonsgegevens worden gescheiden gehouden van andere informatieobjecten, en er wordt gewerkt met identificatiecodes (IDs) in plaats van directe persoonlijke informatie.
* Scheiding van bijzondere persoonsgegevens en basis persoonsgegevens: Bijzondere persoonsgegevens, zoals demografische gegevens, worden apart gehouden van basis persoonsgegevens. +
Op de gescande pagina’s wordt niet direct gesproken over ontwerpkaders i.r.t. digitale identiteiten. Daarom blijft het ontwerpgebied onveranderd ten opzichte van de vorige ROSA scan. Voor een meer uitgebreide analyse van dit scanonderdeel verwijzen we naar: [[Architectuurscan Edu-V Architectuurkader]] +
Op de pagina ´Methodiek en modellen” [1] wordt beschreven: “In het afsprakenstelsel Edu-V worden gegevensdiensten tussen referentiecomponenten uitgewerkt. Bij de uitwerking van deze gegevensdiensten benutten we de AMIGO-aanpak van Edustandaard.”
In de pitch staat: “De gegevensdienst leerresultaten is gericht op uniformiteit van de uitwisseling van leerresultaten in het funderend
onderwijs. De gegevensdienst bouwt voort op reeds uitgewerkte standaarden UWLR-Resultaatuitwisseling en
Summatieve toetsresultaten vo en biedt een modern alternatief voor deze (legacy)standaarden.” [2]
In iedere gescande praktijksituatie worden de conceptuele en logische uitwisselingsmodellen (zie AMIGO modellenmatrix) uitgewerkt. Deze zijn meer gedetailleerd dan het conceptuele model dat is gescand in de vorige architectuurscan. Ook worden de API specificaties uitgewerkt. [2] +
Deze (lite) scan richt zich specifiek op alle Edu-V gegevensdiensten rondom de praktijksituaties “Verwerven en in gebruik nemen leermiddelen”
en de gegevensdienst “Administreren leerresultaten” binnen de praktijksituatie “Toetsen en examineren”. [2]
Daarnaast valt het scenario “Administratiesystemen onderwijsdeelnemer en -medewerker”
(Scenario binnen praktijkscenario Doorgifte identiteiten [2]) en de gerelateerde API specificaties binnen de scope van deze scan. Dit scenario richt zich op uitwisseling van gegevens met betrekking tot onderwijsaanbod, onderwijsmedewerkers, onderwijsdeelnemers en onderwijsinrichting. (Administratiesystemen onderwijsdeelnemer en –medewerker
, [2]) +
Het ontwerpgebied M2M Interactie van de gescande gegevensdiensten is onveranderd ten opzichte van de vorige ROSA scan. Voor een meer uitgebreide analyse van dit scanonderdeel verwijzen we naar: [[Architectuurscan Edu-V Architectuurkader]] +
Volgens het conceptuele model van “Verwerven en in gebruik nemen leermiddelen” [1] worden de volgende referentiecomponenten gebruikt binnen de scenario’s:
* Bestelomgeving leermiddelen
* Aanspraakmanager
* Licentieregistratie
* Leermiddelenportaal
* Gebruiksomgeving digitaal leermateriaal
* Digitaal toetssysteem
* Leermiddelen dashboard
Additioneel worden hier in het gedetailleerde model de volgende referentiecomponenten aan toegevoegd:
* Administratiesysteem onderwijsdeelnemer
* Administratiesysteem onderwijsmedewerker
* Leveranciersspecifieke leermiddelencatalogus
* Overkoepelende leermiddelencatalogus
* Selectieomgeving leermiddelen
* Distributiefaciliteit
* Ordersysteem leermiddelen
Binnen het scenario “Administratiesysteem leerresultaten” [1] worden de volgende rc’s gebruikt:
* Digitaal toetssysteem
* Administratiesysteem leerresultaten
Het scenario: Administratiesystemen onderwijsdeelnemer en –medewerker, heeft betrekking op RCs:
* Administratiesysteem onderwijsdeelnemer
* Administratiesysteem onderwijsmedewerker
Daarnaast wordt ook een relatie benoemd met de ketenvoorziening RIO [2] +
De atlassian pagina over de praktijksituaties: “[https://edu-v.atlassian.net/wiki/spaces/AFSPRAKENS/pages/11927579/Verwerven+en+in+gebruik+nemen Verwerven en in gebruik nemen leermiddelen]” [1], bevat een gedetailleerde uitwerking van 18 scenario’s. Elk scenario beschrijft de interacties tussen een actor, zoals een onderwijsmedewerkers, onderwijsdeelnemers of leverancier, en verschillende referentiecomponenten.
De pagina over de praktijksituatie “[https://edu-v.atlassian.net/wiki/spaces/AFSPRAKENS/pages/30113793/Toetsen+en+examineren Toetsen en examineren]” [1], beschrijft twee scenario’s, waarbij alleen “Administreren leerresultaten”, relevant is voor deze scan: Dit scenario gaat over het administreren van leerresultaten in een RC “Administratiesysteem leerresultaten”.
Plannen van toetsen en examens is een ander scenario dat nog niet nader is uitgewerkt. +
In de pitch staat: “De praktijksituatie
Toetsen en examineren richt zich niet op het middelbaar beroepsonderwijs.”. Gegevensdiensten in relatie met deze praktijksituatie zijn onderdeel van deze scan.
Het werkingsgebied van de gegevensdiensten is verder onveranderd ten opzichte van de vorige ROSA scan. Voor een meer uitgebreide analyse van dit scanonderdeel verwijzen we naar: [[Architectuurscan Edu-V Architectuurkader|Architectuurscan Edu-V Architectuurkader - ROSA Wiki]] +
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. +