144
U

Eigenschap:Scanbevindingen

Uit ROSA Wiki
Ga naar: navigatie, zoeken
KennismodelKennismodel ROSA
TypeTekst
Geldige waarden
Meerdere waarden toegestaanNee
Weergave op invulformulierenTekstvak
Defaultwaarde
Toelichting
Specialisatie van



Deze eigenschap wordt gebruikt door de volgende elementtypen:


Pagina's die de eigenschap "Scanbevindingen" gebruiken

Er zijn 25 pagina's die deze eigenschappen gebruiken.

(vorige 25 | volgende 25) (20 | 50 | 100 | 250 | 500) bekijken.

A
AS CA MBO BO +Een gezamenlijke voorziening die CA mogelijk maakt, dient “eigendom” van de sector te zijn, dit moet in termen van governance geregeld worden  +
AS CA MBO BS +'''Eenmalige registratie, meervoudig gebruik''' Voorziening CA maakt (her)gebruik van gegevens uit BRP/BRON, RIO en van centrale voorzieningen (DigiD) '''Persoonlijke digitale ruimte''' De studentomgeving binnen CA kan worden opgevat als persoonlijke digitale ruimte ihkv het aanmeldproces.  +
AS CA MBO GUK +Na identificatie worden persoonsgegevens (uit BRP) en vooropleidingsgegevens opgehaald bij BRON/DUO. Gegevens over opleidingsaanbod worden via RIO naar CA overgebracht Voorziening CA geeft BSN, Geboortedatum en Geslacht door aan SIS Introductie van voorziening CA leidt tot harmonisatie van aanmeldinformatie Gegevenssets worden beschreven in Bijlage 2 PvE.  +
AS CA MBO IAA +Een aspirant-student identificeert zich in de voorziening CA met een eID (DIGID).  +
AS CA MBO IBP +Het transferpunt stuurt alle 1e-jaar mbo-aanmeldingen (uit CA) en aanmeldstatussen (uit VVA) door naar de analyseomgeving meervoudig aanmelden. Daar worden de gegevens geanonimiseerd ten behoeve van analyse en rapportage meervoudig aanmelden. Uitgangspunt is dat 100% van de aspirant-studentgegevens in/door de voorziening CA gaat i.v.m. inzicht in meervoudige aanmeldingen. Ten behoeve van statistische analyses kan de ruwe data van aanmeldingen door de beheerder van CA worden geëxporteerd naar Excel. Voor specificatie van de levering van gegevens CA naar SIS wordt verwezen naar Bijlage 2.. Deze bijlage 2 gaat over het wat, niet over het hoe (+maatregelen) van de levering. “Zolang wordt gewerkt met geaggregeerde rapportages [...] is er vanuit de AVG geen bezwaar”.  +
AS CA MBO KP +In het PvE zijn de processtappen van aanmelden door middel van use cases vormgegeven (PvE, p.3).  +
AS CA MBO RCA +Er zijn binnen het mbo reeds activiteiten en werkende voorzieningen gericht op digitaal aanmelden (DaMBO), Digitaal ondertekenen (pilots worden opgeschaald) en de overdracht van leerdossiers (in de regio). In het kader van nieuwe wetgeving wordt een Voorziening Vroegtijdig Aanmelden (VVA) ingericht (voor wat betreft het mbo ook wel ‘mbo-koppelpunt’ genoemd). De voorziening CA heeft een directe relatie met de Voorziening Vroegtijdig Aanmelden (VVA) en met de student informatie systemen (SIS) van de instellingen.  +
AS CA MBO TG +Collectieve (mbo-)voorziening Centraal Aanmelden Sterke wens vanuit instellingen om inzicht te krijgen in meervoudige aanmeldingen Informatiebehoefte rondom meervoudig aanmelden speelt op drie niveaus: instelling, regionaal, landelijk (sectoraal).  +
AS CA MBO WG +Centraal Aanmelden staat ten dienste van alle bekostigde instellingen; 55 instellingen nemen deel aan het PvE. PvE dient als vertrekpunt voor oplossing door geïnteresseerde (markt)partijen. Het beheer en eigenaarschap wordt ondergebracht in de coöperatieve vereniging MBO-Voorzieningen, die in handen is van de deelnemende instellingen. [[DUO]] levert gegevens aan CA, via een soortgelijke koppeling als SIS/BRON.  +
AS EK-REST BS +'''Gemeenschappelijkheid in informatiehuishouding''' Binnen het onderwijs zijn al veel ketenpartijen die gebruik maken van RESTful gegevensuitwisseling. Deze maken nu zelfstandige keuzes hoe transport, logistiek en beveiliging ingericht moeten worden. Het profiel beoogt hier meer standaardisatie in door te voeren, waarbij met name invulling gegeven wordt aan het kunnen routeren tussen de rollen die in Edukoppeling t.b.v. SaaS worden onderscheiden.  +
AS EK-REST GOV +'''Relaties met andere standaarden''' * UBV (zie ook [[AS EK-REST IBP|onderdeel IBP]]) * Voor transparante intermediair, onweerlegbaarheid, en/of uitwisseling obv XML: toepassen Edukoppeling WUS-profiel * OOAPI: onduidelijk of Edukoppeling-rollen hierin onderkend worden * Inbedding in nationale (overheidsbrede) standaarden. Basis wordt gevormd door afspraken en voorschriften uit de landelijke API-strategie. Enige mate van ontkoppeling via MoSCoW-classificering. * Op p.6 wordt XML over REST niet toegestaan, volgens API-24 is het een eigen afweging (COULD).  +
AS EK-REST GUK +Must: Gebruik van openbare internet “Overigens kan Edukoppeling ook toegepast worden in gesloten netwerken.”. Tegenspraak? Hoe ‘must’ te lezen? '''Foutafhandeling:''' * Architectuur definieert categorieën A t/m E In 3.1.8 alleen foutmeldingen voor cat. A t.a.v. syntax to/from-routeringskenmerken. → hoe passen de andere categorieën op HTTP statuscodes?  +
AS EK-REST IAA + * Identificatie/authenticatie verwerker obv OIN / PKI-infrastructuur (P2P). * Eindorganisaties worden geïdentificeerd via routeringskenmerken (TO, FROM) * Inzet van transparante dienstverleners wordt (nog) niet ondersteund (daarvoor: WUS) * Verplicht gebruik Onderwijsserviceregister * Verwijzing naar ontwikkelingen OAuth in bijlage A. * Gebruik van API-sleutels geen onderdeel van het profiel, maar wel toegestaan ** Voor API-key (geen onderdeel profiel) stroomschema’s en mogelijke 401/403-foutcodes. Zoiets mist voor afhandeling van ‘from-OIN’ en OIN verwerker (P2P) .   +
AS EK-REST IBP + * TLS (wordt verwezen naar UBV) Vertrouwelijke gegevens in GET-parameters * P.13: ‘dienen gepseudonimiseerd te zijn’ * P.18: igv persoonsgegevens ‘kunnen aanvullende beveiligingsmaatregelen toegepast worden, zoals adequaat versleutelen en/of voorkomen ongewenste logging dmv filter’.   +
AS EK-REST TG +M2M-gegevensuitwisseling via een beveiligde point-to-pointverbinding waarbij RESTful standaarden voor gesloten (access-restricted en purpose-limited) APIs worden toegepast (zowel pull als push).  +
AS EK-REST WG +Gehele onderwijsdomein (cf. organisatorisch werkingsgebied zoals beschreven in Edukoppeling architectuur).  +
AS HOVI B&O +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.  +
AS HOVI BS +'''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.  +
AS HOVI GOV +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.  +
AS HOVI GUK +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).”  +
AS HOVI IAA +'''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  +
AS HOVI IBP +'''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.  +
AS HOVI IMP +Voor zowel de onderwijsinstellingen, als de afnemers zijn er afspraken gemaakt over de implementatie van de HOVI. Deze afspraken zijn te vinden op de HOVI website. Zo is er per onderwijsinstelling een contactpersoon aangewezen die de migratie intern begeleidt en is er een overgangsperiode waarin de studiekeuzedatabase zowel HOVI- als HODEX-data kan bevatten.  +
AS HOVI KP +Voorlichten over onderwijsaanbod: HOVI biedt de standaarden en infrastructuur die onderwijsaanbieders kunnen gebruiken om op uniforme manier informatie over onderwijsaanbod aan te bieden. HOVI is de vervanger van HODEX. In “HOVI Artikel HO Informatie 2019-09-16” worden de redenen benoemd voor het vervangen van de HODEX. Genoemd wordt dat dit voornamelijk te maken heeft met dat de infrastructuur van de HODEX verouderd is en dat het register “wildgroei is ontstaan” . dezelfde ketenprocessen als de HODEX.  +
AS HOVI RC&A +HOVI is de opvolger van HODEX en daarom ook een Centrale database opleidingsaanbod, Portaal onderwijsaanbod, Adresboek van databases met opleidingsaanbod en import-tool opleidingsaanbod. Uit Bijlage 2 van de HOVI Specificatie (p.21) wordt duidelijk welke inhoudelijke wijzigingen er zijn gemaakt ten opzichte van de HODEX.  +