Regie op gegevens

Binnen het Edu-V afsprakenstelsel hebben onderwijsorganisaties regie over de eigen gegevens. De onderwijsorganisatie is in staat om een gegevensuitwisseling tussen leveranciers te activeren of te deactiveren. Meer in detail wordt er door de onderwijsorganisatie toestemming gegeven voor het uitwisselen van gegevens binnen een gegevensdienst tussen twee referentiecomponenten. In de praktijk wordt er ook wel gesproken over het aanzetten van een koppeling of het verlenen van consent.

Het koppelen of verlenen van consent is niet nieuw. Wel is het zo dat leveranciers hier eigen implementatiekeuzes in hebben gemaakt. Deze keuzes zijn in enkele gevallen onderdeel zijn van een standaard (bijvoorbeeld bij UWLR) of zijn bilateraal afgesproken. Vanuit de architectuurprincipes streven we naar een precompetitief, veilig en (toekomst)bestendig afsprakenstelsel waarbij onderwijsorganisatie regie hebben over hun eigen gegevens. Het standaardiseren van de functionele en technische werking van Regie op gegevens is hiermee een belangrijk onderdeel van het Edu-V afsprakenstelsel.

De werking hiervan wordt toegelicht in de volgende paragrafen:

Overwegingen

Bij het uitwerken van een uniforme oplossing voor Regie op gegevens zijn er een aantal zaken die we hebben afgewogen:

1. De onderwijsorganisatie maakt gebruik van meerdere applicaties waarin gegevens worden verwerkt.

2. Indien de gegevens persoonsgegevens bevatten, is de leverancier verwerker en handelt deze in opdracht van het onderwijsbestuur dat verwerkersverantwoordelijke is.

3. De onderwijsorganisatie beschikt als verwerkersverantwoordelijke over een actueel overzicht van register van verwerkingen. Een gegevensuitwisseling tussen leveranciers ten behoeve van de onderwijsorganisatie is een verwerking en staat geregistreerd in dit register.

4. Gegevens van de onderwijsorganisatie ontstaan bij, of worden geregistreerd in, één applicatie. De leverancier van deze applicatie is verantwoordelijk voor correcte verwerking.

5. Toestemming van de onderwijsorganisatie is noodzakelijk en voldoende om gegevens tussen leveranciers uit te wisselen.

6. De toestemming van de onderwijsorganisatie wordt tenminste verleend bij de leverancier van de applicatie die verantwoordelijk is voor het ontstaan van de gegevens. In het Edu-V afsprakenstelsel wordt deze leverancier de gegevensaanbieder genoemd.

7. Omwille van transparantie en compliance dienen gegevensaanbieders de toestemming te registreren.

8. In het ecosysteem wordt onderscheid gemaakt in vier transactierollen die een leverancier kan innemen in een gegevensdienst:

   1. Bron van gegevens in de transactiepatronen Bevraging en Abonneren op wijzigingen middels notificaties. De leverancier is een gegevensaanbieder.

   2. Afnemer van gegevens in de transactiepatronen Bevraging en Abonneren op wijzigingen middels notificaties. De leverancier is een gegevensafnemer.

   3. Verzender van gegevens in de transactiepatronen Melding-bevestiging en Asynchrone uitwisseling. De leverancier is een gegevensaanbieder.

   4. Ontvanger van gegevens in de transactiepatronen Melding-bevestiging en Asynchrone uitwisseling.De leverancier is een gegevensafnemer.

9. De combinatie van overweging 6) en 8) leiden ertoe dat toestemming tenminste wordt verleend bij de Bron en de Verzender van de gegevens.

   1. Omwille van de correcte werking van het transactiepatroon Melding-bevestiging en Asynchrone uitwisseling is een bevestiging vanuit de Ontvanger gewenst.

   2. De registratie bij de Ontvanger is gewenst om als Verzender er zeker van te zijn dat een verstuurde melding naar een Ontvanger ook wordt geaccepteerd.

10. In het ecosysteem zijn leveranciers actief met een eigen API infrastructuur, en zijn ook leveranciers actief zonder eigen API infrastructuur. Dit is afhankelijk van de transactierol die een leverancier inneemt in een gegevensdienst.

    1. Ter illustratie in de transactierollen Afnemer en Verzender is het niet per sé noodzakelijk om een eigen API te hebben. Als Afnemer kun je de API van de Bron bevragen (pull). En als Verzender kun je een bericht naar de API van de Ontvanger toesturen (push).

11. Een onderwijsorganisatie kan toestemming voor een specifieke set van gegevens verlenen. Hierbij onderscheiden we:

    1. De scope vanuit de onderwijsorganisatie, zijnde een onderwijsaanbieder.

    2. De scope vanuit de gegevens, denk aan alle gegevens uit de gegevensdienst of een beperkte set van gegevens uit de gegevensdienst. Hierbij kan onderscheid gemaakt worden in:

       1. Het informatieobject: de entiteiten en attributen, bijvoorbeeld wel de basisgegevens over onderwijsdeelnemers maar niet de communicatiegegevens van onderwijsdeelnemers.

       2. De gegevens: een subset van de beschikbare gegevensset, bijvoorbeeld wel alle onderwijsdeelnemers die ingeschreven zijn op de bovenbouw van het havo/vwo en geen andere onderwijsdeelnemers.

12. Zodra het persoonsgegevens betreft dan is er ook toestemming nodig vanuit de persoon zelf. In het Edu-V afsprakenstelsel gaan we ervan uit dat de verwerkersverantwoordelijke (zijnde de onderwijsorganisatie) deze toestemming heeft verkregen vanuit haar wettelijke taak of middels expliciete toestemming vanuit de (verzorgers van de) persoon.

13. Leveranciers zijn als Verwerker gebonden aan de afspraken zoals vastgelegd in de verwerkersovereenkomst en dienen daarnaast te voldoen aan de AVG. De implicatie hiervan is dat alleen de persoonsgegevens worden verwerkt waarvoor een leverancier ook daadwerkelijk doelbinding heeft.

    1. Als voorbeeld kan een leverancier met een methode Biologie voor de onderbouw toestemming vanuit de onderwijsorganisatie hebben om gegevens uit het Administratiesysteem onderwijsdeelnemer te bevragen. De leverancier mag echter alleen de persoonsgegevens verwerken van de onderwijsdeelnemers die ook daadwerkelijk het vak Biologie volgen en in de onderbouw zitten.

    2. Leveranciers treffen maatregelen om enkel deze persoonsgegevens te verwerken en beschikbaar te stellen in de eigen applicaties. De overige persoonsgegevens worden niet opgeslagen.

14. Een aantal architectuurprincipes conflicteren potentieel met elkaar waardoor een trade-off noodzakelijk is. Het betreft onder meer de volgende principes:

    1. A11: De afspraken in het afsprakenstel zorgen voor een gelijke toetredingsdrempel voor alle leveranciers.

    2. A12: De afspraken bevatten geen onredelijke en onnodige toetredings- en implementatiedrempels.

    3. A13: Het afsprakenstelsel faciliteert stapsgewijze toetreding van leveranciers in referentiecomponenten, gegevensdiensten én technische infrastructuur.

    4. B5: Leveranciers kunnen met de door hen gekozen referentiecomponenten autonoom opereren.

    5. B6: Het afsprakenstelsel bevat mechanismen om de continuïteit van processen en de integriteit van data te borgen, waaronder fallback scenario’s, opvragen van initiële standen en support endpoints.

    6. B9: Gegevensuitwisselingen zijn traceerbaar.

    7. C2: De maatregelen zijn passend voor de gegevens die verwerkt worden. De maatregelen zijn bijvoorbeeld strikter vertrouwelijke gegevens, persoonsgegevens en bijzondere persoonsgegevens en minder strikt voor niet vertrouwelijke gegevens en open data.

    8. C4: In het afsprakenstelsel is de privacy van onderwijsdeelnemers en onderwijsmedewerkers altijd geborgd.

    9. D3: De onderwijsorganisatie geeft toestemming over de uitwisseling van eigen gegevens tussen leveranciers.

15. De lijst met architectuurprincipes toont aan dat B5, B6, B9, C2, C4 en D3 leiden tot implementatie. Bij het ontwerp van Regie op gegevens is het van belang om hierbij A11, A12 en A13 in acht te nemen en ervoor te zorgen dat er geen onredelijke en onnodige drempels zijn en dat leveranciers stapsgewijs kunnen toetreden. In het ontwerp wordt derhalve onderscheid gemaakt in:

    1. must: verplicht om te implementeren.

    2. shOULD: sterk aanbevolen om te implementeren.

    3. COULD: optioneel te implementeren.

Conceptueel model

In het afsprakenstelsel gaan meerdere referentiecomponenten gegevens met elkaar uitwisselen. De referentiecomponenten doen dat in een transactierol van Bron, Afnemer, Verzender of Ontvanger binnen een gegevensdienst. In het conceptueel model is een ecosysteem weergegeven met vijf leveranciers die samenwerken in de gegevensdiensten onderwijsadministratie (rood), leerresultaten (geel) en leermateriaalgebruik (groen). Voor al deze gegevensdiensten is regie op gegevens van toepassing.

Open

Figuur 1: Conceptueel model Ecosysteem met vijf leveranciers en drie gegevensdiensten

In het ecosysteem zijn vijf leveranciers met elk één applicatie actief:

• Leverancier A biedt een applicatie aan met drie referentiecomponenten:

  • Administratiesysteem onderwijsdeelnemer in de transactierol Bron voor de gegevensdienst Onderwijsadministratie.

  • Administratiesysteem leerresultaten in de transactierol Ontvanger voor de gegevensdienst Leerresultaten.

  • Consentmanagement om regie op gegevens mogelijk te maken voor beide gegevensdiensten.

• Leverancier B biedt een applicatie aan met twee referentiecomponenten:

  • Gebruiksomgeving digitaal leermateriaal in de transactierol Afnemer voor de gegevensdienst Onderwijsadministratie.

  • Consentmanagement om regie op gegevens mogelijk te maken voor deze gegevensdienst.

• Leverancier C biedt een applicatie aan met twee referentiecomponenten:

  • Gebruiksomgeving digitaal leermateriaal in de transactierol Afnemer voor de gegevensdienst Onderwijsadministratie én Verzender voor de gegevensdienst Leermateriaalgebruik.

  • Consentmanagement om regie op gegevens mogelijk te maken voor beide gegevensdiensten.

• Leverancier D biedt een applicatie aan met twee referentiecomponenten:

  • Digitaal toetssysteem in de transactierol Afnemer voor de gegevensdienst Onderwijsadministratie én Verzender voor de gegevensdienst Leerresultaten.

  • Consentmanagement om regie op gegevens mogelijk te maken voor beide gegevensdiensten.

• Leverancier E biedt een applicatie aan met twee referentiecomponenten:

  • Leermiddelendashboard in de transactierol Afnemer voor de gegevensdienst Onderwijsadministratie, Ontvanger voor de gegevensdienst Leermateriaalgebruik én Ontvanger voor de gegevensdienst Leerresultaten.

  • Consentmanagement om regie op gegevens mogelijk te maken voor alle drie de gegevensdiensten.

Alle leveranciers bieden in hun applicatie de referentiecomponent Consentmanagement aan. Dit stelt de applicatiebeheerder vanuit de onderwijsorganisatie in staat om de desbetreffende applicatie te koppelen aan een andere applicatie en daarmee de gegevensdiensten te activeren of te deactiveren. Met andere woorden: consent verlenen of consent intrekken.

Voor ieder van de vijf leveranciers is de implementatie van de benodigde infrastructuur en het consentmanagement echter anders:

In het Afsprakenstelsel Edu-V ondersteunen we daarom vier implementatievarianten voor regie op gegevens. Deze worden toegelicht in de volgende paragraaf.

Implementatievarianten

De bovenstaande overwegingen hebben geleid tot een ontwerp waarin we onderscheid maken in een aantal implementatieonderdelen:

Consent Consumer is een belangrijke architectuurkeuze om de laagdrempeligheid te borgen voor leveranciers die geen noodzaak voor een eigen API hebben. Zij zijn hiermee niet verplicht om alleen voor het uitwisselen van consentgegevens alsnog een API infrastructuur in te richten. Vanzelfsprekend dienen deze leveranciers wel te beschikken over een Client om te gegevens op te vragen of te versturen naar een API van de andere leverancier.

Bij de werking van Consent gaan we ervan uit dat er consent wordt verleend bij de Bron of de Verzender. Daar ontstaan immers de gegevens waarover de onderwijsorganisatie regie heeft. In de praktijk leiden Consent Consumer en Consent API tot vier mogelijke implementatievarianten voor het uitwisselen van consentverleningen tussen leveranciers:

De vier implementatievarianten zijn weergegeven in interactiediagrammen op de pagina’s:

1. Bron met Consent API en Afnemer als Consent Consumer

2. Bron en Afnemer met Consent API

3. Verzender als Consent Consumer en Ontvanger met Consent API

4. Verzender en Ontvanger met Consent API

COULD Consentverzoek

In aanvulling op de vier implementatievarianten kunnen Afnemer en Ontvanger een verzoek doen bij respectievelijk Bron of Verzender om gegevens te delen. De initiatie vindt in dit geval plaats binnen de referentiecomponent consentmanagement van de Afnemer of Ontvanger (in tegenstelling tot initiatie vanuit de Bron of de Verzender). Een applicatiebeheerder doet een verzoek om consent te verlenen vanuit de referentiecomponent Consentmanagement van de Afnemer of Ontvanger. In de praktijk leidt dit tot drie mogelijke samenwerkingsvarianten tussen leveranciers:

Bij iedere implementatievariant is ook het interactiediagram toegevoegd voor de implementatie van het consentverzoek.

COULD Verwerkersregister

Leveranciers wisselen gegevens uit ten behoeve van onderwijsorganisaties. Indien er persoonsgegevens verwerkt en uitgewisseld worden dan zijn zowel onderwijsorganisatie als leverancier verplicht om een verwerkersovereenkomst te ondertekenen. In een gegevensuitwisseling tussen twee leveranciers dienen beide leveranciers over een geldige verwerkersovereenkomst met het onderwijsbestuur te beschikken.

De referentiecomponent Verwerkersregister maakt het mogelijk voor leveranciers om te verifiëren of een andere Leverancier al dan niet beschikt over een geldige verwerkersovereenkomst met het onderwijsbestuur. Zodra er geen verwerkersovereenkomst is voor een afnemende of ontvangende leverancier dan is het niet wenselijk dat er een gegevensuitwisseling wordt geactiveerd met deze leverancier. De informatie uit het verwerkersregister kan door leveranciers die als Bron of Verzender optreden benut worden om applicatiebeheerders te notificeren over het ontbreken van de verwerkersovereenkomst bij Afnemer of Ontvanger.

Het toepassen van deze controle als onderdeel van het verstrekken en registreren van consent is niet verplicht maar wel een optie. De functionele werking van deze verificatie is beschreven op de volgende pagina:

• Verifiëren geldigheid van een verwerkersovereenkomst

Release notes