Eigenschap:Toelichting relatie met ROSA
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
De Voorziening CA past binnen de principes van dit ontwerpgebied +
Op onderdelen ontbreken duiding van betekenis en doelbinding.
'''Behoeftegerichte en doelgebonden gegevens uitwisseling'''
Onduidelijk waarom uitwisseling van geboortedatum en geslacht uit CA naar SIS noodzakelijk is.
'''Registreer de betekenis van nieuwe gegevens'''
De (geharmoniseerde) aanmeldgegevens ihkv CA zijn op te vatten als een nieuwe gegevenssoort. De gegevenssets zijn vooral syntactisch beschreven (welke velden); een toelichting / nadere duiding van betekenis ontbreekt, evenals een overkoepelend (informatie)model.
'''Semantiek in berichtuitwisseling is traceerbaar'''
Onderdelen van de gegevensspecificaties zijn ontleend aan andere bronnen. Dit is tekstueel in het PvE aangeduid. +
Identificatie met eID sluit aan bij ontwerpkader Toenadering tot eID.
Hoe de identificatie van andere actoren (beheerder, gebruiker van analysedata) plaatsvindt is nog niet duidelijk. +
Een aantal belangrijke IBP uitgangspunten dient verder uitgewerkt te worden.
'''Privacy by design'''
Gegevens worden in de analyseomgeving geanonimiseerd. Vanuit oogpunt van dataminimalisatie zou dat bij voorkeur al voor de aanlevering aan de analyseomgeving (i.e. binnen het transferpunt) plaatsvinden, of wellicht via een tussengelegen separate functionele eenheid.
De voorziening CA wordt tevens een voorziening die alle mbo-aanmeldingen analyseert - ook de aanmeldingen die niet via CA verlopen.
'''Gegevens worden niet langer bewaard dan strikt noodzakelijk'''
Onduidelijk wat de bewaartermijn is van div. gegevens (w.o. ruwe aanmeldgegevens en analysegegevens).
'''Duidelijke eisen en verwachtingen;
Transparantie over maatregelen'''
Het PvE specificeert wel wat er wordt uitgewisseld, maar besteed weinig aandacht aan het hoe (in termen van bijbehorende maatregelen).
Een BIV-classificatie van betrokken gegevens ontbreekt.
Eisen en verwachtingen omtrent gegevensgebruik (m.n. export ruwe data) niet nader gespecificeerd. +
Het betreft een deel van het ketenproces aanmelden en inschrijven uit ROSA, nl. aanmelden bij instelling. Beheer van aanmeldingen gebeurt door instellingen zelf (in SIS). +
Binnen andere werkingsgebieden zijn al vergelijkbare voorzieningen gerealiseerd (HO / Studielink). +
Binnen de ketenfunctie [[Id-a14b574c-baf0-4100-a143-ae4b82f96ea5|Instroom, Doorstroom en Uitstroom]] gaat het enkel om het realiseren van een voorziening t.b.v. Instroom.
Binnen de ketenfunctie Informatieverwerking betreft het de realisatie van een centrale (generieke) voorziening.
Binnen de ketenfunctie Informatiestandaardisatie betreft het de (sectorale) harmonisatie van aanmeldgegevens voor de persoonlijke omgeving van de student. +
Het werkingsgebied, bestaande uit MBO-instellingen, MBO-Voorzieningen (als MBO-ondersteunende organisatie), Softwareleveranciers (SIS) en [[DUO]], valt volledig binnen het onderwijsdomein. +
Onduidelijk of het transferpunt c.q. beheerder voorziening CA eigen zeggenschap heeft over bepaalde gegevens, of alleen als (niet-verantwoordelijke) intermediaire verwerker optreedt.
Hoewel er wel diverse zeggenschappen worden beschreven of geïmpliceerd, zijn deze versnipperd door het PvE opgenomen. Een eenduidig overzicht ontbreekt. +
Het gaat hier om een uitwisseling die alleen betrekking heeft op de onderwijssector VO. +
Niet alle belangen van groepen belanghebbenden zijn in kaart gebracht.
(Relatie met [https://rosa.wikixl.nl/index.php/Id-3e1c60f7ddc94138b34893bb740db5c5 Alle belangen in kaart])
Het is niet duidelijk hoe de LAS leveranciers betrokken worden bij het beheer van CEVO.
(Relatie met [https://rosa.wikixl.nl/index.php/Id-71feaaeab2f649c29a5e437a35eff6c2 Betrokken belanghebbenden])
De CEVO documentatie beschrijft niet hoe de relaties met andere afspraken wordt bewaakt.
(Relatie met [https://rosa.wikixl.nl/index.php/Id-92b8a7216c244914b658bdb8704be371 Bewaak relaties met andere afspraken]) +
CEVO is het eerste gescande initiatief dat de AMIGO methodiek toepast. CEVO maakt semantiek van de berichtenuitwisseling letterlijk traceerbaar naar de ROSA informatiemodellen. (Relatie met [https://rosa.wikixl.nl/index.php/Id-a09f11ed-c3cf-43f6-b031-185898c7ab18 Semantiek in berichtuitwisseling is traceerbaar])
Het actuele Edukoppeling REST/SaaS-profiel wordt toegepast voor de gegevensuitwisseling zoals omschreven in CEVO.
(Relatie met [https://rosa.wikixl.nl/index.php/Id-fd10bf7a-e960-4484-8e19-bd8b86e7d911 Gebruik Edukoppeling voor vertrouwelijke gegevensuitwisseling]) +
CEVO gebruikt onderwijsidentiteit in de uitwisseling van kandidaatgegevens. (Relatie met [https://rosa.wikixl.nl/index.php/Id-184c6bfd-f81e-4035-8e73-daaea7f0f3ac Gebruik onderwijsidentiteit waar nodig])
CEVO geeft de optie om gebruik te maken van ECKiD met LAS-key als fallback optie. Het gebruik van ECKiD heeft in de afspraak de voorkeur.
(Relatie met: [https://rosa.wikixl.nl/index.php/Id-f1fa49e1-4376-46f6-9fe7-570aa2e8ce65 Gebruik pseudoniem waar mogelijk]) +
Er is voldoende transparantie over IBP maatregelen binnen CEVO. Het onderscheid tussen openbare informatie en specifieke informatie nog duidelijker worden gemaakt door een BIV classificatie toe te voegen.
(Relatie met: [https://rosa.wikixl.nl/index.php/Id-b7fcde30-fc9e-4ec0-99c0-6d22f8bf579e Transparantie over maatregelen])
Maatregelingen zijn genomen om de aantasting van integriteit te voorkomen in de uitwisseling van CEVO.
(Relatie met [https://rosa.wikixl.nl/index.php/Id-5a3f56f2-142a-4e8e-922e-b33799c44ff4 Voorkom aantasting van integriteit])
CEVO wisselt alleen persoonsgegevens uit wanneer dit strikt noodzakelijk is voor de uitwisseling.
(Relatie met: [https://rosa.wikixl.nl/index.php/Id-6905cf44-3de1-41b3-b56f-4b44db4fcb1f Voorkom ongewenste traceerbaarheid en vindbaarheid])
De weergavekenmerken, die tijdens de toetsafname op het scherm worden getoond, zorgen ervoor dat de persoonsgegevens van een examenkandidaat kunnen worden gevalideerd.
(Relatie met [https://rosa.wikixl.nl/index.php/Id-5837b66d-8bfe-4034-80df-3eb1c0c5dc0a Valideer persoonsgebonden gegevens]) +
Er is een relatie met het ketenproces Toetsen, examineren en oefenen en onderliggende ketenprocessen zoals Plannen van afname en Analyse van de afname. +
CEVO heeft relaties met meerdere referentiecomponenten:
* Facet heeft relatie met [https://rosa.wikixl.nl/index.php/Id-ded9e8d9-4034-48f0-abbc-b5a5aeaff9f4 Digitaal toetssysteem].
* Magister en Somtoday heeft relatie met [https://rosa.wikixl.nl/index.php/Id-0a5b23bf-02aa-42d7-8ce6-fe1b736092ba Leerlingadministratiesysteem]
Er zou ook een relatie met het OSR gelegd kunnen worden, maar deze zit nog niet in de ROSA. +
Centrale examens VO heeft raakvlak met ketenfuncties “Toetsing en diplomering” en “informatiestandaardisatie”. +
Het werkingsgebied van CEVO omvat het VO, CvTE en DUO. +
Uit de documentatie werd niet duidelijk hoe de zeggenschappen liggen. +
Binnen het project is zicht op de belanghebbenden en de wijze waarop zij betrokken worden.
Kanttekening ten aanzien van het ontwerpkader B'''ewaak relaties met andere afspraken'''''Cursief gedrukte tekst'' – in het PRD worden verschillende afhankelijkheden benoemd tussen de Dienst Verwerkersovereenkomsten en andere (soms nog te ontwikkelen) voorzieningen. Het is onduidelijk hoe de afstemming voor deze afhankelijkheden vormgegeven is of wordt. Op dit onderdeel dus: Onbekend. +
Er moet nog worden bepaald welke rollen er worden onderscheiden en welk (eHerkenning-)betrouwbaarheidsniveau daarbij moet worden gehanteerd. Het schema in Afb. 14 toont een stap waarin een inlogmethode wordt geselecteerd (eHerkenning of Entree). In de tekst wordt niet toegelicht wanneer / voor welke functies of delen van de dienst Entree gebruikt kan worden. +
Geeft invulling aan de ontwerpkaders uit het ontwerpgebied IBP. +
De dienst is niet gericht op specifieke ketendomeinen en/of -processen, maar ondersteunt de invulling van een randvoorwaarde (het zorgen voor ondertekende verwerkersovereenkomsten) die geldt voor alle ketenprocessen waarin verwerking door verwerkers plaatsvindt. +
Het model impliceert dat de Onderwijsinstelling optreedt als verwerkingsverantwoordelijke, terwijl in de tekst van het PRD op het Bestuur als verwerkingsverantwoordelijke wordt benoemd.
Het model impliceert dat Verwerkingsactiviteiten in de voorziening worden geregistreerd, waar in de tekst wordt aangegeven dat dat niet zo is.
De entiteiten in het informatiemodel zijn gerelateerd aan entiteiten uit het ROSA IV-domein IBP, het FORA Informatiemodel Bedrijfsvoering (geen onderdeel van deze scan), en begrippen uit het ROSA Begrippenkader. Er is niet uitgewerkt in hoeverre deze modellen als uitgangspunt gebruikt zijn.
De entiteiten zijn ook gerelateerd aan het Gemeenschappelijk Informatiemodel voor Voorzieningen dat is opgenomen in [https://www.noraonline.nl/wiki/Gemeenschappelijke_Informatiemodel_voor_Voorzieningen NORA], en mede voortkomt uit de Softwarecatalogus/Dienst Product Catalogus casus in het onderwijs. Het is onduidelijk in hoeverre dit model, en het bijbehorende uitgangspunt dat deze use case vooral een dataintegratievraagstuk betreft, zijn weerslag heeft in de opzet van de Dienst Verwerkersovereenkomsten. +
De beoogde functionaliteit is niet altijd eenduidig beschreven. De functie ‘Registratie verwerkingsactiviteiten’ (par 3.2) is in tegenspraak met de beperking tot registratie van verwerkersovereenkomsten.
Het doel ‘Applicatielandschap inzichtelijk maken’ genoemd in Afb. 5 e.v. lijkt geen doel van de Dienst Verwerkersovereenkomsten, maar eerder van de in het PRD benoemde (gerelateerde) voorziening Softwarecatalogus/Dienst Product Catalogus.
De onderlinge afhankelijkheden tussen de verschillende voorzieningen behoeft verdere uitwerking. Het is bijv. verwarrend dat in Afbeelding 15 functionaliteiten en gegevens die bij de Dienst Product Catalogus horen, in scope van het MVP van de Dienst Verwerkersovereenkomsten worden geplaatst. +
De Dienst Verwerkersovereenkomsten valt binnen het IV-domein Inrichten IBP. In dit IV-domein is o.a. de relatie tussen verwerker en verwerkingsverantwoordelijke uitgewerkt in relatie tot een Gegevensverwerkend Systeem. De relatie tussen (de modellen in) het PRD en het IV-domein in ROSA zijn in het PRD niet verder uitgewerkt of toegelicht. +
het werkingsgebied (funderend onderwijs) valt binnen de reikwijdte van ROSA c.q. het werkingsgebied onderwijs. +
De Entree Federatie heeft raakvlakken met het ROSA basisprincipe Koppelen - niet kantelen.
De implementatie van dit principe leidt tot een relatie met het afgeleide ROSA principe Een gezamenlijke basisinfrastructuur. Deze relatie wordt versterkt door de keuze om de nieuwe versie van de Entree Federatie te baseren op software die binnen het HO wordt toegepast. +
H4 van de Marktverkenning (2) beschrijft de positie van alle groepen belanghebbenden en heeft daarom een relatie met ontwerpkader '''Alle belangen in kaart'''.
Er is een relatie met '''Betrokken belanghebbenden'''. Er is bekend hoe de groepen belanghebbende betrokken zullen worden bij het beheer/doorontwikkelproces.
Relaties met andere afspraken worden bewaakt door bijvoorbeeld aan te sluiten bij werkgroepen met overlappende doelstellingen. Daarom wordt voldaan aan het ontwerpkader '''Bewaak relaties met andere afspraken'''. +
De inrichting van de Entree Federatie is gericht op het minimaliseren van de uit te wisselen attributen, waarmee invulling gegeven wordt aan het basisprincipe '''Behoeftegerichte en doelgebonden gegevensuitwisseling'''. +
Er is een relatie met ROSA ontwerpkader Meerdere expliciete betrouwbaarheidsniveaus. Het inrichten van deze betrouwbaarheidsniveaus is niet de verantwoordelijkheid van de EF, maar zal dit wel gaan ondersteunen.
Daarnaast is er een relatie met het ontwerpkader Marktpartijen kunnen IAA-diensten leveren, aangezien de EF de dienstverlening van ID providers makkelijker maakt. +
Op pagina 14 van de technische verkenning (1) worden continuïteit, performance en betrouwbaarheid genoemd als de focuspunten om de architectuur te verbeteren. Deze focuspunten hebben veel raakvlakken met het ROSA ontwerpgebied IBP.
Het Attribute release policy heeft een relatie met ROSA ontwerpkader Duidelijke eisen en verwachtingen.
De uitgangspunten op p.14 van de technische verkenning (1) hebben een relatie met ROSA ontwerpkader Continuïteit van de dienstverlening. +
Volgens het stuk Context uit H2 van de Marktverkenning (2) is de Entree Federatie een aanmelddienst. Daarom heeft het een relatie met alle ketenprocessen. +
Uit de ROSA Wiki (7) wordt duidelijk dat er een relatie is met het referentiecomponent Toegangsdienst educatieve content. +
De Entree Federatie heeft een relatie met de toepassingsgebieden Identificatie en toegang en IBP. +
De Entree Federatie heeft betrekking op het PO, VO en MBO. Daarnaast bestaat er ook een relatie met software leveranciers. In het bijzonder softwareleveranciers die opereren als Identity en Service Providers. (Bron: Pitch (4)) +
Entree is zelf ook idP, maar daar is een aparte dienst voor gemaakt. Er zitten geen identiteiten in de Entree federatie zelf (alleen bij Idps).
Uit gesprekken blijkt dat de EF de uitwisseling van attributen en het goed vastleggen van zeggenschappen op attributen faciliteert. Entree is daarin geen verantwoordelijke partij. Rollen en verantwoordelijkheden zijn (juridisch) geregeld in een contract voor aansluiting. +
Het SaaS/REST-profiel brengt gemeenschappelijkheid in RESTful gegevensuitwisseling in het onderwijsdomein. +
REST-profiel wordt duidelijk gepositioneerd t.o.v. de bestaande WUS-profielen.
De tekst is onduidelijk over of XML over REST ‘verboden’ is, of ontraden wordt. Er zijn scenario’s waarin XML over REST wenselijk kan zijn, m.n. De overgang van WUS naar REST, waarbij bestaande XML-gegevensstructuren tijdelijk gehandhaafd blijven.
Afwijkingen op nationale afspraken zijn grotendeels beargumenteerd en niet in fundamentele tegenspraak. +
Toepassing voor zowel bevragingen als meldingen, gebruikmakend van generieke bedrijfstransactiepatronen uit Edukoppeling architectuur. Deze ‘atomaire’ patronen kunnen worden gecombineerd tot complexe, toepassingsspecifieke interactiepatronen. +
de invulling van IAA sluit aan bij bestaande methoden en voorzieningen (OIN, PKI, OSR).
(Verplichte) toepassing van het OSR voor RESTful-gegevensuitwisseling tussen meerdere gelijkwaardige ketenpartijen stelt aanvullende eisen aan registratie van diensten in en de werking van het OSR. +
Het SaaS/REST-profiel brengt gemeenschappelijkheid in RESTful gegevensuitwisseling in het onderwijsdomein
De opmerkingen in de tekst over vertrouwelijke gegevens in GET-parameters zijn in kennelijke tegenspraak.
* ‘Vertrouwelijk’ is breder dan ‘persoonsgegevens’
* Specifiek voor persoonsgegevens geldt AVG (‘passende maatregelen’)
* Pseudonimisering als specifieke maatregel is mogelijk niet in alle situaties toepasbaar. (Uit toelichtende gesprekken blijkt overigens dat ‘pseudonimisering’ hier gelezen moet worden als het gebruiken van betekenisloze identifiers.) +
Het REST-SaaS-profiel voegt een gestandaardiseerde werkwijze voor het gebruik van REST-APIs toe aan de Edukoppeling-architectuur. +
Het REST/SaaS-profiel valt binnen de Edukoppeling architectuur waarvan het werkingsgebied het gehele onderwijsdomein betreft. +
Het profiel FDE-set bouwt voort op de bestaande standaard EDEXML (Compliant relatie met [https://rosa.wikixl.nl/index.php/Id-b269d84e-d15b-4c83-8946-7a69013c288d Koppelen - niet kantelen]). +
In de documentatie staat niet omschreven hoe de relaties met UWLR en EDEXML worden bewaakt door de werkgroep Distributie en toegang. (Non-conforment relatie met [https://rosa.wikixl.nl/index.php/Id-92b8a7216c244914b658bdb8704be371 Bewaak relaties met andere afspraken])
Daarnaast is het onduidelijk of de groepen belanghebbende in kaart zijn gebracht en wat de verwacht impact zal zijn van het toepassen van de AMIGO methodiek. +
In FDE-set §2.5 staan de definities van nieuwe gegevens die aan EDEXML worden toegevoegd.
(Relatie met [https://rosa.wikixl.nl/index.php/Id-9573b8ef-992a-43ad-8b05-44444d37666e Registreer de betekenis van nieuwe gegevens])
Aangezien het ECK-iD wordt uitgewisseld, samen met vertrouwelijke gegevens is het van groot belang dat Edukoppeling wordt toegepast.
(Compliant relatie met [https://rosa.wikixl.nl/index.php/Id-fd10bf7a-e960-4484-8e19-bd8b86e7d911 Gebruik Edukoppeling voor vertrouwelijke gegevensuitwisseling]) +
Het ECK iD wordt gebruikt wanneer deze beschikbaar is. Wanneer deze niet beschikbaar is kan worden teruggevallen op een LAS-key.
(Relatie met [https://rosa.wikixl.nl/index.php/Id-f1fa49e1-4376-46f6-9fe7-570aa2e8ce65 Gebruik pseudoniem waar mogelijk]) +
Uit de documentatie van de FDE-set kan worden opgemaakt dat er maatregelen zijn genomen mbt. IBP, bijvoorbeeld de toepassing van Edukoppeling. Waarom dit invulling geeft aan IBP eisen en welke eisen dit zijn, wordt niet duidelijk uit de documentatie. (Non- conforment relatie met [https://rosa.wikixl.nl/index.php/Id-b7fcde30-fc9e-4ec0-99c0-6d22f8bf579e Transparantie over maatregelen])
Vertrouwelijke persoonsgegevens en het ECK iD zijn onderdeel van de FDE-set. Aan afnemers van de FDE-set worden onvoldoende eisen gesteld om te voorkomen dat het ECK iD traceerbaar is naar persoonsgegevens.
(Non-conforment relatie met [https://rosa.wikixl.nl/index.php/Id-6905cf44-3de1-41b3-b56f-4b44db4fcb1f Voorkom ongewenste traceerbaarheid en vindbaarheid]) +
Aangezien het gaat om een profiel om educatieve content uit te kunnen wisselen, is er raakvlak met het ketenproces [https://rosa.wikixl.nl/index.php/Id-ccf809a2-6ebd-48e3-bac5-48a195fd7700 Educatieve contentketen]. In het specifiek met het bedrijfsproces Leermiddelen distribueren en toegang geven.
Daarnaast zou ook een relatie kunnen bestaan met [https://rosa.wikixl.nl/index.php/Id-708caf28-d696-4962-8955-fa623b666676 Selecteren en beschikbaar stellen van het materiaal] op basis van de definitie van dit ketenproces, maar inhoudelijk lijkt dit proces zich te beperken tot materiaal voor Toetsen, Examineren en Oefenen. +
in het profiel wordt de term Distributeur Applicatie gebruikt terwijl de ROSA dit [https://rosa.wikixl.nl/index.php/Id-e3c985fa-04dd-4abe-a491-509791e25b7f Distributeursportaal ]noemt. +
Het profiel FDE-set voegt een extra laag '''informatiestandaardisatie''' toe op de EDEXML standaard. +
Het profiel FDE-set (versie 1.1) is een profiel voor het VO en MBO op de EDEXML (bron: https://www.edustandaard.nl/standaard_afspraken/fijndistributie/fde-set1-0/ ), daarom is het werkingsgebied van de FDE-set het VO en het MBO. +
Uit de documentatie wordt niet duidelijk hoe zeggenschappen zijn belegd. +
In lijn met Eenmalige registratie, meervoudig gebruik +
de adviezen ut de vorige architectuurscan zijn opgevolgd. +
De wijze waarop buitenlandse adressen worden ondersteund en met huisnummers wordt omgegaan is in deze versie expliciet beschreven. Ook de overige aanvullingen zijn in paragraaf 2.5 vastgelegd (Ontwerpkader: Registreer de betekenis van nieuwe gegevens). +
Middels een werkingsregel wordt het gebruik van ECK-iD afgedwongen wanneer deze voor de leerling voorhanden is. Is deze er niet, dan moet het LAS-key worden gebruikt.
<br>
Het is echter onduidelijk waarom het gebruik van LAS-key in deze versie verplicht is gesteld, en waarom het (verplichte) element Leerling-/studentnr is toegevoegd. In de wijzigingen is slechts beschreven dat het element is toegevoegd. +
In de paragraaf IBP wordt toegelicht hoe de verantwoordelijkheden t.a.v. IBP bij toepassing van deze afspraak zijn belegd, mede in relatie tot het privacyconvenant. In deze paragraaf wordt ook verwezen naar Edukoppeling en UBV-TLS, alsmede naar de relevante onderdelen van de UWLR-specificatie waar deze afspraak op voortbouwt. +
De ketensamenwerking ‘fijndistributie in het vo’ geeft een specifieke invulling aan het ketenproces ‘Leermiddel verwerven’. +
De Distributeurapplicatie is in de implementatie-onafhankelijke ketenprocesuitwerking in ROSA te mappen op de referentiecomponent ‘Leermiddelmarktplaats’. +
valt binnen het ketendomein ''Inhoud van het onderwijs'', in het bijzonder het ketenproces Leermiddel verwerven. +
Het werkingsgebied vo valt binnen de ROSA werkingsgebieden. +
Paragraaf 2.1 geeft inzicht in de interactie tussen DA (distributeur) en LAS (school), aangevuld met een tekstuele toelichting op het (verantwoordelijkheden binnen) het proces. +
Het ROSA ontwerpkader [[Id-71feaaeab2f649c29a5e437a35eff6c2|"Betrokken belanghebbenden."]] benadrukt het belang van het betrekken van alle relevante stakeholders in het proces. In het PrSA document wordt dit principe erkend en wordt aangegeven dat DUO zich inzet voor transparantie door stakeholders op verschillende momenten in het proces te informeren. Echter, de termen "leverancier", "bronhouder" en "data provider" komen op meerdere plekken in het document terug, maar het wordt niet duidelijk wie dit precies zijn.
Daarnaast is het opmerkelijk dat, hoewel de Wet register onderwijsdeelnemers aangeeft dat basisgegevens kunnen worden verstrekt aan verschillende onderwijsverenigingen, deze organen niet expliciet worden genoemd in de PrSA van GABI. Ze worden alleen kort benoemd in de PSA documenten voor SANE en MDP. Dit kan worden gezien als een gebied voor verbetering in termen van [[Id-3e1c60f7ddc94138b34893bb740db5c5|transparantie en duidelijkheid voor alle betrokken stakeholders]]. +
Er zijn nog geen ontwerpkaders uitgewerkt in de ROSA op het gebied van H2M. +
Het wordt niet uit de documentatie duidelijk of een passend afspraken stelsel voor IAA wordt gehanteerd dat aansluit bij de onderwijsketen. +
In het PrSA document wordt het principe van "Gegevens bij de bron" en "Enkelvoudig beheer, meervoudig gebruik" benadrukt, wat in lijn is met het ROSA ontwerpkader [[Id-ae3fc0b0-39a7-4f66-93ed-ec74cdf0307f|"Gegevens worden niet langer bewaard dan strikt noodzakelijk"]].
Daarnaast 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. Dit is in lijn met het ROSA ontwerpkader [[Id-b7fcde30-fc9e-4ec0-99c0-6d22f8bf579e|"Transparantie over maatregelen"]], waarbij ketenpartijen transparant zijn over de genomen privacy- en beveiligingsmaatregelen. +
De definities lijken niet in frictie te zijn met het ROSA begrippen [[E861026a-f92e-47da-9b2a-1a691a3a99e3|identity and access management]] in dit geval, maar het is duidelijk dat nog niet direct gebruik is gemaakt van begrippen hieruit in het PrSA. Dit heeft daarom een explain relatie met [[Id-3d2f6976230c4289b54fcf4f32d769eb|Hanteer begrippen uit het ROSA begrippenkader]]
Uit de documenten wordt niet duidelijk hoe precies op HORA en HOSA wordt aangesloten. Ook is het niet duidelijk hoe de ROSA wordt toegepast of hoe gebruik wordt gemaakt van andere Edustandaard afspraken. Dit kan leiden tot onduidelijkheden en inconsistenties in de implementatie en het gebruik van de principes en standaarden. Is er bijvoorbeeld relatie met de [https://www.edustandaard.nl/standaard%20afspraken/doorstroommonitor/doorstroommonitor-6-0/ Doorstroommonitor (DSM) - Doorstroommonitor 6.0]. Dit heeft raltie met ROSA ontwerpkaders [[Id-2a6e58fa46054fd5b8288d319eb81c17|Sluit aan op ketenprocesuitwerkingen in ROSA]] en [[Id-12cae8bdcd7c4c5493dec58d9f4c1911|Hanteer de stappen uit de AMIGO-aanpak]]. +
GABI is nog opzoek naar de implicaties die uitvoering van de wet WRO heeft op ROSA ketenprocessen. Uit analyse van de context van GABI, wet WRO, is de definitie van basisgegevens af te leiden. Deze basisgegevens hebben betrekking op gegevens die in de Edustandaard afspraak Doorstroommonitor worden verwerkt. De tekst van de WRO stelt dat deze gegevens alleen nog maar worden verstrekt aan de onderwijsraden, wanneer sprake is van een specifieke doelbinding.
Daarom is een directe relatie te leggen met in ieder geval het ketendomein [[Id-59614c44c25743adb0a7331896cc1775|"Organisatie van het onderwijs"]]. In het speciaal wordt in ieder geval het ketenproces [[Id-5db9617678fe495cbae3185d0a0f52bc|Doorstroom monitoren]] geraakt. Waarschijnlijk heeft GABI bredere impact dan alleen op dit ketenproces. +
Er zijn nog geen ontwerpkaders uitgewerkt in de ROSA op het gebied van M2M +
De GABI-afnemersplatformen, die verantwoordelijk zijn voor het gebruik van de gegevens uit de distributieplatformen, kunnen mogelijk een relatie hebben met de ketenvoorzieningen Vensters en XBRL Onderwijsportaal.
[http://Id-cffdc104-0654-4072-ac0e-3c8ee57be7f9 Vensters] is een voorziening die onderwijsbesturen en hun onderwijsaanbieders ondersteunt om op transparante wijze verantwoording af te leggen over hun onderwijs. Het bestaat uit modules waarmee gebruikers zelf de regie hebben op informatievoorziening en verantwoording. Dit kan mogelijk een raakvlak hebben met de afnemersplatformen van GABI, die ook gericht zijn op het gebruik van gegevens voor verschillende doeleinden.
[[Id-6547e24b-b439-41f7-9ef8-32e2d8708068|XBRL Onderwijsportaal]] ondersteunt de digitale aanlevering van de jaarcijfers door onderwijsbesturen. Dit kan ook een raakvlak hebben met de afnemersplatformen van GABI, die mogelijk ook betrokken zijn bij het beheer en gebruik van dergelijke gegevens.
Echter, aangezien de verbinding met het ketenproces doorstroom monitoren niet expliciet is gelegd in de GABI-documenten, is dit een aanname van wat de architectuur zou kunnen zijn, niet van wat de architectuur van GABI nu is. Daarom is de relatie met deze ketenvoorzieningen op dit moment onbekend. +
GABI beschrijft niet een directe relatie met ketenprocessen in de ROSA. Mogelijk zou wel een relatie met scenario's die het ketenproces Doorstroom monitoren weergeven mogelijk zijn. Deze scenario's worden nog uitgewerkt in de ROSA. +
De uitwerking van ROSA Werkingsgebieden benadrukt het belang van het duidelijk definiëren van het gebied waarbinnen een bepaalde architectuur of systeem opereert. Op het moment van scannen is de architectuur van GABI vooral op de context van DUO gericht, maar de wet WRO, waarvan GABI de uitvoering gaat ondersteunen, heeft bredere implicaties die direct impact hebben op in ieder geval alle onderwijsraden. +
Aangezien basisgegevens niet expliciet worden benoemd als de scope van GABI kunnen ook de Zeggenschappen niet verder uitgewerkt worden. +
De relatie met ROSA is sterk afhankelijk van de mate van afstemming met andere afspraken binnen de keten zoals RIO en de OO-API. HOVI is op het moment nog niet op deze afspraken afgestemd, maar voor het komende jaar zijn er wel plannen om dit te doen. +
Het Governance-document beschrijft de verschillende belanghebbenden rondom HOVI, de governancestructuur en het eigenaarschap van de infrastructuur, de data en de standaard.
Bewaking van relaties met andere standaarden is een aandachtspunt. +
Uit de beschikbare brondocumentatie werd niet duidelijk hoe in de architectuur van HOVI invulling wordt gegeven aan het ontwerpgebied Gegevensuitwisseling in de keten. +
Om als afnemer gebruik te kunnen maken van de HOVI infrastructuur, moet de afnemer zich registreren om toegang te kunnen krijgen. Het PvE geeft aan dat er een aansluiting op SurfConext mogelijk moet zijn. Hoe deze aansluiting van de architectuur is ingevuld is onbepaald op basis van gescande documentatie. +
De eisen die het gebruik van HOVI stelt aan afnemers en instellingen, de verantwoordelijkheden die dat met zich meebrengt en de verwachtingen die partijen over en weer mogen hebben zijn nog onvoldoende duidelijk gespecificeerd. +
De HOVI heeft hoofdzakelijk een relatie met Voorlichten over onderwijsaanbod. +
HOVI is de opvolger van HODEX, en biedt voor het ho een centrale database opleidingsaanbod. +
De HOVI-standaard is een infrastructuur voor opleidingsinformatie. Volgens de HOVI spec v.0.92 §1.0, is de HOVI gebaseerd op de concepten: centrale database, openbare informatie en gestandaardiseerd.
Op basis van HOVI spec v.0.92 §1.0 heeft de HOVI betrekking op de ROSA toepassingsgebieden: Instroom doostroom en uitstroom, leerrouteplanning, informatieverwerking en informatiestandaardisatie. +
HOVI heeft alleen betrekking op het Hoger Onderwijs werkingsgebied van de ROSA. (HOVI spec v.0.92 §1.1) +
Alle zeggenschappen krijgen in het Governance document een duidelijke invulling. +
Gemeenschappelijkheid in informatiehuishouding (non-conformant):
Implementatie-afhankelijkheden conflicteren met het principe van technische interoperabiliteit vanuit een gemeenschappelijke en neutrale basisinfrastructuur. Voor een brede toepasbaarheid van de specificatie dient deze onafhankelijk van implementatie-afhankelijkheden te zijn.
Eenmalige registratie, meervoudig gebruik (conformant): ontsluiting van detailinformatie via dashboard; detailinformatie blijft in de oorspronkelijke omgeving en wordt niet naar het dashboard overgebracht (tevens ontwerpkader Doelbinding) +
De uitwisseling van oefenresultaten voegt nieuwe concepten en mogelijkheden toe aan bestaande uitwisselingen, i.h.b. aan [[UWLR]].
Uniformering van begrippen op het terrein van ‘vakgebied’ is inmiddels doorgevoerd als aanbeveling in [[UWLR]] 2.2.1 m.b.t. Methodegebonden toetsen in het [[PO]].
In [[UWLR]] is ‘afname’ altijd één datum/tijdstip. Hier vindt : (tussen)resultaatbundeling plaats per les / doel / vakgebied. Een les kan meerdere ‘afnamemomenten’ bestrijken, en bijvoorbeeld niet op 1 dag / binnen 1 uur afgerond zijn.
De groepssleutel die in [[UWLR]] wordt gebruikt is betekenisloos. Hier wordt een persistente Groeps-id (GroepsLasKey) geïntroduceerd.
Er wordt een aantal uitgangspunten benoemd (p.4), waarvan wordt aangenomen dat daar, in ieder geval in het [[PO]], grotendeels aan wordt voldaan. In specifieke situaties, wanneer een leerling bijvoorbeeld door adaptief te werken met meerdere lessen tegelijkertijd bezig kan zijn, verschuift het concept ‘Les’ echter van klokbegrip naar inhoudelijk begrip, en ligt er een sterker verband met leerdoelen.
Registreer de betekenis van nieuwe gegevens
Eenduidige definitie van begrippen als ‘les’, ‘vakgebied’, ‘tussenresultaat’ en ‘voortgang’ ontbreken. +
Er wordt nu uitgegaan van identificatie mede op basis van [[BRIN]]. Van [[BRIN]] is bekend dat dit op termijn wordt vervangen door [[RIO]]. De voordelen die Basispoort-id oplevert t.a.v. persistentie en granulariteit komen overeen met de beoogde voordelen van [[RIO]].
Gebruik [[onderwijsidentiteit]] waar nodig; gebruik pseudoniem waar mogelijk
Impliceert dat zo veel mogelijk gebruik gemaakt wordt van pseudoniem. +
Veiligheid van REST-aanroepen verdient aandacht. Het gebruik van HTTP in plaats van HTTPS past sowieso niet bij de te hanteren niveaus van integriteit en vertrouwelijkheid.
De specificatie omvat uitwisseling van oefenresultaten t.b.v. een generieke methodemonitor. Vanuit het ontwerpkader [[Duidelijke eisen en verwachtingen]] dient helder te zijn welke IBP-afspraken op basis van de beoogde functionaliteit gemaakt moeten worden (zie ook onderdeel Toepassingsgebied). +
De uitwisseling op basis van deze specificatie valt volledig binnen het ketenproces [[Toetsen, examineren en oefenen]]. +
De Koppeling Uitwisseling Oefenresultaten bestrijkt de ketenfuncties [[Onderwijsuitvoering]] (genoemde use cases zijn Voorbereiding van een lesdag en Live de voortgang van digitaal verwerken/oefenen volgen) en [[Toetsing en examinering]] (genoemde use case Vaststellen op welke opdrachten/oefeningen het slechtst gescoord wordt). Daarnaast bestrijkt de specificatie van de uitwisseling de ketenfunctie [[Informatiestandaardisatie]]. +
Het gehanteerde werkingsgebied valt volledig binnen het werkingsgebied van ROSA (i.e., het [[onderwijsdomein]]). Het is onduidelijk waarom de wens oefenresultaten c.q. voortgang te monitoren beperkt zou zijn tot het [[PO]]. +
Er is geen inzicht gegeven rondom de zeggenschappen mbt de gegevens die worden uitgewisseld. +
De inhoud van het hoofdstuk over Governance in het projectplan ([1] p.5) is in lijn met alle ontwerpkaders die onder het ROSA principe ”Governancestructuur passend bij de ketenafspraak“ +
OKE past de afspraak OOAPI toe. Dit is een afspraak in beheer van Edustandaard. Er is een relatie met ”Maak gebruik van de Edustandaard-afspraken” +
Het is onduidelijk hoe het OKE voldoet aan het ROSA-ontwerpkader: ”Gebruik pseudoniem waar mogelijk”. +
Er is een afhankelijkheid met wat de OOAPI v5 met adviezen uit de vorige scan heeft gedaan. Hiervoor verwijzen we naar de ROSA scan m.b.t. de OOAPI v5. +
De OKE afspraak valt binnen het ketendomein: ”Uitvoering van het onderwijs” en raakt de ketenprocessen: ”Examineren” en ”Toetsen”. +
Door de AMIGO aanpak te volgen is compliant met ROSA ontwerpkader: ”Hanteer de stappen uit de AMIGO-aanpak"
Het OKE is compliant met de ROSA ontwerpkaders onder het Principe: “Semantische interoperabiliteit ” +
Er is raakvlak met het ROSA RC: Digitaal toetssysteem
Het vaststellen en vastleggen van een resultaat binnen dezelfde functie als het plannen past niet binnen de beschrijving van het ROSA RC: Planning- en roostersysteem
Aangezien binnen de scope van OKE ook examenresultaten horen is er een relatie met de ketenvoorziening Facet. Hoe deze is uitgewerkt wordt niet duidelijk uit de documentatie. +
OKE bevat gegevenssoorten die mogelijk raakvlak hebben met gegevenssoorten: Toetsdeelnemer, Toetsresultaat, Toetsafname, Examenuitslag, Afnameplanning en Afnameconditie. Voor deze gegevenssoorten wordt uit de documentatie niet duidelijk hoe de zeggenschappen liggen. +
de afspraak heeft relatie met het Toepassingsscenario ” Leermiddelen en Toetsen” Het lijkt erop alsof de OKE functionaliteiten van een vergelijkbaar abstractieniveau zijn als de ROSA ketenprocesstappen binnen dit toepassingscenario. Afwijkend van de ROSA is dat de analyse van de toetsafname niet als een apparte functionaliteit wordt genoemd. +
Er zijn geen relaties gevonden met het ontwerpgebied waardegedreven belangenafweging. +
Volgens het pitch document is het werkingsgebied het HO, maar het wordt niet duidelijk uit de beschikbare documentatie of ambities om het werkingsgebied van de OOAPI te vergroten nog van kracht zijn. +
De OOAPI is een API specificatie voor gegevensuitwisseling tussen verschillende systemen. De API wordt gerealiseerd door een (pilot) OOAPI Gateway die door SURF wordt gerealiseerd en die OOAPI-verzoeken gericht aan meerdere instellingen kan bundelen.
Er is een relatie tussen informatie die wordt ontsloten door middel van de OOAPI, informatie die vastgelegd wordt in de RIO registratie, en informatie die in de HOVI database is opgenomen. De inhoudelijke en technische samenhang tussen deze systemen is uit de documentatie onbekend. +
Uit de beschikbare documentatie wordt niet duidelijk hoe relaties worden bewaakt met andere overlappende afspraken zoals RIO en de HOVI.
Er wordt wel gesproken over afstemming met RIO voor HO in het artikel over de stimuleringsregeling ([https://www.surf.nl/stimuleringsregeling-uitwisselen-van-onderwijsaanbod-data-weer-gestart Zie bron]; onder kopje “Open Onderwijs API – de standaard voor het open delen van onderwijsdata”). +
De semantiek van begrippen binnen de OOAPI specificatie is niet traceerbaar naar andere begrippenkaders binnen de onderwijsketen.
Het is onbepaald in hoeverre de OOAPI in lijn is met het Edukoppeling REST profiel. +
Zoals te lezen onder het kopje “SAMEN WERKEN AAN STANDAARDISATIE” op de OOAPI website, kan gebruik worden gemaakt van SURFConext voor authenticatie. De richtlijnen voor autorisatie bij de OOAPI zijn niet terug te vinden in beschikbare documentatie en daarom onbepaald. +
Het IBP ROSA ontwerpkader over duidelijke eisen en verwachtingen richting de keten is onvoldoende gerealiseerd.
In de beschikbare documentatie worden geen duidelijke eisen en verwachtingen benoemd met betrekking tot beveiliging en vertrouwelijkheid van gegevens die met de OOAPI worden uitgewisseld. +
De OOAPI specificatie maakt niet expliciet welke ketenprocessen door de OOAPI bediend moeten kunnen worden, in het bijzonder of er alleen sprake is van ontsluiting-/inzageprocessen (richting apps) of dat het gebruik van de OOAPI ook beoogd wordt voor administratieve processen (e.g., uitwisseling van gegevens tussen toetssysteem en SIS, etc.) +
Van inhoud van de verschillende onderdelen van de OOAPI v4. Specificatie valt af te leiden dat informatie gedeeld kan worden met raakvlak met de volgende ketenfuncties:
* Onderwijsuitvoering;
* Personeel en organisatie;
* Onderwijshuisvesting;
* Toetsen, examinering en oefening;
De OOAPI Specificatie bevat ook een datamodel en heeft daarom raakvlak met:
* Informatieverwerking;
* Informatiestandaardisatie;
De scope van de OOAPI omvat ook persoonsgegevens en daarom zijn ook verwachtingen rondom Identificatie en toegang en Informatiebeveiliging en privacy relevant. +
De OOAPI v4 heeft alleen betrekking op het Hoger Onderwijs werkingsgebied van de ROSA volgens de pitch, maar uit de vorige ROSA scan van 2018 blijkt dat dit werkingsgebied later mogelijk verbreed kan worden. Er wordt in de documentatie gesproken over onderwijsgegevens in het algemeen. (zie bijvoorbeeld: https://www.surf.nl/stimuleringsregeling-uitwisselen-van-onderwijsaanbod-data-weer-gestart)
Het is onbekend of het steeds de ambitie is het werkingsgebied uit te breiden. +
De zeggenschappen die partijen hebben ten aanzien van gegevens die via de OOAPI worden ontsloten, zijn niet uitgewerkt. +
In het bijzonder waar het Bewaak relaties met andere afspraken c.q. de relatie met RIO betreft is een duidelijke uitwerking onderdeel van de specificatie. +
De implementatie van maatregelen op gebied van toegang / IAA is de verantwoordelijkheid van de instelling / ketensamenwerking die OOAPI toepast in een concreet scenario. +
In het (toegevoegde) onderdeel IBP in de OOAPI architectuurdocumentatie is een algemene BIV-classificatie opgenomen, onleend aan de HORA, en een duiding van de verantwoordelijkheid van instellingen om de BIV-classificatie bij toepassing van OOAPI zelf vast te stellen. +
De OOAPI raakt de volgende ketendomeinen en -processen in ROSA:
'''Organisatie van het onderwijs'''
* Publiceren onderwijsinrichting
I.h.b. in het kader van onderwijsaanbod.
'''Deelname aan het onderwijs'''
* Aanmelden
* Inschrijven
Ihb in het kader van roosterinformatie
'''Uitvoering van het onderwijs'''
* Toetsen
* Examineren
* Monitoren voortgang
I.h.b. in het kader van resultaten +
Er is gekozen om aan te sluiten bij Digikoppeling en de NL API strategie. Edukoppeling biedt een onderwijsspecifieke toepassing hiervan.
De OOAPI-modellen wijken af van de ROSA gegevensmodellen. +
De scan richt zich op de OAS specificatie als algemeen toepasbare specificatie die voor verschillende scenario’s gehanteerd kan worden. Het gebruik van deze specificatie in concrete uitwisselscenario’s zoals “SURFeduhub als voorziening voor aansluiting op RIO” valt buiten scope van deze scan. +
OOAPI richt zich niet op een specifiek scenario van ketensamenwerking, maar is bedoeld als een algemeen toepasbare specificatie die voor verschillende scenario’s gehanteerd kan worden. +
het werkingsgebied (ho + mbo) valt binnen de reikwijdte van ROSA c.q. het werkingsgebied onderwijs. +
Het inrichtende principe “De informatievoorziening overschrijdt organisatiegrenzen.” en onderbouwing vanuit ketendoelen hebben raakvlak met ROSA AP: [[Id-72b6fd75-30af-471e-870e-61f115023421|Een gezamenlijke basisinfrastructuur]].
<br>
De KA(1) richtende principes “5 . Een gegeven wordt enkelvoudig beheerd in een daartoe aangewezen omgeving” en “7. Gegevens worden meervoudig gebruikt in alle omgevingen” hebben een relatie met ROSA AP:
[[Id-5f0d221a-6573-487d-b728-65ea1c0fccbd|Eenmalige registratie meervoudig gebruik]]. +
Het KA(1) Bestuurlijke principe “De deelnemers zijn op de hoogte van ieders belangen en respecteren elkaar daar in. Ze delen kennis en voeren de dialoog over verschillen in inzicht .“ heeft relatie met ROSA ontwerpkader: [[Id-3e1c60f7ddc94138b34893bb740db5c5|Alle belangen in kaart]]
<br>
Het nog ontbreken van een scherpe doelstelling van het onderwijsgegevensplatform zelf, in combinatie met het ontbreken van een beschrijving van beoogde deelnemers, maakt het lastig om belanghebbenden bij het onderwijsgegevensplatform te betrekken. Om deze reden voldoet het onderwijsgegevensplatform niet aan het ROSA ontwerpkader: [[Id-71feaaeab2f649c29a5e437a35eff6c2|Betrokken belanghebbenden]].
<br>
Aangezien de beschrijving van de relatie met andere Edustandaard afspraken ontbreekt, is het onduidelijk hoe de relatie is met ROSA ontwerpkader: [[Id-92b8a7216c244914b658bdb8704be371|Bewaak relaties met andere afspraken]] +
Er is een relatie met ROSA ontwerpkader [[Id-9573b8ef-992a-43ad-8b05-44444d37666e|Registreer de betekenis van nieuwe gegevens]]
De relatie met belangrijke beveiligingsstandaarden als Edukoppeling wordt niet expliciet geduid in de brondocumentatie. Daarom is het onduidelijk of het onderwijsgegevensplatform in lijn is met ROSA ontwerpkader: [[Id-fd10bf7a-e960-4484-8e19-bd8b86e7d911|Gebruik Edukoppeling voor vertrouwelijke gegevensuitwisseling]] +
Aangezien niet duidelijk is hoe federatieve authenticatie wordt ingevuld, is het onduidelijk of wordt voortgebouwd op bestaande federaties binnen het onderwijs. Dit heeft een relatie met ROSA ontwerpkader: [[Id-18d1384e-e207-4e93-9bf1-24e4c967c3b5|Voortbouwen op bestaande federaties]].
<br>
Op basis van subprocessen rondom beheer in de KA (p.11) kan worden opgemaakt dat er een relatie is met ROSA ontwerpkader: [[Id-f1fa49e1-4376-46f6-9fe7-570aa2e8ce65|Gebruik pseudoniem waar mogelijk]]. +
KA (1) inrichtend principe “6 . Gegevens zijn beveiligd op basis van hun risicoclassificatie” en KA verrichtend principe ”6 . Heldere eisen t.a.v. gegevenskwaliteit .” hebben een relatie met ROSA ontwerpkader: [[Id-f4e449df-6504-462a-a23f-d7c6b29dcd2a|Duidelijke eisen en verwachtingen]].
<br>
De beperkte mogelijkheid voor onderzoekers om onderzoeksgegevens te kopiëren wordt invulling gegeven aan ROSA ontwerpkader: [[Id-4ca3ac6b-ea99-43c8-b868-668bbe3c5bb8|Voorkom onrechtmatige toegang of verspreiding]] +
Op basis van Plateau 5 uit de KA (p.23) kan worden opgemaakt dat in ieder geval het ketenproces [[Id-b66a0fb3-7a64-4135-8416-57b71b5202a4|Doorstroom monitoren]] wordt geraakt. Aangezien volgens de KA ook meer platformen kunnen worden ingericht, is het onbepaald welke ketenprocessen verder geraakt zouden kunnen worden. +
Op basis van de scan bevinding dat het ketenproces Doorstroom monitoren in ieder geval wordt geraakt, is het Onderwijsgegevensplatform waarschijnlijk een verbreding van het Referentiecomponent [[Id-a311b984-81db-440c-a7b7-0a8c213597bb|Datawarehouse sectorregisters]]. Aangezien de scope van de ketenprocessen die worden geraakt, niet kan worden vastgesteld, kan ook de scope van de verbreding van het Referentiecomponent niet worden bepaald. +
Uit de gescande documenten wordt het toepassingsgebied van het onderwijsgegevensplatform niet duidelijk. De verwijzing naar de WRO doet wel vermoeden dat het toepassingsgebied [https://rosa.wikixl.nl/index.php/Id-a14b574c-baf0-4100-a143-ae4b82f96ea5 “Instroom, doorstroom en uitstroom”] betreft voor de aanlever kant van gegevens, maar deze relatie is niet expliciet geduid in de brondocumenten.
<br>
Een relatie met [[Id-8a97533b-5d13-4754-8aed-4c0eeb110bfa|“Visievorming en governance”]] lijkt wel meer expliciet naar voren te komen uit de brondocumentatie voor de afnemer kant van het onderwijsgegevensplatform. +
Op basis van de gescande brondocumentatie kan het werkingsgebied niet met zekerheid worden vastgesteld. Op basis van de usecases (4) lijkt het vooral alsof DUO direct met het onderwijsgegevensplatform te maken krijgt, terwijl in figuur 1 van de KA (1) het beeld schetst dat het hele onderwijslandschap direct iets met het platform gaat doen. +
Aangezien basisgegevens niet expliciet worden benoemd als de scope van het Onderwijsgegevensplatform, kunnen ook de Zeggenschappen niet verder uitgewerkt worden. +
Voor ketenpartijen is het van belang te weten (a) aan welke (technische) vereisten zij moeten voldoen voor het kunnen ontvangen van deze terugmeldingen en (b) bij welke typen gegevensuitwisselingen welke typen koppelingen kunnen worden gebruikt (zie ook het onderdeel Gegevensuitwisseling in de keten) +
Het governancelandscap is complex; voor elk deel is een logische partij benoemd, maar de verschillende delen kennen sterke afhankelijkheden. Dit stelt hoge eisen t.a.v. (de afstemming van) de verschillende change management processen (change management proces binnen Edustandaard voor wat betreft wijzigingen op het informatiemodel / een change management proces binnen DUO voor wat betreft wijzigingen op het register zelf inclusief alle koppelingen / veranderingen op gebied van wetgeving en veranderingen binnen de instellingen en opleidingen die impact hebben op het informatiemodel). Om ongewenste, ‘sterke’ wijzigingsafhankelijkheden te voorkomen, dienen het model en de implementaties ervan (in de RIO-registratie en/of administratiesystemen en afnemers) onafhankelijk van elkaar te kunnen ontwikkelen.
De verantwoordelijkheid voor het bewaken en beheren van de consistentie tussen juridische werkelijkheid en onderwijskundige werkelijkheid (zowel modelmatig als qua invulling (data)) is niet expliciet belegd. +
Doordat vanuit RIO ook de onderwijskundige werkelijkheid kan worden weergegeven, is de verwachting dat het gebruik van instellingsgegevens door ketenorganisaties eenvoudiger wordt en beter passend op diverse ketenprocessen. Hiervoor is de ontsluiting van de onderwijskundige werkelijkheid randvoorwaardelijk. Dit is niet in scope van dit project maar wordt in het programma wel gerealiseerd.
Er is een mogelijk spanningsveld tussen ketenbeheer v.h .informatiemodel en inspelen op beleidswijzigingen door registratiehouder. Zie ook het onderdeel ‘beheer en doorontwikkeling’. +
De PSA is op dit vlak vooral intern gericht. +
Bij ‘beschikbaarstellen gegevens’ hoort ook het beschikbaar stellen van de gegevens omtrent de onderwijskundige werkelijkheid. Er moet nog meer duidelijkheid komen over op welke wijze(n) dit zal gaan gebeuren (LOD, M2M, etc.) en welke eisen dit stelt aan afnemende partijen (zeker als dit op andere manieren gebeurt dan het aanleveren). Voor gegevensleveringen is die duidelijkheid er al wel, maar of systemen die gegevens aan RIO aanleveren via dezelfde soort koppeling ook die gegevens weer kunnen ontvangen is nog onbekend.
In de vorige RIO-scan werd t.a.v. de verbinding met KOI geconstateerd dat de indruk bestond dat nog niet alle RIO-begrippen tot het KOI herleidbaar waren, en dat het verplaatsen van KOI-begrippen naar het RIO-model ook nog niet volledig was uitgevoerd. Het is uit de huidige scan niet duidelijk geworden of en hoe de aanbevelingen daaromtrent zijn opgevolgd.
In de fasering van de Linked Data-omgeving wordt enerzijds gesteld dat die in de pilotfase data bevat die “volledig, actueel en correct” is en anderzijds dat “de omgeving incrementeel groeit en bij aanvang nog niet alle data beschikbaar zal zijn”. Dat lijkt niet met elkaar te rijmen. +
ROSA richt zich primair op de identiteit van personen. +
Er is vooralsnog geen sprake van vertrouwelijkheid.
Een belangrijke, nog onbeantwoorde vraag is: hoe wordt integriteit (en beschikbaarheid) geregeld. Ook ihkv afhankelijkheid vanuit andere ketenpartijen en -voorzieningen die gebruik maken van informatie uit RIO, zoals het Onderwijsserviceregister (zie ook die scan). Integriteitseis is ‘hoog’ als RIO-gegevens als authentieke instellingsgegevens in de keten gelden.
Vertrouwelijkheid speelt mogelijk een rol bij bereikbaarheidsgegevens (persoonsgegevens). Aandacht nodig voor:
* maken van onderscheid tussen vertrouwelijke gegevens en niet-vertrouwelijke gegevens,
* borgen vertrouwelijkheid
* hoe past dit bij het uitgangspunt ‘open (register)data’?
Het is onduidelijk welke andere kwaliteitsnormen in de pilotfase LOD gelden t.o.v. de eindfase, en met name welke kwaliteitsnormen in pilot- en eindfase gelden op gebied van BIV. +
de ambitie is dat RIO toegepast kan worden binnen alle ketenprocessen waarin instellings- of opleidingsinformatie wordt gebruikt. De lijst met genoemde ketenprocessen is niet limitatief. +
Het RIO toepassingsgebied valt binnen de ketenfuncties Informatiestandaardisatie en Informatieverwerking. RIO ondersteunt processen binnen diverse andere ketenfuncties, zoals Bekostiging, Kwaliteitsbewaking en toezicht, Erkenning en accreditering. +
Het werkingsgebied ‘onderwijsdomein’ valt samen met het werkingsgebied van ROSA. +
De voor RIO gehanteerde zeggenschappen komen overeen met de in ROSA onderkende zeggenschappen.
Inhoudelijk zal, voordat het Bevoegd Gezag als gegevensverantwoordelijke gegevens aan RIO kan aanleveren, er een identiteit voor het Bevoegd Gezag uitgegeven en geregistreerd moeten zijn. Dit is binnen de projectgroep wel onderkend maar nog niet goed beschreven. +
Hoewel niet expliciet benoemd, is de relatie met de ROSA-principes “Een gezamenlijke basisinfrastructuur” en “Eenheid in verscheidenheid” af te leiden uit de PSA .
RIO-LOD ondersteunt eenmalige registratie, meervoudig gebruik van instellings- en opleidingsaanbodgegevens.
“Compliancy” met NORA en ROSA wordt genoemd als een “business driver” in §2.2 van de PSA. Dit sluit aan bij de ROSA basisprincipes: “Aansluiten bij NORA” en “Digitaal doen we het zo”.
DUO zorgt voor aansluiting op Basisregistraties (PSA §3.1.1) +
Uitgangspunt voor het ROSA ontwerpgebied governance is dat alle belangen worden afgewogen; daarvoor moeten alle belangen en belanghebbenden in kaart zijn gebracht. +
Ontsluiting van RIO gegevens via Linked Open Data geeft invulling aan het ROSA ontwerpkader “Openbare registergegevens worden ontsloten als Linked Open Data”. Voor één use case is een aparte webservice rechtstreeks op RIO ingericht buiten LOD om.
De LOD-URIs kennen een eigen levenscyclus. Afnemers moeten daarop voorbereid zijn (ihb wanneer URIs vervallen).
Semantiek uit RIO-modellen heeft raakvlakken met semantiek in andere uitwisselingen. Linked data kan een manier zijn om die semantiek ook over uitwisselingen heen traceerbaar te maken. Hier ligt een relatie met bijvoorbeeld AMIGO (‘virtuele modellenrepository’). +
Het wijzigen van RIO data is niet in scope van deze scan, aangezien het hier alleen gaat over de ontsluiting van RIO-LOD. +
Privacygevoelige informatie wordt buiten Scope verklaard (PSA §2.3) voor RIO LOD.
Er wordt aangegeven dat data van goede kwaliteit moet zijn. (PSA §2.2) Hiervoor is ROSA ontwerpkader “Voorkom aantasting van integriteit” belangrijk, maar er wordt niet direct naar gerefereerd.
Een eis voor de LOD API is een hoge standaard beschikbaarheid, maar deze wordt nog niet gehaald. Wat een hoge beschikbaarheid inhoudt is nog niet genoeg omschreven. +
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.
Het project wordt vooral gepositioneerd als technologische verandering, effecten op (interne) processen van de afnemers van de gegevens worden buiten beschouwing gelaten. +
Zeggenschap over gegevens ligt bij onderwijsinstellingen zelf (PSA §2.2). Dit ligt aan de kant van het RIO-register, niet bij RIO-LOD,
RIO LOD heeft verder betrekking op de zeggenschappen “Beschikbaar stellen” en “Inzien”. DUO stelt RIO data beschikbaar via Linked data endpoints aan iedere afnemer die gebruik wil maken van deze data. +
Op alle plaatsen waar nu nog (informatie uit) BRIN wordt gebruikt, zal RIO gebruikt moeten gaan worden. +
RIO-LOD heeft direct betrekking op de ketenfuncties Informatieverwerking en Informatiestandaardisatie, en gedeeltelijk op Identificatie en toegang en Informatiebeveiliging en privacy
Vanuit afnemersperspectief zijn alle overige ketenfuncties ook relevant, immers op alle plaatsen waar instellings- en opleidingsinformatie gebruikt wordt is RIO in beeld als de bron van die data. +
Het werkingsgebied van RIO-LOD omvat (net als het RIO register) het gehele onderwijsdomein. +
in lijn met Eenmalige registratie, meervoudig gebruik en Koppelen – niet kantelen. De event driven stijl is een andere benadering van gegevensuitwisseling. +
''Bewaak relaties met andere afspraken''
De overwegingen voor het herontwerp zijn samengevat in een overzicht van tien verbeteringen die het SEM ecosysteem wil bewerkstelligen (https://github.com/stichtingsem/ecosystem/blob/master/documentation/principles.md)
Werkgroep D&T is als werkgroep niet formeel betrokken bij (de formulering van) de wens ‘tot vervanging van de huidige leermiddelenketen’.
Er is op basis van de AMIGO-aanpak in verschillende verbanden gewerkt aan specificatie van uitwisseling van leerresultaten. SEM heeft deze vertaald in een event-based oplossing. De wens is aan beide zijden om deze in sync te houden.
Deelnemende partijen (Aanmeldformulier 4.1) omvatten slechts een deel van de belanghebbenden, nl. private partijen (uitgeverijen, leveranciers) vnl. in het vo. De sectoren po en mbo ontbreken, evenals de betrokkenheid van het onderwijs. Een dergelijke herstructurering van de architectuur van de leermiddelenketen vraagt om een brede betrokkenheid en belangenafweging (cf. ROSA-ontwerpgebied governance, i.h.b. Alle belangen in kaart en Betrokken belanghebbenden) +
Er wordt geen gebruik gemaakt van Edukoppeling. +
Er wordt een autorisatie- / mandateringsstructuur ingericht die wat betreft doelstelling lijkt op het Onderwijsserviceregister, maar functioneel en technisch anders is gerealiseerd. Uitgangspunt is een decentrale organisatie, waarbij continuïteit van de dienstverening als waarde een hoge prioriteit heeft (geen SPOF door verplicht gebruik centrale voorziening).
Een gebruiker met de juiste rechten moet in beide systemen de consent registreren. Dat betekent dat die persoon in beide systemen deze rechten moet hebben, of dat er 2 personen met de juiste rechten in beide systemen betrokken zijn. De handelingsbevoegdheid namens de school wordt dus vastgelegd aan de hand van rollen en autorisaties in de deelnemende systemen.
Er wordt waar mogelijk gebruik gemaakt van het ECKiD, met een fallback naar een userId (nledupersonrealId of nledupersonprofileId obv Entree). +
Er wordt weliswaar gesteld dat een UUID alleen gebruikt mag worden binnen de context van een enkele resource, maar er lijkt verder niet afgedwongen te worden dat UUIDs niet over resources / calls heen gebruikt kunnen worden. Daarmee ontstaat mogelijk een separate persoonsidentifier naast de eigenlijke identifier (eckID, userID) die in de requests gebruikt worden. +
Hoe verhoudt (implementatie van) SEM Ecosysteem zich tot (bestaande) implementaties van de afspraak ECK D&T? +
Stichting SEM is nauw betrokken geweest bij de uitwerking en validatie van het ketenprocesmodel. Het SEM Ecosysteem geeft als ketensamenwerking een specifieke invulling aan dit proces. +
Het werken vanuit (systeem)‘rollen’ (SIS, LMS, MP, LA) past goed bij de wijze waarop ROSA referentiecomponenten onderscheidt. +
valt binnen de ketendomeinen3 Inhoud van het onderwijs (Leermiddel aanbieden, Leermiddel verwerven, Leermiddel(gebruik) betalen) en Uitvoering van het onderwijs (Leermiddel gebruiken, Monitoren voortgang (zowel op voortgang als op resultaat), Plannen en Roosteren (ihkv klaarzetten van leermiddelen) en – via de relatie Leermiddel gebruiken <-> Toetsen ook Toetsen en Examineren). +
Het (beoogde) werkingsgebied is po, vo, en bve (incl. vavo).
De huidige uitwerking is gevalideerd in een aantal PoCs in het vo, en is nog niet gereed voor toepassing in po, mbo. +
De gegevenssoorten waar de afspraak betrekking op heeft zijn onderdeel van de procesuitwerking die in het kader van revisie ROSA is uitgewerkt. +
Het toepassen van de AMIGO methodiek zorgt ervoor dat de afspraak makkelijker hergebruikt kan worden in de onderwijsketen, daarom heeft de afspraak wel raakvlak met het ROSA ontwerpkader Eenheid in verscheidenheid. +
Aangezien de belanghebbende in kaart zijn en worden betrokken bij de afspraak is er overlap met het ROSA ontwerpkader Betrokken belanghebbenden
In relatie met ontwerpkader: Alle belangen in kaart; Het is duidelijk wie de belanghebbende zijn, waarschijnlijk zijn tijdens de werkgroepen alle belangen ook duidelijk geworden, maar dit staat niet ergens in de brondocumentatie samengevat. +
Het gebruik van de AMIGO methode in de technische specificatie [5] geeft invulling aan het ontwerpkader: Semantiek in berichtuitwisseling is traceerbaar
De samenhang die word geschetst (p.13 [5]) met de AMIGO modellenmatrix heeft raakvlak met ROSA ontwerpkader:
Classificeer alle gegevens- en domeinobjecten met het Kernmodel Onderwijsinformatie
Het gebruik van Edukoppeling heeft raakvlak met ROSA ontwerpkader:
Gebruik Edukoppeling voor vertrouwelijke gegevensuitwisseling +
Aangezien er naast het Eck-iD ook backup keys worden aangewezen is er sprake van een kwaliteitssysteem, en daarom is er raakvlak met het ROSA ontwerpkader: Kwaliteitsborging van identiteiten
Het Eck-ID wordt gebruikt. Het ROSA ontwerpkader: Gebruik pseudoniem waar mogelijk,
Het gebruik van Oauth 2.0 kan worden meegenomen in de Edukoppeling transactie standaard. +
Voor de onderliggende infrastructuur worden sectorbrede frameworks en baselines gebruikt, dus is er raakvlak met ontwerpkader: Sectorbrede frameworks en baselines
Aangezien het certificeringsschema is ingevuld is er overlap met het ROSA ontwerpkader: Duidelijke eisen en verwachtingen +
Er is raakvlak met het ROSA ketenproces Toetsen. +
De afspraak is gerelateerd aan de referentiecomponenten: Digitaal toetssysteem, Dashboard leerresultaten, Leerlingadministratiesysteem, Leerlingvolgsysteem. Het heeft ook relatie met een Leermanagement systeem (LMS), maar deze zit niet in de ROSA.
Gedurende het project ontdekte het project dat de LV OSR niet bruikbaar was voor hun use-case. +
Het gaat hier om de uitwisseling van toetsresultaten binnen het ketendomein Uitvoering van het onderwijs. +
De afspraak heeft betrekking op het werkingsgebied VO. +
Er is raakvlak met de ROSA gegevenssoort Toetsresultaat. Het lijkt erop alsof de zeggenschappen allemaal bij de medewerker liggen, maar het zou per zeggenschap nog in kaart kunnen worden gebracht. +
Onbepaald met [[Id-3e1c60f7ddc94138b34893bb740db5c5|Alle belangen in kaart]]: De betrokkenheid van verschillende SURF-leden en partners suggereert dat er inspanningen zijn gedaan om verschillende belangen in kaart te brengen, hoewel dit wellicht verder uitgewerkt kan worden voor een volledig overzicht.
Onbepaald met [[Id-92b8a7216c244914b658bdb8704be371|Bewaak relaties met andere afspraken]]: Het is onduidelijk hoe de SURF Security Baseline zich verhoudt tot het toetsingskader Certificeringsschema informatiebeveiliging en privacy ROSA en de Uniforme Beveiligingsvoorschriften en of er afstemming met deze afspraken is georganiseerd. Ook is onduidelijk hoe deze afhankelijkheden traceerbaar worden gemaakt.
Compliant met [[Id-0c6e3e22affd4f5cb987c01f57cc09c0|Transparantie over deelname]]: Het is duidelijk wie aan ontwikkeling van de afspraak hebben deelgenomen. +
Dit ontwerpgebied is nog niet uitgewerkt in de ROSA. +
Compliant met [[Id-524036beed23475da8e599258b2bb27f|Een persoon heeft minstens één digitale identiteit]] en [[Id-3d8aadfa96bd4ec4aa8777174232eb29|Sturing op gebruik van digitale identiteit]]: implementatie van maatregel SB.9.013 zorgt ervoor dat digitale identiteiten traceerbaar en controleerbaar blijven, in overeenstemming met de ROSA-ontwerpkaders over dit onderwerp.
Compliant met [[Id-607f0e5b8e864af3a99d7d71066689ac|Maak uitvoering transparant]]:
Door het loggen en documenteren van toegangs- en autorisatieverzoeken, evenals wijzigingen in rollen en contractuele relaties, wordt de transparantie voor de betrokken personen verhoogd.
Compliant met [[Id-05e0d5baa26e4051b327d7891f644c15|Maak in ontwerp (van vertrouwensraamwerk) transparant hoe privacy is geborgd]]: De maatregel SB.9.016 voldoet aan het ROSA ontwerpkader door expliciet de toegangsrechten en rollen binnen de organisatie te definiëren, wat bijdraagt aan duidelijke privacyborging en informatiebeveiliging in het ontwerp. +
Explain met [[Id-6d06dfb2f1fb4c08a59dbefbdefa2d57|Hanteer Certificeringsschema ROSA]] en [[Id-f34f222390e24b748ff7b90de25b1d16|Gebruik UBV]]:
De SURF Security Baseline hanteert een andere aanpak in classificatie, categorieën, en maatregelen dan het Certificeringsschema ROSA, wat leidt tot verschillen in de uitvoering van informatiebeveiligingsbeleid. +
Er is geen overlap tussen ontwerpkaders uit de ROSA en inhoud van Security Baseline maatregelen. +
Op basis van het gestelde in het aanmeldformulier van de SURF Security Baseline, kan gesteld worden dat de SURF Security Baseline raakvlakken heeft met alle ketendomeinen en -processen binnen ROSA. +
Dit ontwerpgebied is nog niet uitgewerkt in de ROSA. +
Al lijken er geen specifieke ketenvoorzieninngen en RC’s betrokken te zijn bij implementatie van deze afspraak, gezien de definitie van 'assets' in de maatregelen, heeft deze een relatie met het referentiecomponent: [[Id-ed153bb97a524ff3a4f53ca7f6199012|Gegevensverwerkend Systeem]]
Aan dit referentiecomponent is het ROSA ontwerpkader gekoppeld: [[Id-6d06dfb2f1fb4c08a59dbefbdefa2d57|Hanteer Certificeringsschema ROSA]]. Echter, de mate waarin de implementatie van de SURF Security Baseline ook de vereisten van het ROSA certificeringsschema invult, blijft onbepaald. +
Er is een relatie met het ROSA Ondersteuningsscenario [[Id-616c06e18c4049a195e843424702803a|Inrichten IBP-maatregelen]].
De SURF Security Baseline, met zijn focus op informatiebeveiliging binnen onderwijsinstellingen, sluit aan bij het ROSA-ondersteuningsscenario voor het inrichten van IBP-maatregelen. Deze afspraak met maatregelen ondersteunt de ketengerichte benadering van ROSA voor informatiebeveiliging en privacy, waarbij onderwijsinstellingen worden aangemoedigd hun interne beveiligingsmaatregelen af te stemmen met de keten. +
De SURF Security baseline is van toepassing op de werkingsgebieden bve en ho. +
Een beperkt aantal standaarden en uitwisseldiensten wordt met name genoemd, maar heeft dit niet ook impact op federaties, Entree /SURFConnext en vele online diensten binnen het onderwijs? +
De doelstelling van UBV draagt bij aan het ROSA-principe “Een gezamenlijke basisinfrastructuur”.
Door ketenbreed gelijke technische afspraken te hanteren, wordt interoperabiliteit in de keten ondersteund. +
Belanghebbenden zijn in beeld, maar nog niet allemaal aangehaakt; governancestructuur is nog in opbouw. +
de Uniforme Beveiligingsvoorschriften omvatten gezamenlijke afspraken op het gebied van Communicatiebeveiliging uit de Code voor Informatiebeveilging (ISO27001/27002) +
Op dit moment is alleen een profiel voor Edukoppeling uitgewerkt. Het uitwerken van een profiel incl.vaststelling in twee werkgroepen als voorwaarde om aan te sluiten bij de UBV betekent voor andere implementaties dat het niet makkelijk is om snel in te stappen. +
De UBV raken alle referentiecomponenten en applicaties die H2M of M2M gegevens/informatie uitwisselen. +
De UBV hebben betrekking op het Informatiebeveiliging en Privacy toepassingsgebied van de ROSA. +
bestrijkt het volledige werkingsgebied van de ROSA. +
Het certificeringsschema dekt (bewust) niet alles, maar beperkt zich tot ict-toepassingen. Hoewel gehanteerde BIV-definities en classificaties afwijken van die in het ROSA-katern IBP is de essentie van deze definities en classificaties gelijk. +
Fully conformant - het certificeringsschema is binnen elk ketenproces toe te passen. +
het certificeringsschema bestrijkt alle ict-toepassingen (in ROSA-termen: Voorzieningen) in het onderwijsdomein.
Het certificeringsschema is gericht op ict-toepassingen, en niet op (certificering van) organisaties of processen. +
het werkingsgebied van het Certificeringsschema valt volledig samen met het ROSA werkingsgebied. +
Eigenaarschap van gegevens is zowel juridisch als inhoudelijk lastig te duiden. Een formeel (juridisch) eigenaarschap van gegevens bestaat niet, omdat in formele zin eigenaarschap altijd over stoffelijke zaken gaat, en gegevens dat niet zijn. Bovendien zullen vanuit verschillende rollen verschillende partijen 'iets' met gegevens moeten doen - een absoluut eigenaarschap is dus, los van de juridische context, uitgesloten. In ROSA wordt daarom uitgegaan van zeggenschappen die partijen kunnen hebben over gegevens. +
Er zijn geen soortgelijke voorzieningen en/of bouwstenen benoemd in ROSA. +
Het Lerarenregister geeft invulling aan de principes: eenmalige registratie, meervoudig gebruik en terugdringen van administratieve lasten +
Een mogelijke m2m-koppeling tussen Lerarenregister en Bevoegd Gezag wordt met Edukoppeling gerealiseerd via DUO +
Het Lerarennummer is nog niet ingevoerd +
LR geeft invulling aan IBP principes zoals in ROSA zijn vastgesteld +
Het Lerarenregister bestrijkt (administratieve) processen die niet nader in ROSA zijn beschreven. +
Het Lerarenregister geeft invulling aan verschillende ketenfuncties: het register verzorgt informatieverwerking, informatiestandaardisatie, identificatie en toegang, informatiebeveiliging en privacy ten behoeve van beleid en wetgeving, verantwoording, erkenning en accreditering, en kwaliteitsbewaking en toezicht. +
het werkingsgebied van het Lerarenregister valt volledig binnen het ROSA werkingsgebied. +
Er zijn geen tegenstellingen geconstateerd tussen de beschreven informatieprocessen en de zeggenschappen op gegevens die reeds in ROSA zijn opgenomen. +
Er zijn geen soortgelijke voorzieningen en/of bouwstenen benoemd in ROSA +
Er ontstaan verschillende registraties die gepositioneerd worden als (authentieke) bron voor dezelfde gegevens +
Een mogelijke m2m-koppeling tussen Lerarenregiter en Bevoegd Gezag wordt met Edukoppeling gerealiseerd, “bij voorkeur via DUO” +
Verdere ontwerp- en implementatiekeuzes bepalen de mate waarin toegang tot leraardossiers afdoende kan worden beperkt, en de mate waarin leraren zelf publicatie van onjuiste informatie kunnen voorkomen. +
Het Lerarenregister bestrijkt (administratieve) processen die niet nader in ROSA zijn beschreven. +
Het Lerarenregister geeft invulling aan verschillende ketenfuncties: het register verzorgt informatielevering en -doorlevering ten behoeve van beleid en wetgeving, verantwoording, erkenning en accreditering, en kwaliteitsbewaking en toezicht. +
Het werkingsgebied van het Lerarenregister valt volledig binnen het ROSA werkingsgebied. +
Er zijn geen tegenstellingen geconstateerd tussen de beschreven informatieprocessen en de zeggenschappen op gegevens die reeds in ROSA zijn opgenomen. +
Bij gebrek aan informatie is niet goed te bepalen voor ontsluiting vanuit welke referentiecomponenten de OO API is bedoeld, noch welke referentiecomponenten rechtstreeks bij (de implementatie van) de OO API zijn betrokken. +
De OO API bestrijkt geen bovensectorale samenwerking +
Verdere ontwerp- en implementatiekeuzes bepalen hoe de gegevensuitwisseling afdoende kan worden geborgd +
Verdere ontwerp- en implementatiekeuzes bepalen hoe het gebruik van identiteiten afdoende kan worden geborgd +
Verdere ontwerp- en implementatiekeuzes bepalen de mate waarin toegang tot vertrouwelijke gegevens afdoende kan worden beperkt +
Bij gebrek aan informatie is niet goed te bepalen voor welke processen de OO API wel of niet is bedoeld. +
De OO API geeft invulling aan de volgende ketenfuncties: Onderwijsuitvoering; Personeel en
organisatie; Onderwijshuisvesting; Toetsen, examinering en oefening; Informatieverwerking; Informatiestandaardisatie. +
Het werkingsgebied van de OO API valt volledig in het onderwijsdomein c.q. ROSA +
omdat de zeggenschappen niet zijn uitgewerkt. +
Het minimaliseren van persoonsgegevens is in lijn met IBP-principes uit ROSA. Bestaande systemen kunnen blijven werken op de huidige manier totdat aansluiting op het serviceregister opportuun is of vanuit ketensamenwerking wordt gevraagd. +
In het ontwerp wordt een aantal voorbehouden gemaakt met betrekking tot de mate waarin het serviceregister gerealiseerd kan worden zonder extra administratieve complexiteit. Onvoldoende duidelijk is welke eventuele aanvullende complexiteit intrinsiek door het serviceregister wordt geïntroduceerd, en welke complexiteit het gevolg kan zijn van latere implementatiekeuzes ten aanzien van het gebruik van het serviceregister. +
Het serviceregister geeft invulling aan het ontwerpkader ''Serviceinformatie wordt samenhangend openbaar gemaakt''.
Gegevens in het serviceregister zijn (deels) vertrouwelijk van aard. Voor deze gegevens is het ontwerpkader Gebruik Edukoppeling voor vertrouwelijke gegevensuitwisseling van toepassing. Het eventuele gebruik van REST/JSON voor niet-vertrouwelijke delen van het serviceregister valt buiten de bestaande ontwerpkaders van ROSA (maar is daarmee niet in tegenspraak). +
Het ontwerp van het serviceregister doet nog geen uitspraken over het te gebruiken IAA-middel +
De kwaliteitseisen die voor het serviceregister gelden dienen verder te worden geëxpliciteerd. +
Het onderwijsserviceregister is een administratieve, technische component die in principe voor alle soortern processen gebruikt kan worden +
het serviceregister past binnen de ketenfuncties Informatieverwerking en Identificatie en toegang +
het werkingsgebied valt samen met het ROSA werkingsgebied ‘onderwijsdomein’ +
de zeggenschappen zijn indirect (via functionele wensen) uitgewerkt en bovendien niet in relatie gebracht tot de beoogde faseringen. +
De relatie tussen [[BRIN]] en de nieuwe RIO-registratie is nog niet beschreven. De verwachte impact op bestaande processen is daarmee ook nog niet bepaald.
Want er zijn nu al allerlei partijen (ook partijen die voorzieningen beheren, zoals [[Basispoort]]) die BRIN gebruiken als basis voor hun eigen processen of dienstverlening. Wanneer BRIN vervangen wordt door RIO is het de vraag wat die partijen moeten doen.
Basispoort werd al genoemd, maar allerlei [[Leerlingadministratiesysteem|Leerlingadministratiesystemen]] gebruiken ook BRIN als basis voor hun indeling, en ze moeten ook communiceren op basis van BRIN. +
Uit gesprekken met direct betrokkenen blijkt dat het basisprincipe [[Eenmalige registratie meervoudig gebruik]] binnen dit thema een basaal uitgangspunt is van het programma Doorontwikkelen BRON en daarmee van het RIO-project.
Het ROSA-doel [[Inspelen op beleidswijzigingen]], en de wijze waarop het RIO-Informatiemodel daaraan bij zou kunnen dragen, wordt in de aangeleverde documentatie niet expliciet benoemd. Toch lijkt dit, gegeven de aard van het uiteindelijke register en het verband met processen met een wettelijke grondslag, binnen het thema [[Bovensectorale samenwerking]] het belangrijkste aspect +
Daar waar RIO en KOI tot elkaar te herleiden zijn, is die herleiding eenduidig. De indruk bestaat echter dat nog niet alle RIO-begrippen tot het KOI herleid zijn. Omgekeerd zijn in april 2015 vanuit [https://www.edustandaard.nl/standaarden/begrippen/begrip/begrippenset-kernmodel-onderwijs-informatie-koi/1.1/ KOI v1.1] begrippen genoemd die naar het RIO-informatiemodel verplaatst dienden te worden. Dit is ook niet volledig gebeurd. Of alle ten tijde van KOI v1.1
voorgestelde relaties (tussen RIO en KOI) ook zijn doorgekomen is niet bepaald.
Het model bevat gegevenstypen waarvan de inhoud (de gegevens zelf) eigendom zijn van enerzijds DUO en anderzijds onderwijsinstellingen. Er loopt nu een POC "RIO publiceren als [[Linked Open Data (LOD)]]". De lopende POC bestrijkt alleen de gegevens van DUO, en hun ontsluiting.
In de POC-groep is ter sprake geweest dat onderwijsinstellingen geheel eigen doelstellingen kunnen hebben voor het beschikbaar stellen van hun (deel van hun RIO) data als LOD, dit op basis
van door hen vastgestelde informatiebehoeften van de partijen waar zij mee te maken hebben, in hun context. DUO is daar slechts een van.
Voorbeelden: andere onderwijsinstellingen, inspectie, leveranciers, uitgevers enz. Deze doelstellingen worden niet in de huidige POC bestreken, maar zullen onderdeel zijn van een volgende, bredere PoC, dat zich zal richten op het verbinden van de juridische en onderwijs
werkelijkheid. +
De scope van het thema IAA (onderwijsvolgers) en RIO (instellingen en onderwijsaanbod) kent geen overlap +
Het huidige model omvat geen persoonsgegevens, waardoor de aspecten Vertrouwelijkheid en Privacybescherming niet aan de orde zijn. Integriteit en beschikbaarheid spelen geen rol op het niveau van het model, maar worden belangrijk wanneer overgegaan wordt tot realisatie van een voorziening en 'vulling' van de gegevenssets.
Mocht de scope van het model verbreed worden tot persoonsgegevens dan zal IBP wel relevant worden, en zal dat tevens impact hebben op bijvoorbeeld publicatie als (linked) open data +
De ambitie is dat RIO werkt voor alle ketenprocessen in het onderwijs. +
Vereist een inhoudelijke analyse en mapping met bestaande standaarden als [[HODEX]], [[UWLR]] enz.
In principe dient elke standaard waar identificatie van instellingen aan de orde is, bekeken te worden. Hetzelfde geldt in feite voor voorzieningen die gebruik maken van een bepaalde indeling van instellingen.
Het RIO informatiemodel is het eerste model waarover op dit niveau afspraken worden gemaakt; andere modellen richten zich op specifieke sectoren of toepassingsgebieden. +
Het werkingsgebied van RIO komt overeen met het meest veelomvattende werkingsgebied ‘Onderwijsdomein’ dat ROSA kent. RIO richt zich niet op werkingsgebieden buiten het onderwijsdomein. +
Er zijn door RIO-implementatiegroep wel zeggenschappen toegekend, maar die lijken af te wijken van de [[Zeggenschappen|ROSA-zeggenschappen]]. Nadere informatie ontbreekt. +
Koppelpunten zijn nog niet bekend in ROSA. +
Centralisering van logica maakt inspelen op veranderende wetgeving eenvoudiger. Aanleverende systemen hoeven niet te worden aangepast; zij blijven alle aanmeldingen aanleveren aan het koppelpunt zonder zich te hoeven bekommeren om de vraag of die gegevens nodig zijn.
Zie ook [[Architectuurscan VA-MBO Gegevensuitwisseling|Gegevensuitwisseling in de keten - Behoeftegerichte en doelgebonden gegevensuitwisseling]] +
Afhankelijk van verdere besluitvorming c.q. explicitering daarvan m.b.t. de positie van vo- en gemeentekoppelpunten, en eventuele impact daarvan op adressering conform Edukoppeling.
Er spelen 2 soorten uitwisselingen:
* Peer-to-peer: correcte aflevering naar volgende schakel (e.g., adressering van mbo-instelling naar mbo-koppelpunt, van mbo-koppelpunt naar vo-koppelpunt, van vo-koppelpunt naar vo-school)
* End-to-end: correcte ontvangst en verwerking door beoogde ontvanger (adressering van mbo-instelling naar vo-instelling)
Edukoppeling stelt: berichtadressering bevat altijd OIN van ‘formele partij van request-, resp.. Antwoordbericht’. (end-to-end).
* Voor het mbo-koppelpunt wordt expliciet gekozen dit als verlengstuk van de mbo-administratie te positioneren. Daardoor kan beargumenteerd worden dat het koppelpunt de ‘formele partij’ voor end-to-end uitwisseling is, m.a.w. dat adressering van en naar het mbo-koppelpunt plaatsvindt.
* Voor de vo- en gemeentekoppelpunten is die positie niet expliciet gekozen.
* Als de vo- en gemeentekoppelpunten niet als verlengstuk van de administratie, maar als transparante routeringsintermediair dient te worden opgevat, is de gehanteerde adressering (met OIN van koppelpunt) niet conform Edukoppeling transactiestandaard.
De ontwerpkeuze om business logica te centraliseren impliceert dat ‘behoeftegerichte en doelgebonden gegevensuitwisseling’ (privacy by design) bij het mbo-koppelpunt wordt ingevuld. Omdat het koppelpunt echter fungeert als verlengstuk van de mbo-administraties, vindt filtering alsnog bij de (verlengde) bron plaats.(compliant)
Zie ook [[Architectuurscan VA-MBO Bovensectoraal|Bovensectorale Samenwerking - Inspelen op beleidswijzigingen]] +
ligt aan verdere uitwerking van nog te stellen eisen. +
Past op ketenproces Aanmelden en Inschrijven; voegt daar een gegevensstroom voor statusovergangen aanmeldingen aan toe.
Past op ketenproces Voorkomen van schooluitval. Huidige uitwerking is gericht op verzuimregistratie, PvE voegt daar monitoring van aanmeldstatus aan toe. +
het PvE past binnen de ketenfuncties Instroom, Doorstroom en Uitstroom, Preventie Schooluitval, Informatieverwerking en Informatiestandaardisatie +
het werkingsgebied valt binnen het ROSA werkingsgebied +
het is onduidelijk welke zeggenschappen en verantwoordelijkheden samenhangen met de extractie van stuurinformatie door het koppelpunt. +
S
De afspraak conformeert zich, waar nodig, aan eisen uit het PvE van DUO voor BRON-aanlevering. +
Deze referentiecomponenten zijn reeds in ROSA bekend. +
(1) Doelbinding voor uitwisseling leerkrachtgegevens is niet beschreven; (2) de relatie tussen Eindtoets-specifieke begrippen en KOI ontbreekt; (3) Er wordt (nog) geen gebruik gemaakt van Edukoppeling; (4) De relatie met (waarden uit) het Gegevenswoordenboek DUO is impliciet. +
Toepassing (en selectie) van IAA-middelen valt buiten de specificatie en wordt aan de Toets- en LAS-leveranciers overgelaten. +
Integriteit (resultaten) en vertrouwelijkheid (privacy) zijn belangrijke aspecten.Er worden echter geen concrete uitspraken gedaan over BIV-eisen, -classificaties en -maatregelen.
De H2M-aanleveringen vinden plaats buiten de scope van het beschreven logistieke proces, maar bevatten wel degelijk diverse (bijzondere) persoonsgegevens (bijv. kenmerken m.b.t. dyslexie die belangrijk zijn voor hoe de toets wordt afgenomen)
Wanneer bestandsoverdracht en/of handmatige aanvulling nodig blijft, blijven de bezwaren ihkv IBP daarvoor bestaan. Bovendien belemmert het de mogelijkheid om volledig M2M uit te wisselen.
De afspraken over beperkte aanlevering en verwerking van alleen leerlinggegevens uit leerjaren 7 (dit is een beperkt aantal) en 8 passen bij het principe van dataminimalisatie. De afspraken lijken nog wel veel ruimte open te laten om toch gegevens uit leerjaren 6 en lager alsmede van leerlingen uit leerjaar 7 die niet aangemerkt zijn om de eindtoets te gaan doen aan te leveren (‘zo veel mogelijk beperken’ / ‘mogen weigeren’). Het is niet duidelijk of en zo ja hoe vaak er meer leerlinggegevens dan strikt noodzakelijk worden aangeleverd. +
Het beschreven proces past binnen uitgewerkte processen rondom Examineren, Toetsen, Oefenen.
Wat wel opvalt: de procesbeschrijvingen hanteren een volledig eigen systematiek, waarbij ook verschillende niveaus door elkaar worden gebruikt. De beschreven stappen zijn niet beschreven vanuit ROSA perspectief. Bovendien is de beschrijving zeer diffuus doordat bedrijfslaag, informatielaag en technische laag heel erg door elkaar lopen in de beschrijving.
Het beschreven ketenproces omvat aanlevering aan DUO / BRON van eindtoetsresultaten. Naast BRON is ook de VO-school afnemer van de resultaten van de eindtoets, ihkv het onderwijskundig rapport. Dit deel van het ketenproces is niet beschreven. In de praktijk gebeurt dit via OSO of rechtstreeks aan een overstap-ondersteunende applicatie. +
De afspraak valt binnen de ketenfuncties ''Toetsing en diplomering'' en ''Informatiestandaardisatie''. +
De afspraak bestrijkt de ROSA werkingsgebieden PO-instellingen en PO-ondersteunende organisaties binnen Sector PO. +
Zeggenschappen en gegevensoorten zijn niet expliciet benoemd. +